1. Dylan Morrison Avatar Dylan Morrison
  2. Untitled project
  3. DancingMad
  4. Issues

"Equip Screen" bug

Issue #9 invalid
Dan Yetman created an issue

I'm not certain how to describe this one, so I'm including a link to the video.

Equip Screen Bug

This may be related to a few minor graphics glitches that I've seen here and there. I'm using the latest e78864e commit on an SD2SNES plugged into an NTSC SNES Mini, and on Character Name screens, by holding left or right to continually scroll the cursor, a brief graphical glitch, similar to the one in the video but nowhere near as large nor continuous, can be reproduced at regular intervals.

In addition, pressing L or R on the "Status Screen" will cause an even more minor, but noticeable glitch to occur with each press.

It is my belief that these glitches are related to each other. I'm not totally certain what the issue is.

Comments (16)

  3. Dylan Morrison repo owner

    That is a really odd bug considering we aren't touching the graphics code at all... Hmm. It may have something to do with my stubbed NMI handler. I might try pulling that out for the time being but if we have to remove it completely that means fading will never be right. (because I won't be able to change volume over time). The problem with the NMI (which is when graphics are drawn, thus my conclusion that this may by the issue) is that you only have the duration of a TV VBlank in which to process it. Any NMI handling routine that adds to the original one in the game, which mine does, decreases the amount of time the game has in the VBlank to process these instructions.

    Mine is currently just a stub, something to allow me to add more later, but if even the stub is causing issues, that would be bad. Anyway, I'm going to try removing the stub entirely and we'll see what happens. If that still doesn't fix things then the issue is elsewhere and that's even worse because at that point I have no easy idea what it could be.

    Attempted fix has been committed to experimental as commit cde8fd3. Please report back on this one as soon as you can because if this doesn't fix this, I want to revert the change, and need to consider other possible causes.

  4. Dylan Morrison repo owner

    Somehow in the commit to fix this bug I reintroduced the save bug, for some reason lda MSULastTrackSet got changed to lda MSUCurrentTrack in the track comparison routine. So instead of commit cde8fd3 please test the latest experimental commit e4bc37b.

  7. Dylan Morrison repo owner

    Darn. Well, good news and bad news then. Good news is that my NMI routine isn't causing graphical bugs, bad news is that something else is. Can you try this on the other SNESes you mentioned owning and see if it happens on them as well? I can't get it to reproduce on Higan for sure.

  8. Dylan Morrison repo owner

    Oh, also important, please make sure this does not happen on an unpatched version of the ROM on the same system.

  9. Dan Yetman reporter

    I'll check. I had a thought, though, that this is probably related to VBlank. It's like the screen is constantly trying to refresh itself, as the issue bears some slight resemblance to the fade in and fade out of switching menus. No idea why it only affects those few places though.

  10. Dylan Morrison repo owner

    Right, which would make sense if removing the NMI code had fixed it. (The NMI code interacts during VBlank). But since removing the NMI code, and thus making it so we aren't actually doing anything during VBlank, didn't fix it that leaves me with no real idea what could be causing this.

    My biggest thought is that maybe it's taking so long for tracks to load (in cycle terms, .7ms is still a long time on a CPU firing 3 million times a second) that it's triggering VBlanks during the track loading process, and that somehow this is causing problems because the game's own normal NMI code is triggering during bits where the game is not in normal execution (since it's stuck in my code).

    The best solution to this, if this is indeed the problem, would be disabling the NMI during track loading. But this would mean turning off the screen. Which is a rather drastic step to take.

    For what it's worth, I'm reading the Chrono Trigger MSU-1 hack's code, and the way it handles track loading is almost identical to the way I do, so this is odd that it would cause problems for FF6 but not CT, given they're both Square games running on similar engines.

  11. Dylan Morrison repo owner

    Addendum re above bit about the track loading busy check and the NMI: I can't actually check if this is a problem with higan or bsnes because, as ikari let me know, instead of ever reporting MSU1_AUDIO_BUSY, both emulators simply halt emulation during the loading of tracks, so there's no way to find out what exactly is going on during track loads on a system where they're not happening "instantly" from the point of view of the SNES.

    Just based on another hunch, I tried to go into the Equip screen in a debugger and screw around while having breakpoints set on all of the areas of RAM I'm using. None of them were touched. So yeah, I'm just really confused as to why this is breaking.

  12. Dylan Morrison repo owner

    Okay, this could completely break things or cause other enormous graphical or game issues, but shot in the dark I'm going to try disabling VBlank/NMI during the MSU-1 code, and then re-enabling VBlank/NMI at the end of the MSU routine.

    I'd ask that you complete testing for this bug on your other SNESes before you try this, but the new, shot-in-the-dark attempted fix is in commit f5f4d8f. I can't state this enough, I'm messing with stuff I shouldn't be messing with during sound code at this point so this could definitely cause more problems than it fixes, but if it fixes the issue then we at least know where to start.

    Doing this NMI disable and re-enable trickery doesn't seem to cause graphical issues in a very quick test on Higan, but yeah, I wouldn't trust it.

    EDIT: Okay, yes it does cause graphical issues in Higan. Major, intermittent ones. Whee. But still, if it fixes your issue then we've found something.

  13. Dan Yetman reporter

    Before I check this out, I want to clear something up. For the first test I did on the SD2SNES, I used the installer, and since then, I've just been downloading the patches by themselves. But, is the installer doing anything else to the ROM aside, bit wise, aside from applying the patch? I'm wondering in my methodology is flawed.

  14. Dan Yetman reporter

    UPDATE: It's not your patch! I just tried the famous SkyRender FFVI translation, a NON-MSU1 release from more than a decade ago, and I get the same thing! I then plugged my original FFIII copy into my SNES to make certain that it's not the system - it's not. I then checked the vanilla, unenhanced basic 1.0 ROM. The 'EQUIP' bug is still there. I then downgraded my SD2SNES firmware from 0.1.7p4 to 0.1.6 - FIXED.

    There is some hanky-panky going on with how the preview firmware affects things. It's not actually on your end - it's on ikari's.

    I'm going to revert back to the earliest working patch, which I believe was commit e78864e, to verify right now.

    EDIT: VERIFIED. The e78864e commit works quite nicely with the 0.1.6 SD2SNES firmware, with none of the graphical glitches apparent in the 0.1.7p4 version.

  15. Dylan Morrison repo owner

    Thank god. And thank you for being so thorough with your testing. I'm going to revert the changes I did to try to fix this one then and for now I'm going to recommend people use 0.1.6.

    Also yes, your methodology is fine. The installler is mostly for grabbing the music and moving all the files to the right place.

    I just let ikari know via email of the bug in 0.1.7p4.

  17. Log in to comment
Assignee
Type
bug
Priority
critical
Status
invalid
Component
Patch
Milestone
Alpha
Votes
0
Watchers
1
Jira Software: the preferred issue tracker for Bitbucket. Join the team!