Multiplayer Graphics Compression
Dimedime-d opened this issue · comments
Most of the graphics used in the multiplayer (Single Pak Versus) mode use a very peculiar compression scheme:
The data comes in "groups" of 8 blocks, each block is 8x8 pixels. The data is filled column by column, using one type of byte to tell the game to switch nibbles (hex digits), and reading off nibbles from other bytes as needed.
My current compression code doesn't compress graphics correctly in all cases, particularly when a nibble stays the same from column to column. As a consequence, I'd have to design my graphics such that this isn't the case.
The slightly darker purple on the top left edge is a minor tweak by me so that the other shade of purple doesn't "bleed over" to the next column.
If I could identify this compression algorithm, I would have a much easier time improving the accuracy of my compression, either by applying existing code, or studying this unknown compression routine online. Otherwise, I'm stuck with these graphical restrictions when hacking my images in. Or, I could opt to use the other LZ compression, but that would require changing the asm to use the other decompression routine.
I am experiencing the same problem with my translation of Kururin Squash! (GameCube), worked on by the same team of developers. It's almost done, but the GBA micro-ROM sent for the GBA minigame has a single interestingly compressed piece of text that is preventing me from reaching 100%.
Firstly, the above graphics from Kururin Squash! did not use this compression routine, rather, the LZSS compression in the GBA BIOS. I hacked in the translated text above and sent the new client_thread ROM on its way.
Second, I have implemented all translated graphics in Single Pak Versus with the above limitations (see #8), so for now, I have no need to further research this compression routine (for now).
If anyone wants to research this compression:
It is located at 0x951D8 in the ROM, though it seems to be mirrored into RAM at 0x03003460 and executed there, in ARM (32-bit) mode, not THUMB!