(Recovered from SMWiki, improvements are welcome.)
Latest revision as of 23:36, 9 November 2019
The compression is a simple run-length encoding format. However, this one is two-dimensional, which means the decompressed data gets stored every other byte in the output buffer unlike LC_RLE1. Therefore, the decompression routine needs to be run entirely two times. Also, there are two compressed tables.
The compressed data consists of "chunks", each with a header:
bits 76543210 CLLLLLLL C: Command bit LLLLLLL: Length
Here's a list of the command bit values the LC_RLE2 routine can use during decompression:
0 "Direct Copy" Followed by (L+1) bytes of data 1 "RLE" Followed by one byte to be repeated (L+1) times
There is no byte which marks the end of the compressed data. You have to specify the length of the original, decompressed data so the decompression goes without any problems.
Two tables and decompression
The decompressed data gets written to the output buffer every other byte. This means that the bytes are stored as [XX] [YY] [XX] [YY] [XX] [YY] [..]. The XX bytes are from table 1, the YY bytes are from table 2. Technically, when the compressed data is read, the index to the compressed data increases by one, while the index to the output buffer increases by two, which causes this effect. The tables' original decompressed length should be half of the original, decompressed data altogether. So if you specify the length as $4000 bytes, table 1's output should be $2000 bytes, and table 2's output should be $2000 bytes too.
You can use the LC_RLE2 compression to mainly compress raw VRAM tilemap. Technically you can compress anything with this format, but raw VRAM tilemaps are preferred due to the often-occuring repeating every-other bytes.
You can see an LC_RLE2 decompression routine setup at SNES $04:DC6F (SMW). The decompression routine itself is located at SNES $04:DABA. The decompression routine does not support data which crosses bank boundaries. Therefore, you will have to take care of that.