--- In gbadev@yahoogroups.com, "miked0801" <katy.mike@v...> wrote:
> Any other popular compressors out there (besides RLE, LZ77)?
> PuCrunch seems pretty nice and runs fast with just a little work.

RLE is in theory a special case of LZSS with a window size of one
symbol. The big purported advantage of RLE over LZSS comes only
with the larger copy sizes that common RLE implementations have
(130 or so vs. 18 for GBA LZSS). If you have highly repetitive
data, you may be able to beat the GBA's garden-variety LZSS by
modifying the compressor to use nonlinearly increasing copy sizes
and writing a decompressor to match.

You may also want to try Huffman coding of some sort. In fact,
Deflate is in effect an LZ77 pass followed by Huffman coding.
However, Huffman can be slow because using a bitstream rather
than a bytestream involves lots of shift operations.

I've tried Pucrunch, and decompression was dog slow because
Pucrunch compressed data is also a bitstream. Pucrunch didn't
even do significantly better on my test corpus (the 4-bit tiles
and 8-bit bitmaps of Tetanus On Drugs) than GBA LZSS did.
LZO is faster, but it's under a copyleft license, which means
you have to distribute your game's source code with the binary
(or make a suitable written offer to distribute said source code
at cost) unless you negotiate an alternate agreement with the
author.

If you are trying to compress images or tile data, try storing
difference images. Sort your palette from darkest to lightest,
subtract each row from the previous row, and then use LZSS
followed by Huffman coding.

--
Damian