Sprite decompression (Generation I): Difference between revisions

In {{RBY}}, all front and back sprites of Pokémon and Trainers are stored in a compressed form in the ROM, and are decompressed only when used<ref>[https://github.com/pret/pokered/blob/4e96f9d232cd51be9d51a76f7d0cc6211aaccdca/home/uncompress.asm#L21 The main function for decompressing Pokémon sprites]</ref>. The compression format first uses one of several different forms of differential encoding to increase the number of zero bits in the data, then encodes the data using a run-length encoding (RLE) on zero bits. The decompression routine makes use of part of SRAM bank 0 as a buffer, meaning that it needs to unlock the SRAM beforehand<ref>[https://github.com/pret/pokered/blob/4e96f9d232cd51be9d51a76f7d0cc6211aaccdca/home/uncompress.asm#L10-L13 The piece of code to unlock the SRAM and switch to bank 0 for sprite decompression in Red/Blue]</ref>, but in Red/Blue it never locks the SRAM afterwards<ref>Yellow [https://github.com/pret/pokeyellow/blob/2f00afe9352ff9b71d5854f18ca5356905cf2ef8/home/uncompress.asm#L12 does correctly lock the SRAM after decompressing a sprite].</ref>, making it easier for glitches to corrupt SRAM bank 0 (and to a lesser extent, the SRAM in general). Furthermore, the decompression routine does not check the size of the sprite adequately, so when decompressing sprites of glitch Pokémon or Trainers, the routine itself can easily overflow the buffer and cause [[Pokémon sprite corruptions (Generation I)|various memory corruptions]], most famously in the Hall of Fame (which is stored in SRAM bank 0 after the buffer), but also in the WRAM if the sprite is large enough.