Graphics compression for the sprites appears to be very simple. All they are basically doing is compressing those bytes of tile data that are 00. A good number of the sprite tiles in the ROM are not compressed at all. For those that are, there is a 4 byte header with decompression control information. Each nybble in that header controls a single segment of 4 bytes of tile data. The control operations for each type of nybble are as follows:
A zero indicates that the next byte of tile data is zero, and "copy" copies a byte of ROM data into the tile instead. Actual tile data starts immediately after the 4 byte header. So making a decompression/compression algorithm for these tiles is pretty straightforward. The other part is then locating all the actual pointers to compressed tile data, and then editing those pointers from within a character's animation frames themselves.
April 14, 2019, 11:13:38 am - (Auto Merged - Double Posts are not allowed before 7 days.)
I can see why this game hasn't had much hacking attention before. It's not that the compression routine for sprites itself is difficult, but rather the structure of the data and the pointers. This game basically REQUIRES you to use a tool to make edits, as doing it by hand is incredibly impractical. For each character, all of their compressed tiles are stored together, and MUST be ordered by their compressed size. Rather than having a list of pointers to each tile, pointers are automatically generated based on these compressed sizes and a table in ROM that lists how many tiles of each size there are. So if you change the size of a single tile:
1. The compressed tile list needs to be re-ordered
2. The table holding the # of compressed tiles of each size needs to be updated
3. EVERY animation frame for that character needs to be rewritten.