NPC collision bypassing glitch
The NPC collision bypassing glitch is a glitch in Pokémon Red and Blue that allows an NPC to walk through another NPC or object. It is a rare glitch that is hard to reproduce because it is both frame-perfect and dependent on the random timing (as well as direction) for the walking NPC.
The first known instance of this glitch was documented by Roelof and recorded by ChickasaurusGL, in which an NPC would walk through the Cable Club lady. It was later discovered[1] that this glitch is related to the sprite update order, as well as how the game handles sprites temporarily hidden by a text box or a screen border.
Text box method
This glitch can be recreated if the following criteria are met:
- A text box pops up exactly at the frame when the walking NPC was ready to move, but hadn't decided in which direction yet.
- The text box obscures the sprite that would be in the way of the walking NPC.
- The walking NPC has lower ID than the other sprite.
When the text box is closed, the walking NPC would be updated before the other sprite becomes visible again, triggering this glitch. The most convenient text box to trigger this glitch is the Start menu, but other text boxes, such as the PC interface, can also be used.
This glitch can be also triggered by saving the game when the other sprite is obscured, and resetting; indeed, it was first reproduced from a save file. This also allows the player to use the saving interface (which covers more area on the screen than just the Start menu) or the box-changing interface (which covers the entire screen) to obscure the sprite.
Screen border method
Instead of using a text box, it's possible to use a border of the screen to obscure both or one of the sprites. There are two variants of this method.
Both of the following methods work on the same principle as the text box method. As such, they still require the walking NPC to have lower ID than the other sprite.
"Dead" border method
In this method, the player moves to a position so that both sprites are on the top or left border of the screen. Then, the player walks away from the border, leaving both sprites off-screen at the critical frame. When the player walks back so that both sprites are on-screen again, this glitch may happen.
For example, in the screenshot on the right, if the player walks down at a specific timing, then walks back up, the dark-haired NPC may walk into the light-haired NPC.
This method doesn't work with the right or bottom border of the screen, because when on those borders, the NPC cannot walk along the border, only away from it.
"Live" border method
In this method, the player moves to a position so that the walking NPC is on a border of the screen, and the other sprite is adjacent to the walking NPC, but off-screen. Then, the player walks towards the border, so that the other sprite becomes on-screen at the critical frame. This glitch may happen.
For example, in the screenshot on the right, if the player walks up at a specific timing, the NPC may walk through the Cable Club lady.
This method should work with all four borders of the screen.
Reproduction with emulator
This glitch is rare because of the strict timing on opening the text box or making the critical step, which depends on the random walking delay of NPCs. It is possible to recreate the glitch on an emulator by observing the correct memory address at wSpriteStateData2 (represented by $C2x8) for the walking NPC (for example, $C228 for the walking NPC in the Cerulean City Pokémon Center). This address can easily be identified, because whenever it goes down to 0x00, the walking NPC will make their next step. Depending on the method used to trigger the glitch, the timings for the critical input may be different:
- For the Start menu, the Start button should be pressed when $C2x8 is 0x01. It will have decreased to 0x00 when the Start menu is actually open.
- For the PC, the A button should be pressed on the frame $C2x8 becomes 0x00.
- For the "dead" border method, the direction to move away from the border should be pressed when $C2x8 is 0x08. Since it takes 8 "overworld frames" for the player to walk a step, when the player finishes the step and makes the sprites invisible, $C2x8 will have decreased to 0x00.
- For the "live" border method, the direction to move towards the border should be pressed when $C2x8 is 0x08. Similar to above, when the player finishes the step, $C2x8 will have decreased to 0x00.
Notice that the "live" border method may be the most difficult to do on an emulator, especially if you are unlucky. This is because for the other methods, there is always a period of "dead" time, during which the RNG advances but the sprites don't (when the text box is open, after resetting but before choosing "Continue" on the main menu, or when both sprites are off-screen). By making a save state during the "dead" time, and waiting a different amount of time before doing the final step, the RNG can be easily manipulated so that the walking NPC will walk in the desired direction. For the "live" method, there is no such "dead" time, so the RNG may need to be manipulated in some way other than delaying.
Youtube video
| |