#111384 - KertDawg - Wed Dec 06, 2006 3:16 am
Hello!
I have a 32x32 sprite for which there are over 32 frames. They're 256-color sprites. That makes 512 cells. From what I understand, I'm out of room if I want to add additional sprites.
Is there any way to show more than this number of 256-color sprites?
The options that I can think of are: 1.) convert them to 16-color. This might not be easy, though. 2.) DMA copy frames in before they're needed. I can have frames for, say, the sprite to face a certain direction. I can DMA copy the sprites for a new direction when the sprite turns. Will DMA be fast enough to copy 8 32x32 frames into place?
I will experiment. I'm hoping that somebody will have a clever trick that might make things a little easier. Thanks for any replies!
_________________
- Kertis
#111386 - tepples - Wed Dec 06, 2006 4:09 am
| KertDawg wrote: |
| The options that I can think of are: 1.) convert them to 16-color. This might not be easy, though. |
Many professional games use 16 color sprites. If they don't look good, hand-retouch them.
| Quote: |
| 2.) DMA copy frames in before they're needed. I can have frames for, say, the sprite to face a certain direction. I can DMA copy the sprites for a new direction when the sprite turns. Will DMA be fast enough to copy 8 32x32 frames into place? |
Of course it's fast enough.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#111404 - Dwedit - Wed Dec 06, 2006 8:22 am
I think that Vblank is long enough to overwrite the entirety of vram about 5 times, unless I calculated wrong.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#111407 - Ant6n - Wed Dec 06, 2006 8:40 am
vblank: 83776 cycles
time to copy 16bit from overclocked ewram to vram: ~2 cycles (time is ~3 cycles for 32bit from iwram).
--> makes ~80000 bytes you can copy during vblank.
now that is not the entire vram, which is 96 KB, but sprite memory is only 32 KB (or 16 KB in bmp modes), so you can copy more than once, and it is probably save to assume that you could update all sprites even from rom assuming you have fast copy routines.
#111441 - Miked0801 - Wed Dec 06, 2006 5:04 pm
With double-buffering, you have enough time to decompress individual sprite frames and load them whenever, then update only the OAM during VBlank.
#111450 - gmiller - Wed Dec 06, 2006 5:58 pm
Although this is not hardware double buffering and if you have a lot of active sprite image data then you might still have to copy the data during vblank rather than change an index in OAM.
#111520 - Dwedit - Thu Dec 07, 2006 6:03 am
Use a cache for VRAM so you don't always need to recopy.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#111524 - Ant6n - Thu Dec 07, 2006 7:58 am
I would advise against caching sprites. There is so little memory on gba, and copying is really fast. Even if one has 32 animated sprites running at 20 fps, one can still safely copy from rom, if a couple of animations are offset from the others by a frame.
I am actually in the process of writing a little library that tries to organize sprites and vram and provides functions to handle resources in a more abstract way. not very easy to do, the engineering part is harder than the programming.
#111549 - tepples - Thu Dec 07, 2006 5:04 pm
| Ant6n wrote: |
| I would advise against caching sprites. There is so little memory on gba, and copying is really fast. |
Is copying still really fast if the sprite cels are compressed in the ROM?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#111556 - poslundc - Thu Dec 07, 2006 5:56 pm
| tepples wrote: |
| Is copying still really fast if the sprite cels are compressed in the ROM? |
It's even faster, but the data you copy is a whole lot less visually appealing. ;-)
If you need to compress your data, I recommend a scheme such as the one Mike was suggesting where you double-buffer in VRAM, and can therefore safely decompress a frame into VRAM during the VDraw period before displaying it in VBlank. Of course, the penalty to this method is you have less active VRAM available, and the GBA's 32K already isn't huge.
Dan.
#111561 - Ant6n - Thu Dec 07, 2006 6:58 pm
| tepples wrote: |
| Ant6n wrote: | | I would advise against caching sprites. There is so little memory on gba, and copying is really fast. |
Is copying still really fast if the sprite cels are compressed in the ROM? |
mmh, not sure. But I wonder which compression one would use.
But then again, if one changes the full 32 kB of sprite tile ram 20 times per second, that would be 640 KB of data to cache.
#111564 - Dwedit - Thu Dec 07, 2006 7:18 pm
You don't cache all of it, you just refuse to recopy what's already in sprite vram. If you use the full sprite vram, there would be quite a few updates before the old data gets overwritten. Not copying tiles is still faster than copying them.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#111567 - Miked0801 - Thu Dec 07, 2006 8:00 pm
Many older, lossless compression routines work very well. LZ77, RLE, and check out PUCrunch (an old C64 compressor) which rivals ZIP on smaller files. All the above also decompress fairly qucikly as well. If one needs compression that is.
If not, you could allocate 1 buffer in VRAM that fits your entire sprite (if it doesn't change in size much) and then just copy from ROM into the same area (and update the OAM if the sprite sizes change). This works well too.
#111897 - KertDawg - Mon Dec 11, 2006 3:45 pm
Thanks for all the replies. The solution that I used was to DMA copy the sprites that I need every time the animation loop changes. Since it's a 32x32 sprite with 8 frames in a loop, the amount of data is small. I'm doing the copy during vblank, and it works very well.
Thanks again for the replies.
_________________
- Kertis
#111905 - Ant6n - Mon Dec 11, 2006 5:05 pm
yay for works
#112432 - Ant6n - Sat Dec 16, 2006 9:52 am
back on the compression question. What 'image' compression format would be useful to use? I think jpeg is out because of colors, gif due to licensing (??), png, well, don't know. I wonder whether there is a good image format that compresses well in 1-8 bits paletted color formats and can be output from usual programs. thoughts?
#112468 - tepples - Sat Dec 16, 2006 5:36 pm
| Ant6n wrote: |
| What 'image' compression format would be useful to use? I think jpeg is out because of colors |
JPEG has been ported to the GBA by Burton Radons. It's still useful for mode 3 backgrounds.
| Quote: |
| gif due to licensing (??) |
Unisys's patents expired worldwide before the Nintendo DS came out.
| Quote: |
| png, well, don't know. |
PNG is a heavyweight codec. It was originally designed for compression efficiency at the expense of code space and CPU time, for use on desktop machines with CPUs clocked 40 times faster than the GBA's.
| Quote: |
| I wonder whether there is a good image format that compresses well in 1-8 bits paletted color formats and can be output from usual programs. thoughts? |
You can use PNG, or you can use what a lot of GBA and DS games use: raw 4-bit or 8-bit tiles in LZSS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#112478 - sgeos - Sat Dec 16, 2006 7:01 pm
Why not used a compressed version of the native graphics format? You should be able to convert just about anything using gd.
-Brendan