3 ms·

The rooms' data compression remind me of the Pokémon sprites during battles in Pokémon Gen I/II (Red/Blue(/green) and G/S/Y). As I remember it, the in-battle sp

The rooms' data compression remind me of the Pokémon sprites during battles in Pokémon Gen I/II (Red/Blue(/green) and G/S/Y). As I remember it, the in-battle sprites (which are fairly large) are "compressed" using a custom algorithm. IIRC, it does RLE, and has some facilities for doing dithering, which was used in a lot of the sprites to give the impression of more color depth than there actually was. And they were only 4-bit (white, black, and two colors) in G/S/Y!

wgjordan 7y ago
That brings back memories! I actually reverse-engineered that exact sprite compression (at least the G/S variant) back in 2001, when I was involved in the early ROM hacking community [1]. I stared at disassembled Z80 machine code for many, many hours to figure out and document the various quirks. I wrote a decompression program in (terrible, self-taught) QBasic, the only programming environment I had access to / knowledge of back then. [1] https://www.romhacking.net/utilities/59/ https://www.romhacking.net/utilities/59/
- kemenaran 7y ago
  Oh, nice! The compression algorithm is said to have been written by Satoru Iwata himself, giving a hand to the overloaded GameFreak team when the development of Pokémon G/S was hitting size limits pretty badly [1]. There is a readable version of the decompression routines in the Pokémon G/S disassembly repo [2]. As the code was originally written in assembly, it is not decompiled–only re-documented. Which means the code we read is the actual code Iwata wrote it 20 years ago. I really like seeing the traces of actual human beings in a disassembly. Noticing different coding styles; seeing where routines were written, then patched over later… We read code, but we see people. [1] https://retrocomputing.stackexchange.com/questions/11476/how-did-satoru-iwata-compress-pokemon-gs-to-fit-two-regions-on-a-single-cartridg https://retrocomputing.stackexchange.com/questions/11476/how... [2] https://github.com/pret/pokered/blob/10289bf/home/pic.asm https://github.com/pret/pokered/blob/10289bf/home/pic.asm
Narishma 7y ago
I think you mean 2-bit. 4-bit is 16 colors.
- deathanatos 7y ago
  Oh, yes, you are correct!

wgjordan 7y ago

That brings back memories! I actually reverse-engineered that exact sprite compression (at least the G/S variant) back in 2001, when I was involved in the early ROM hacking community [1]. I stared at disassembled Z80 machine code for many, many hours to figure out and document the various quirks. I wrote a decompression program in (terrible, self-taught) QBasic, the only programming environment I had access to / knowledge of back then. [1] https://www.romhacking.net/utilities/59/ https://www.romhacking.net/utilities/59/

kemenaran 7y ago
Oh, nice! The compression algorithm is said to have been written by Satoru Iwata himself, giving a hand to the overloaded GameFreak team when the development of Pokémon G/S was hitting size limits pretty badly [1]. There is a readable version of the decompression routines in the Pokémon G/S disassembly repo [2]. As the code was originally written in assembly, it is not decompiled–only re-documented. Which means the code we read is the actual code Iwata wrote it 20 years ago. I really like seeing the traces of actual human beings in a disassembly. Noticing different coding styles; seeing where routines were written, then patched over later… We read code, but we see people. [1] https://retrocomputing.stackexchange.com/questions/11476/how-did-satoru-iwata-compress-pokemon-gs-to-fit-two-regions-on-a-single-cartridg https://retrocomputing.stackexchange.com/questions/11476/how... [2] https://github.com/pret/pokered/blob/10289bf/home/pic.asm https://github.com/pret/pokered/blob/10289bf/home/pic.asm

Narishma 7y ago

I think you mean 2-bit. 4-bit is 16 colors.

deathanatos 7y ago
Oh, yes, you are correct!