Scrambled graphics in G/S when interacting with dialog boxes using autofire? - Page 1
When playing on emulator, I tend to speed my way through dialogue boxes by enabling autofire for A or B and pressing space to speed up the game for a second or so. I've had a few instances where, right after e.g. defeating a trainer, the screen graphics became completely garbled for a (very brief, because I was holding the speedup hotkey) second. After the third time this happened, I wanted to try to systematically reproduce this, and behold the below screenshot of my Pokémon Silver…
What I did here was simply hold the autofire A button and talk to Nurse Joy, healing my Pokémon about 15 times in a row with zero time in between (because of autofire).
Any ideas what is happening here?
I had this happen before, and this is just a bug in some of the older versions of VBA. When displaying textboxes on turbo mode, the tilemap will sometimes get corrupted. It does not seem to happen consistently - I once created a VBM movie file with the bug occuring, but after restarting the emulator and playing it back, the problem magically disappeared.
I don't really know the cause of this. By doing some analysis on the screenshot above we can discover some patterns:
- Everything gets changed: tile data, pallettes and tile attributes (some of the tiles are flipped)
- Almost every 4th tile is ID 0x40, X-flipped
- Tiles are arranged in columns: in the 3rd column, tile 0x40 is the most frequent; in the 4th column, tile 0x02 is the most frequent, and so on. Every column consistently has a most frequent tile.
- The textbox displays fine, so the code that triggers the bug happens before the textbox gets rendered
I searched the ROM for patterns with 4th, 8th and 12th byte set to 0x40, and while I did in fact find some matches, they don't look anything like the corruptions I was able to get.
Could you grab a memory dump after the bug happens and post it here? If this sounds like wizardry to you:
1. Go to Tools > Memory viewer
2. Click "Save…"
3. Type in: Address 0000, size FFFF
4. Give the file some clever name, save it and post it
Attached a zip file with:
- a VBA movie that reliably triggers the glitch for me;
- a screenshot of a second occurrence that happened during playback of that movie;
- the requested memory dump, of this second occurrence.
It looks like this may indeed be emulation error; while the corruption in my first screenshot still appears consistently reproducible in the VBA movie, this second type of corruption has only happened this one time when I was getting ready to dump the memory. But, in case it matters, this happened at nighttime (Nurse Joy says "you're out late") whereas the corruption I reported in the OP happened at daytime.
In any case, hope the memory dump can shed some light. I'm using a self-compiled version of VBA-M (playing on the WX frontend, although the MFC frontend will play the movie with the same corruption). Despite the screenshot suggesting otherwise, the VBA-M revision is the latest Subversion - r1507.