Glitch City Laboratories Archives

So I've been looking into this glitch…
https://www.youtube.com/watch?v=I_JjAIvG9zA

The thing is, there are a total of 11 sprites in the oak's lab before getting your first Pokemon: 2 Pokedex, Oak, Blue, 3 Pokeballs, a lady, 2 scientists, and yourself. That's one more than the number allowed to be displayed at once, as the OAM buffer can only hold data for 40 objects (fe00-fe9f) and each sprite is made of 4.

There is a 10-half-block vertical separation between the two dexes and the two scientists though, meaning they should never be all displayed at once, EXCEPT when you are four half-blocks above the scientists and walk up, or when you are four half-blocks below the dexes and walk down. In these cases, parts of all four sprites are on screen as the background map scrolls during your movement.

The issue comes from the clear unused OAM routine: https://github.com/pret/pokered/blob/2b2c6fe/engine/overworld/oam.asm#L147
If there are 11 sprites, hOAMBufferOffset is going to end up becoming $b0 given that PrepareOAMData is taking care of what would be a total of 44 objects ($00 to $af). Normally, it should be multiples of $10 from $00 through $a0. The game would then attempt to clear unused OAM data starting from what should be the last sprite in use, indicated by hOAMBufferOffset. If there are, say, 6 sprites on screen, every four bytes from $c360 to $c3a0 are set to $a0 in order to make all those sprites invisible in the wram sprite buffer (y coordinate of $a0 is just below the screen). If there are 11 sprites, however, every four bytes from $c3b0 through $c4a0 are going to become corrupted with $a0 because the game won't stop until the lower byte of the address equals $a0 (supposed to be the address of the last sprite when preceded by $c3). With the tilemap starting at $c3a0, this leads to the screen getting corrupted with character "a" every four tiles.

Most of the times, however, the scientists are alrealdy invisible by the time the pokedexes show up, so there are never more than 9 sprites overlapping. But it's not always, given that the glitch pops up every once in a while, which leaves me wondering, what is the timing factor that leads to the pokedex sprites appearing when the scientists are still considered to be visible?

Anyway, after that, some sprites seemingly at random became invisible, leaving only a total of five on screen, but I haven't really looked beyond that. So yeah, has anyone been able to figure out more than me about this mysterious glitch?

EDIT: Figured out why the sprites disappear. If they are above one of the corrupted tiles, the tile will have a value higher than $60 (because they were corrupted with $a0), so the game thinks they are hidden by a text box: https://github.com/pret/pokered/blob/master/engine/overworld/movement.asm#L508

Beware not to mistake the Game Boy's sprites with the game's logical sprites. Usually one game sprite represents four Game Boy sprites.

[li]Run overworld code that will edit Game OAM[/li]
[li]"Decompress" each Game sprite into four sprites, and write them to the Pseudo-OAM[/li]
[li]Use a DMA transfer to commit that to the actual OAM[/li]
[li]The GB's video driver takes care of the rest[/li]

First, you swapped Game sprites and GB sprites. 1 Game sprite uses 4 GB sprites. The GB can display 40 sprites, with their data being taken from a memory area known as the OAM (refer to this). Accessing the OAM is quite a pain, so the game writes some GB sprite data to a buffer in RAM, which I'll refer to as the Pseudo-OAM, then uses a feature known as DMA transfer to commit data to the actual OAM.

Still according to the same page, vertical values >= 160 ($A0) are out of bounds and thus won't be displayed. So, to hide a sprite, the game places it out of bounds.

However, GB sprites are 8x8, and that's really small ! So, the programmers decided that, for the overworld, sprites would be grouped in 2x2 squares (16x16 pixels). Thus, they created a buffer I'll refer to as Game OAM, which holds data for the 16x16 pseudo-sprites (plus some metadata like movement).

The usual cycle works like so :

[li]Run overworld code that will edit Game OAM[/li]
[li]"Decompress" each Game sprite into four sprites, and write them to the Pseudo-OAM[/li]
[li]Use a DMA transfer to commit that to the actual OAM[/li]
[li]The GB's video driver takes care of the rest[/li]

What happens here is that 11 Game Sprites are loaded, so when the game tries to clean their Pseudo-Sprites, it cleans data that is located right past the Pseudo-OAM. Tiles being corrupted in a one-per-four pattern comes from GB sprite structure being 4 bytes long. The game simply alters what it believes to be vertical positions to $A0.


Keep in mind, BGB / VBA cannot display you the Game OAM nor the Pseudo-OAM because they are game-specific, they can only display you the OAM, the real one.