Anonymous user
Escape sprite handling glitch: Difference between revisions
A word.
>Torchickens (Created page with "{{Misc R/B}} The '''escape sprite handling glitch''' (coined by Pigdevil2010 as the '''Escape Rope sprite handling glitch''') is a glitch in {{RGBY}}. When the player use...") |
old->Bbbbbbbbba (A word.) |
||
| (3 intermediate revisions by 3 users not shown) | |||
Line 1:
{{Misc R/B}}
The '''escape sprite handling glitch''' (coined by Pigdevil2010 as the '''Escape Rope sprite handling glitch''') is a [[natural glitch]] in {{RGBY}}.
When the player uses Teleport, Escape Rope or Dig to escape from an area outside of Super Game Boy or Game Boy Color mode (however, a Game Boy Color or Game Boy Advance playing {{RB}} is apparently fine), the player's sprite may temporarily be replaced with a flipped "ABCD" square in English versions, or a flipped "アイウエ" square in Japanese versions during the escape animation.
Line 6:
[[File:Escape sprite handling glitch JP.gif]]
[[File:Escape sprite handling glitch EN.gif]]
==Explanation==
To display the Start menu, the game needs to load the tileset used for text, which overwrites half of the tileset used for overworld sprites. Specifically, the "walking" frames of sprites are overwritten. NPCs respond to this by reverting to the "standing" state whenever the tileset for text is loaded. The player sprite does not check the tileset, but normally it's impossible to open the Start menu (or display any sort of text) in the middle of a player step, so it's not a problem.
The problem comes from the code that handles the animation of the escape item. The player is supposed to first spin in place for a while, then start to move up while continuing spinning. For both parts of the animation, the function SpinPlayerSprite is used to change the facing of the player. That function assumes that the 4 byte list wFacingDirectionList has been initialized to some cyclic permutation of $00, $08, $04, $0C (down, left, up, right), with hl pointing into somewhere into the list. This is indeed the case for the first part of the animation.
However, for the second part of the animation, hl is erroneously left pointing to somewhere else, namely, wPlayerSpinWhileMovingUpOrDownAnimFrameDelay. This value is explicitly set to 2 on SGB, and 3 otherwise. Therefore, SpinPlayerSprite would futilely shift wFacingDirectionList around, while setting the player's facing byte to $02 or $03 depending on the platform.
("Facing values" that are not a multiple of 4 are used for the walking animation, which consists of 4 frames. For walking down, those are standing, walking, standing, walking and flipped (to "move the other foot"), corresponding to $00, $01, $02, $03 respectively.)
On SGB things seem fine, because $02 is just another name for $00 (facing down, standing), so the player just move off the top of screen without spinning. On other platforms, however, the facing byte is set to $03 (facing down, walking, flipped), but the corresponding tile has been overwritten, and hasn't been reloaded yet. Therefore the sprite is displayed as a flipped "ABCD" square.
The same programming error happens when the player arrives at the warp destination; however, by that time the tileset is already properly reloaded, so the player just drops to the ground in a walking posture (non-SGB platform) or standing posture (SGB) without spinning.
==Youtube video==
{{Youtube|2gD3c954DRg|Pigdevil2010}}
| |||