57
edits
Talk:ZZAZZ glitch: Difference between revisions
→Pattern
Bbbbbbbbba (talk | contribs) |
Bbbbbbbbba (talk | contribs) |
||
| Line 5: | Line 5: | ||
:Having played with the game code a fair bit, this seems familiar to me: I suspect it's actually the graphic decompression routine gone out of control due to the Pokémon having garbage graphic data. The graphic compression routines include commands such as "fill with 2-byte pattern" (0099 in this case) and "fill with byte, skipping every third." These exactly match the symptoms. Another hint is that it corrupts the player's trainer and Pokémon graphics - the first place an out-of-control graphic decompression routine is going to trash is the other graphics right nearby. [[User:HyperHacker|HyperHacker]] 03:45, 16 December 2009 (UTC) | :Having played with the game code a fair bit, this seems familiar to me: I suspect it's actually the graphic decompression routine gone out of control due to the Pokémon having garbage graphic data. The graphic compression routines include commands such as "fill with 2-byte pattern" (0099 in this case) and "fill with byte, skipping every third." These exactly match the symptoms. Another hint is that it corrupts the player's trainer and Pokémon graphics - the first place an out-of-control graphic decompression routine is going to trash is the other graphics right nearby. [[User:HyperHacker|HyperHacker]] 03:45, 16 December 2009 (UTC) | ||
::[[User:HyperHacker|HyperHacker]], it seems that your first guess is more correct... With the help of an emulator, I just pinpointed the instruction directly doing the damage, and it was at f82d (3:782d), in the BCDAdd routine. It was the loop used to set the result to 999999 in the event of an overflow (like how your money wouldn't increase beyond 999999). BCDAdd is designed to handle BCDs with different sizes, which, I guess, is why it can rewrite things in different patterns. The calls to BCDAdd are coming from 39d18 (e:5d18). I'm currently trying to understand what that call is intended to do... [[User:Bbbbbbbbba|Bbbbbbbbba]] ([[User talk:Bbbbbbbbba|talk]]) 18:50, 3 May 2014 (UTC) | ::[[User:HyperHacker|HyperHacker]], it seems that your first guess is more correct... With the help of an emulator, I just pinpointed the instruction directly doing the damage, and it was at f82d (3:782d), in the BCDAdd routine. It was the loop used to set the result to 999999 in the event of an overflow (like how your money wouldn't increase beyond 999999). BCDAdd is designed to handle BCDs with different sizes, which, I guess, is why it can rewrite things in different patterns. The calls to BCDAdd are coming from 39d18 (e:5d18). I'm currently trying to understand what that call is intended to do... Edit: probably that portion of code (around 39d18) just deserves to lose. It uses the value of register de immediately after calling BCDAdd, which is not smart: the meaning of that value depends on whether an overflow happened... [[User:Bbbbbbbbba|Bbbbbbbbba]] ([[User talk:Bbbbbbbbba|talk]]) 18:50, 3 May 2014 (UTC) | ||
==Yellow== | ==Yellow== | ||