#47127 - wiz - Tue Jul 05, 2005 4:15 pm
Hellllo
I have recently read that the GBA has hardware support for decompression?
I also read you need a tool to compress your data, what Im wondering about is if I had a massive const u8 array[] and in a program I currently access it normally - what would I need to change when its in its compressed form?
Theres no way it would all decompress in one go - so this must be done in real time, right? for example: is there a way to access array[1234] from its compressed form?
I'm just not sure where to begin, am I even on track?
Cheers all!
#47130 - poslundc - Tue Jul 05, 2005 5:36 pm
The GBA doesn't support hardware compression as such, but it has some built-in decompression algorithms written onto its BIOS that you can access using SWI instructions. These routines are fairly generic, though, and easy to beat the performance of with your own optimized code. More details on the SWI instructions can be found in the [url=http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#BIOS%20(Software%20Interrupts)]Cowbite section on BIOS[/url].
And yes, when your resources are compressed you won't be able to access them directly with any meaningful results. Which usually means you must decompress some or all of the necessary data into EWRAM first before you use it. Depending on the amount of data you need, it might just be a matter of decompressing stuff while switching levels, or if you need to access data more randomly than that it may mean decompressing during VDraw and then copying the decompressed data during VBlank.
Dan.
#47223 - wiz - Wed Jul 06, 2005 3:50 pm
Thanks for clearing up a few things Dan. I love that cowbite site not sure where I would be without it!
What I will probably need is a way to compress maps. Each map will be a v.very large u8 array. I can imagine it wouldnt be much trouble decomressing horizontal map strips in realtime because the tiles will be in order. Not sure about verical strips though.
Will the "decompression" function have to be asm? Unfortunately until today I had no idea what a SWI instruction was. (a way to call a BIOS routines?) But Im still very unsure how I would make use of *them*
#47244 - Miked0801 - Wed Jul 06, 2005 7:16 pm
Compression of maps - my bane. They're huge so they need ot be compressed, but they need to be accessed randomly on a per char basis which rules out most compression schemes. 3 ways to make this work:
1. Compress all the chars at once using the best compression you can find then decompress them all into RAM (or VRAM if they'll fit) when the map is loaded.
Advantages: Best compression. Simpler code
Disadvantages: Signifigantly limited number of chars per map based on EWRAM sized or VRAM.
2. Compress each char individually, and decompress and load each on the fly as needed.
Advantages: Unlimited number of chars available to maps (within reason)
Disadvantges: 32 bytes is too small a dataset for most compressor to reliably compress well. Your compress will suffer greatly. You'll take a CPU hit when decompressing each individual char on the fly. It does work though!
3. Compress chars in small groups (say groups of 16). Load in as needed
Advantges: 16 chars is a large enough amount of data (512 bytes) that most compressors will be able to get decent compression. Allows nearly unlimited number of chars per map.
Disadvantages: You are decompressing more chars than you need to for each load so it will be slower (possibly too slow). You'll also probably need to write a buffering system where extra chars that aren't needed immediately are cashed for future use. This is the most complex solution of the 3 in terms of code.
We've used 1 and 2 on comercial games just fine. 3 is something I may do in the future if we need better compression. It's just such a complex system that getting it 100% at a reasonable speed is kinda scary :)