Use a library of the 256 most commonly used 8x1 pixel rows. Each 8x1 row in the sprite or tile has bit selecting either a literal 8x1 row, or a byte referencing an 8x1 from the library.
Interesting.
To be effective, that would require that the most common rows be common enough to outweigh the 1-byte-per-tile overhead of telling which rows use the dictionary. This will be harder at 2bpp (Game Boy format) than at 4bpp. Anyone have some Super NES tile sheets with which I could test this algorithm?
This is yet another version of my pony-tailed cheerleader character. I made her more cartoony looking because the more realistic style was too difficult to animate fluidly. This would take up exactly 9kB uncompressed in an SNES cart.
I wrote a ratio estimator (which does not actually output a compressed byte stream). Here's what it says:
Code:
2304 slivers, 668 distinct, 252 repeated
dictionary of length 252 slivers has 1888 hits and 416 misses
Assuming 4 bpp, 9216 bytes would compress to 1008 bytes dictionary,
288 bytes control, 1888 bytes references, and 1664 bytes literal
Total: 4848 bytes (52.6% of original)
That is good for such a simple algorithm.
I'm not sure you'd want to compress these graphics anyway =P
That said, I bet a lot of space could be saved by spliting them into smaller sprites. There seems to be quite a good chunk of empty space around. Also it's likely you'll need sprites that don't fit in a 48×64 box in the future (when she does some other animation).
I would probably use metasprite optimization if I have too much flickering, or animation problems. With sizes, she has 6 48x64 of stance, 8 64x64 frames of running, 4 48x72 frames of jumping, and 4 64x64 frames of dash attack. My engine relocates animation slots whenever actors change sizes, which can be problematic when VRAM is crowded. If there is no space in VRAM, it doesn't draw the actor to the screen.