Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation I Glitch Discussion

Two fixes for some glitch Pokemon front sprites via Gameshark - Page 1

Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Nerator
Date: 2014-05-06 13:48:24
1) This fix intended for pokemon, who have sprite size 0x0 (ex. Y:0xBF (4 4), Y:0xD9()). This also works for RB:0xC4 (PokeWTRAINER), even though his sprite size is 5x0
0155C2D0 for Red/Blue
0155C1D0 for Yellow

2) This fix is for pokemon, whose first byte at their sprite data is 00 (ex. Yellow Missingno. and other pokemon with dex entry #0 in Yellow)
0120A3D0
0120A4D0 for Red/Blue (not sure, if such pokemon exists in R/B)
0120A2D0
0120A3D0 for Yellow

Not sure, if all this stuff was already known, just wanted to document it here.

P.S. Btw, PokeWTRAINER has a lovely cry :)

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Ketsuban
Date: 2014-05-08 16:38:41
(not sure, if such pokemon exists in R/B)

'M

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Torchickens
Date: 2014-05-08 18:30:06

(not sure, if such pokemon exists in R/B)

'M


This is about the dimensions of the front sprite; the first sprite related byte in the Pokémon base stats data structure. 'Ms value for that is 8x8 blocks, so it doesn't cause a freeze, but glitch Pokémon that have a nybble of 0 in that byte may.

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Missingnoguy55
Date: 2014-05-08 19:03:39


(not sure, if such pokemon exists in R/B)

'M


This is about the dimensions of the front sprite; the first sprite related byte in the Pokémon base stats data structure. 'Ms value for that is 8x8 blocks, so it doesn't cause a freeze, but glitch Pokémon that have a nybble of 0 in that byte may.


I wonder if that's the reason why 'M and MissingNo. crash in Red/Green. Maybe the byte was changed? Cause I remember Pokémon with no front sprite crash in Red/Green.

Also, this code works nicely. It seems this code also fixes F5 (Channeler) and its back sprite which would always crash the game. This is gonna help a lot.

[img]https://dl.dropboxusercontent.com/u/73775541/bgb00004.bmp[/img]

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Nerator
Date: 2014-05-09 06:26:12


(not sure, if such pokemon exists in R/B)

'M


This is about the dimensions of the front sprite; the first sprite related byte in the Pokémon base stats data structure. 'Ms value for that is 8x8 blocks, so it doesn't cause a freeze, but glitch Pokémon that have a nybble of 0 in that byte may.

Not entirely true. I meant first byte in actual sprite data, where pointer, defined in base stats points to.

Let's look at Yellow Missingno., for example. Pointer to front sprite for it is 0x0006. Subroutine _UncompressSpriteData (0:251a for RB) reads first byte from there and after some math writes sprite dimensions at 0xD0A3 & 0xD0A4 (0xD0A2 & 0xD0A3 for Yellow). Value at 0x0006 is always 00 (as it is rom header), so this causes too much data copied during sprite uncompression and causes different crashes.

In RB only sprite i could find with such properties is indeed back sprite of 0xF5 (), which can be fixed by fix #2

For 'M (0x00 one, as 0xFF & 0xFE are hybrids), his pointer to front sprite is 0x1900 and it's value is 0xDD. While it's still high, it doesn't seem to cause crashes.

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: camper
Date: 2014-05-09 11:31:37
So Yellow Missingno. copies some data 256 times and overwrites too much memory and crashes the game?

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Nerator
Date: 2014-05-09 15:11:49

So Yellow Missingno. copies some data 256 times and overwrites too much memory and crashes the game?

I believe that's what happens. It can explain delay when you start fight with it. I tried using debugger to see why exactly crash happens, and saw that subroutine copied data to SPRITEBUFFER1 (at 0xA188) i believe all the way to 0xCxxx, but i still didn't figure out why it crashes. I guess in some time while uncompressing (may be VBlankHandler has something to do with this, not entirely sure, when this is called, but it was) it messes up the stack and it causes PC return to somewhere it shouldn't, causing either unknown opcode crash or FF crash (infinite loop).

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Stackout
Date: 2014-05-10 12:47:55

I believe that's what happens. It can explain delay when you start fight with it. I tried using debugger to see why exactly crash happens, and saw that subroutine copied data to SPRITEBUFFER1 (at 0xA188) i believe all the way to 0xCxxx, but i still didn't figure out why it crashes. I guess in some time while uncompressing (may be VBlankHandler has something to do with this, not entirely sure, when this is called, but it was) it messes up the stack and it causes PC return to somewhere it shouldn't, causing either unknown opcode crash or FF crash (infinite loop).


I figured this out a while ago, but I couldn't figure out why it was crashing, except the crash occured somewhere in VBlankHandler.

Re: Two fixes for some glitch Pokemon front sprites via Gameshark

Posted by: Nerator
Date: 2014-05-10 20:45:38


I believe that's what happens. It can explain delay when you start fight with it. I tried using debugger to see why exactly crash happens, and saw that subroutine copied data to SPRITEBUFFER1 (at 0xA188) i believe all the way to 0xCxxx, but i still didn't figure out why it crashes. I guess in some time while uncompressing (may be VBlankHandler has something to do with this, not entirely sure, when this is called, but it was) it messes up the stack and it causes PC return to somewhere it shouldn't, causing either unknown opcode crash or FF crash (infinite loop).


I figured this out a while ago, but I couldn't figure out why it was crashing, except the crash occured somewhere in VBlankHandler.

Main difference is subroutines, where overflow happens. In case of PokeWTRAINER (or any pokemon with base sprite sizes 0xX, Xx0 or 0x0) it happens in AlignSpriteDataCentered; in case of Yellow Missingno it happens in UncompressSpriteData. Main problem, that i can't figure out, how this damn VBlankHandler works. And in bgb it's hard to backtrack why PC is changing to what it should not.