Software tile decompression

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Software tile decompression
by on (#52996)
I've added a decoder for the SNES to my tile compression package: http://jiggawatt.org/badc0de/sixpack/.

The algorithm used is LZSS so it's not exactly optimal, but it can achieve decent compression. The decoder is currently not as flexible as the Master System version I wrote earlier - it lacks the ability to decode tiles where unused bitplanes have been removed for example.

The decoder uses about 4kB of RAM starting at $7F0000 + 16 bytes of DP RAM starting at $80 (the addresses can be modified with some defines in the decoder).

There's a test ROM with source code included.

by on (#53280)
I've updated some of the SNES-related parts of sixpack recently. The converter can now output 8-bit planar data (for mode 3/4) in addition to the formats it already supported. I've also rewritten parts of the 65816 LZSS decoder so hopefully it's a bit faster now; I haven't tried doing any measurements.

I'm planning on adding an option to the converter that would convert tiles from planar to linear mode before encoding them, and then back to planar during decoding. This would probably improve compression a little bit, but we'll see.

by on (#53282)
mic_ wrote:
I'm planning on adding an option to the converter that would convert tiles from planar to linear mode before encoding them, and then back to planar during decoding.

By "linear mode" do you mean in the sense of the packed pixel formats used on Genesis and GBA? If so, you can probably repurpose some GBA tile converters in your early experiments.

by on (#53288)
I mean that each pixel would be stored in one nibble/byte/whatever instead of being broken up in separate bitplanes.
Modifying the converter to do this is no big deal - just a few lines of code. Modifying the decoder takes a bit more work. It's not a huge task, but I have a lot of active projects and a finite amount of time to work on them, so..

by on (#63263)
I've written an aPLib decruncher for the SNES which now is included in the package: http://jiggawatt.org/badc0de/sixpack/

by on (#63373)
I've written a 65816 version of the PackFire tiny mode depacker. The code can be found here.

Depacking large amounts of data (like a full-screen 256-color image) using this algorithm is very slow on the SNES, but the compression ratios are pretty good.

by on (#63374)
mic_ wrote:
I've written a 65816 version of the PackFire tiny mode depacker. The code can be found here.

Depacking large amounts of data (like a full-screen 256-color image) using this algorithm is very slow on the SNES, but the compression ratios are pretty good.


Even with Mode-7 packed pixel format?

by on (#63375)
It depends on the amount of data. The test I made was to unpack 29120 bytes of data (packed size: 18158 bytes), and this took several seconds.

The same data unpacks much much faster with the LZSS (packed size: 21283) and aPLib (packed size: 18774) depackers.