So, reading your explanation above.
Would it be better if I cut the large images (34 pixels high) into 2 images of 17 pixels in height?
It seems to me this would increase the chance of finding contiguous memory.
gtBASIC
Forum rules
Be nice. No drama.
Be nice. No drama.
Re: gtBASIC
There's no need to do that, the BLIT routine will automatically split up the image into contiguous chunks of whatever you specify, obviously it will become a little more inefficient as more individual native calls will need to be made internally to get the full image on screen; just set the number so that the LOAD BLIT's work and you'll be fine
Re: gtBASIC
I have a question ? I need to make an image move slowly off screen upwards. Could you add the ability to show a partial piece of the sprite so that memory is not corrupted by drawing a sprite off screen ?
The only other option is to make several slightly smaller and smaller sprites to show the effect but this uses up limited resources.
The only other option is to make several slightly smaller and smaller sprites to show the effect but this uses up limited resources.
Re: gtBASIC Sprite Memory
My application loads 34 BLITs then attempts to load 8 sprites. It fails on the 8th sprite with the following message.
' couldn't allocate memory for sprite 8'
I was loading 36 BLITs but removed 2 that were 36 X 34 pixels each and it still won't load the 9 X 18 sprite no 8.
This makes me think the memory issue is not the BLITs loaded ahead of the sprites.
I have reserved memory for sprites with this statement:
CONST vtX = &h0600
DEF BYTE(vtX, 0, 1, 120) = 0
Is there something I can do to correct this issue as I need a few more sprites
' couldn't allocate memory for sprite 8'
I was loading 36 BLITs but removed 2 that were 36 X 34 pixels each and it still won't load the 9 X 18 sprite no 8.
This makes me think the memory issue is not the BLITs loaded ahead of the sprites.
I have reserved memory for sprites with this statement:
CONST vtX = &h0600
DEF BYTE(vtX, 0, 1, 120) = 0
Is there something I can do to correct this issue as I need a few more sprites
- Attachments
-
- spritememory.jpg (133.38 KiB) Viewed 994 times
Re: gtBASIC
You need to LOAD the SPRITE's before the BLIT's. most likely what has happened is that the BLIT's have taken some of the SPRITE's memory. Also, with the 64k model the maximum number of rows for all SPRITE's, is 120 + 128; have you exceeded this number?
Re: gtBASIC
I have used 204 rows so there are not many left. (More info for the manual).
I removed all large BLIT and then I could then add more sprites so it is the BLITs stealing sprite memory.
I will work out a happy balance of BLIT and SPRITE. There is a large SPRITE flicker issue on the SPRITE DRAW - SPRITE RESTORE set of commands that hopefully I can eliminate.
I removed all large BLIT and then I could then add more sprites so it is the BLITs stealing sprite memory.
I will work out a happy balance of BLIT and SPRITE. There is a large SPRITE flicker issue on the SPRITE DRAW - SPRITE RESTORE set of commands that hopefully I can eliminate.
Re: gtBASIC
Is there a way to stop the erasure and redrawing of specific sprites with the SPRITE DRAW - SPRITE RESTORE commands ?
Even though the sprites have not moved they appear to be erased and redrawn each loop.
Even though the sprites have not moved they appear to be erased and redrawn each loop.
Re: gtBASIC
There isn't, SPRITE's are designed to emulate real hardware sprites as much as possible, i.e. they are capable of restoring any background, static, dynamic, other sprites, blit's, bullets, etc.
If you want a sprite that doesn't redraw/refresh based on spatial state, (i.e. movement), then just use a BLIT that has an embedded background.
If you want a sprite that doesn't redraw/refresh based on spatial state, (i.e. movement), then just use a BLIT that has an embedded background.
Re: gtBASIC
The problem is I am trying to reduce my large BLITs and use the SPRITE/PATTERN process instead as this will fit in memory. I have changed over and it all fits but the flicker is annoying
I have a couple of ideas that might figure this out
I have a couple of ideas that might figure this out
Re: gtBASIC
I was able to get all the graphics into the app by breaking the large images into strips of narrower subsets and adjusting the graphics so there were common areas that could be used across multiple images.
This works well in the emulator. Hopefully I will be able to test on a real gigatron soon as my new man cave is sloowwwly coming to fruition.
This exercise has been interesting. I actually miss the creativity you needed 40 years ago to fit ever expanding application requirements onto memory limited machines back then.
This works well in the emulator. Hopefully I will be able to test on a real gigatron soon as my new man cave is sloowwwly coming to fruition.
This exercise has been interesting. I actually miss the creativity you needed 40 years ago to fit ever expanding application requirements onto memory limited machines back then.