Anonymous user
Sprite decompression (Generation I): Difference between revisions
Sprite decompression (Generation I) (view source)
Revision as of 11:06, 9 September 2022
, 1 year ago→Sprite size: Added explanation of the actual sprite size and the base stats sprite size, and memory corruption (especially the conditions for memory corruption).
m (Changed the external links to embedded videos (after getting permission from Retro Game Mechanics Explained)) |
(→Sprite size: Added explanation of the actual sprite size and the base stats sprite size, and memory corruption (especially the conditions for memory corruption).) |
||
Line 33:
== Sprite size ==
As mentioned above, the size of each valid Pokémon sprite is stored in two ways:
* As the first byte of the compressed data stream, with the high nybble indicating the width and the low nybble indicating the height. For example, for a 5×5 sprite, the value of this byte will be 0x55.
* For front sprites, there is a byte indicating the sprite size in the base stats data structure, with the high nybble indicating the ''height'' and the low nybble indicating the ''width'' (this is the opposite way around compared to the other byte, although for valid Pokémon sprites this does not actually matter since they all have equal width and height). Back sprites are always assumed to be 4×4 before scaling.
For glitch Pokémon, those two sizes often mismatch. The size indicated first byte of the compressed data stream is often called the '''actual sprite size''', and the size indicated by the byte in the base stats data structure is often called the '''base stats sprite size'''. The front and back sprites for a glitch Pokémon each has its own actual sprite size, but there is only one base stats sprite size for the front sprite. Pokémon from the same [[family]] always share the same base stats sprite size, but their sprites may be different since those sprite data may be in different banks (even though they share the same two-byte pointer), in which case each sprite will have its own actual size.
The actual sprite size determines whether the sprite causes memory corruption, and how much. For an actual sprite size of ''w''×''h'', the sprite decompression routine will always read data from the input stream until it has output (''w''×8)×(''h''×8) bits, i.e., ''w''×''h''×8 bytes, for each of the two bit planes. Each bit plane is written to a contiguous region in the memory, starting from <code>sSpriteBuffer1</code> and <code>sSpriteBuffer2</code> respectively, meaning that they will overlap each other if ''w''×''h'' > 49. Then the bit planes are unpacked by operating on the same memory regions. Both decoding and unpacking are handled with double loops, and both ''w'' and ''h'' must be in the range of 0–15 since they are nybbles, so the only relevant possibility of arithmetic overflow is that when (''w''×8) and/or (''h''×8) are 0, they are treated as if they were 256, or equivalently that '''when ''w'' and/or ''h'' are 0, they are treated as if they were 32.'''
Since the distance between <code>sSpriteBuffer2</code> and the start of the Hall of Fame data is 392+256 = 648, Hall of Fame corruption will happen when ''w''×''h''×8 > 648, i.e., ''w''×''h'' > 81. Meanwhile, WRAM corruption will only happen when ''w''×''h'' > 926, which is only possible for a sprite with actual size 0×0 (e.g., Yellow [[MissingNo.]]), where both ''w'' and ''h'' are treated as 32. If WRAM corruption does happen, it will affect WRAM addresses up to $C30F, which contain variables used by the sound engine as well as some sprite data<ref>[https://github.com/pret/pokered/blob/bbb0e7e82deb6741f75a12b48f81076d92f5d9dc/ram/wram.asm#L1-L149 The range of WRAM addresses that can be affected by sprite corruption], up to and including the entire 4-byte structure <code>wShadowOAMSprite03</code></ref>. Corruption of those data is the causes of [[Pokémon_sprite_corruptions#Sound_and/or_sound_bank_corruption|sound and/or sound bank corruption]] and the [[walking characters effect]] respectively.
== Run-length decoding ==
| |||