#10124 - johnny_north - Wed Aug 27, 2003 6:24 pm
Is it possible to decompress lz77 data on the fly? What I?d like to do is compress sprite data for a multiboot image. I can see a couple of problems though. If I need to get a sprite that is one in a group of many, is it practical to produce the uncompressed data by knowing the original frame?s start and ending byte? Can you use lz77 data this way?
I suppose that individual frames of animation could be compressed then individually decompressed using the bios vram lz77 for some basic animation. Does anyone know how slow this would be for say a 64x64 sprite? I need to get some animation, but frame rate is not the biggest issue.
I?m assuming that there will be no room in ewram for me to decompress whole sprite animation strips.
#10133 - DekuTree64 - Wed Aug 27, 2003 7:14 pm
Yeah, I'm pretty sure it's fast enough. I don't know about loading single frames though. I was having that problem with my RPG's battle animations so I decided to use the second 128K of EWRAM as a frame cache, but in a multiboot ROM that's not really an option.
You could write your own decompression routines and make it where you can specify the position in the decompressed data that it should start writing to the dest address, so for a 64x64x256 color sprite, to load frame 2, you'd decompress data until the number of bytes that would have been written to dest gets to 4096, and then start writing until it gets to the end of that frame and return. That would get slow to load the last frame out of a long animation though. Maybe you could look into how .zip files are compressed, since you can decompress single files out of them.
But if you don't have time to learn the algorithms to code your own, I think your best bet would be compressing frame seprately with the command line GBACrusher and a batch file.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#10137 - torne - Wed Aug 27, 2003 7:39 pm
zip files are compressed by deflating each individual file, then concatenating the compressed files together along with a header specifying their names, offsets, sizes, and other metadata. This is horribly inefficient for very small 'files' (such as single frames of animation) as there is almost no redundancy to exploit. If you use small enough files, the compression rate of ZIP drops to 1:1 or worse.
RAR/Ace/tar.bz2/tar.gz are compressed by concatenating the files together then compressing the whole stream; this means you get much higher rates of compression in many cases, but must decompress along the stream until you get to the file you want, if you only want one file.
I would suggest that a hybrid is most appropriate for animation type stuff. Pack sufficient frames together that the compression is ok, but no more than that. =)
#10148 - Master S - Thu Aug 28, 2003 7:32 am
The bios lz77 decompress function reads the size of the uncompressed data from (i think) the first 4 bytes in the compressed data. This means that when calling the decomp. function, you only have to specify source (compressed data) and dest (uncompressed data), and NOT a length param, so it's not posible to decompress a single frame of a animation (using the bios function) Using the bios function the only way to do this is by compressing your sprites individual