nesdev.org

Thanks for your help Doug

dougeff wrote:EDIT2 - yes. Your title / pre-game code checks for the Start button about 3-4 frames before the Lives / Score and Sprite Zero collision tile are loaded.

So the sprite0 check is not supposed to happen on the open screen. I have a flag called open_screen_active that should be set at the end of the reset code to '1'. If the value is 1 it should skip the sprite0 code. If I go into the Mesen menu and tell it to reset from there, everything works fine. The flag is set, and there is no sprite0 check on the open screen (as it should be).

If I use the start button on game over to call the reset, for some reason that flag is not set to 1, but is 0 so the sprite0 code runs.

If I put a debug break point in the start button press and step through it with the debugger, everything works fine and the flag is set as it's supposed to be.

Not that I'm typing this out, I wonder if I'm calling that start button code more than once and therefore calling the reset multiple times in a row. Will need to investigate.

dougeff wrote:On a side note. You might want to make the "lives" lower on the screen. Old CRT TVs will tend to cut off some of those pixels. See the "overscan" entry in the wiki.

I might do that. This is more of a personal research project and I'm not super concerned about the game running on old CRTs. I'm not sure anyone will actually be playing it on an old CRT, but I'll see what I can do.

Thanks again,
Rick

You're missing the point. The problem is you are doing things out of order. Although it is unlikely that the user will be holding the start button down at exactly the power on moment... if it crashes the game, it needs fixed, especially now that you restart the game by jumping to reset.

Either load the BG tiles as soon as possible, before buttons are ever read, ...or disable button presses until those tiles are loaded.

Or you could make Pressing Start the trigger to load the BG tiles in place, and disable Sprite zero hits until that is done.

The reason it doesn't happen during debugging is because it's difficult to hold down the Start button while you step through the game in a debugger.

And if all else fails, yet another way to avoid a freeze is to make the sprite 0 waiting loop resilient to failure, where you get a momentary graphical glitch instead.

dougeff wrote:Either load the BG tiles as soon as possible, before buttons are ever read, ...or disable button presses until those tiles are loaded.

Thanks Doug.

I fixed the issue, although not quite how you indicated. Basically I started pulling code out of the reset into a subroutine and called that from the start button press. This way I was able to move things in and out until the system either didn't clear everything I needed it to, or broke. I think part of the problem was that I was clearing all of memory and flags were getting overwritten at the wrong time.

Out of curiosity, how do you disable button presses? Can you do something to $4016 to disable the gamepad?

Thanks

battagline wrote:Can you do something to $4016 to disable the gamepad?

No, you just ignore any input in the game logic.

tokumaru wrote:No, you just ignore any input in the game logic.

In the future I should probably have a reset_complete flag that gets set to 1 after the reset finishes. I could probably key off of that for all the things that may run when they shouldn't during the reset.

Thanks

Good to hear you found it.

So it was a sprite 0 bug. I would have never guessed by debugging (I did check a little bit) since I never programmed one but I kind of knew it was something timing related since debugging caused it to make it work fine, somehow.