Spot bug in Mesen and Nintaco

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Spot bug in Mesen and Nintaco

Post by zeroone »

I noticed a strange bug in Mesen and Nintaco when running the game Spot.7z <Spot (U) [!].nes>. From the tile screen menu, choose: Select Options. The D-Pad or Select button should be able to move the cursor around the options menu, but they behave quite unresponsively. I did not notice this effect in other emulators.

Any ideas on what's special about this particular screen in this particular game regarding input?
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Spot bug in Mesen and Nintaco

Post by Sour »

Took a few minutes to check, but haven't figured it out. It works fine in PAL mode.
And most of all, it works fine when running the emulation at full speed instead of 60fps - and I simply can't make sense of that part.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Spot bug in Mesen and Nintaco

Post by zeroone »

Sour wrote:Took a few minutes to check, but haven't figured it out. It works fine in PAL mode.
And most of all, it works fine when running the emulation at full speed instead of 60fps - and I simply can't make sense of that part.
Interesting. In fact, Nintaco also has the same issue; it works with PAL, but not NTSC.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Spot bug in Mesen and Nintaco

Post by zeroone »

HalfNES also appears to be affected.
Mednafen
Posts: 60
Joined: Wed Sep 13, 2006 12:45 pm

Re: Spot bug in Mesen and Nintaco

Post by Mednafen »

The game is probably poorly written in such a way that updating emulated gamepad state only around a certain single point in a frame will cause input changes to be ignored by the game. Try updating state at NMI time instead of near line 0, or vice-versa, to check.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Spot bug in Mesen and Nintaco

Post by zeroone »

Mednafen wrote:The game is probably poorly written in such a way that updating emulated gamepad state only around a certain single point in a frame will cause input changes to be ignored by the game. Try updating state at NMI time instead of near line 0, or vice-versa, to check.
But, it's a loop. If the actual controller hardware is polled once a frame and that recorded state is made available to the controller ports at any time within the loop, how does it matter?
Mednafen
Posts: 60
Joined: Wed Sep 13, 2006 12:45 pm

Re: Spot bug in Mesen and Nintaco

Post by Mednafen »

1: Game reads input port, checks for changes from previous state.
2: Emulator updates emulated gamepad state.
3: Game reads input port again to set previous state variables.

With various lengths of time passing between the steps.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Spot bug in Mesen and Nintaco

Post by tepples »

At what (x, y) position do writes to $4016 occur in both emulators where the game works and emulators where it fails?
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Spot bug in Mesen and Nintaco

Post by zeroone »

Mednafen wrote:1: Game reads input port, checks for changes from previous state.
2: Emulator updates emulated gamepad state.
3: Game reads input port again to set previous state variables.

With various lengths of time passing between the steps.
If the game polls the controller ports twice within the same frame and it only looks for changes between those 2 polls, then it would occasionally fail to detect even on real hardware.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: Spot bug in Mesen and Nintaco

Post by Alyosha_TAS »

zeroone wrote:
Mednafen wrote:1: Game reads input port, checks for changes from previous state.
2: Emulator updates emulated gamepad state.
3: Game reads input port again to set previous state variables.

With various lengths of time passing between the steps.
If the game polls the controller ports twice within the same frame and it only looks for changes between those 2 polls, then it would occasionally fail to detect even on real hardware.
Only rarely. Since the total polling routine takes about 30 scanlines you have about a 10% change of this happening on hardware. But in NEStaco there seems to be about a 100% chance, since trace logger indicates that a 'frame' starts at scanline -1 but at that point 1 of the 3 controller polls has already taken place.

It's actually more of a mystery how it ever accepts any input, since this seems like it should fail every time. :?

Also when I was using trace logger, sometimes the trace would start at random scanlines, I'm not sure why.

EDIT: I should be clear that I am referring to what is happening in NESTaco.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Spot bug in Mesen and Nintaco

Post by Sour »

I think I finally understand what might be going on. Mesen polls the keyboard/gamepads every time it needs to update the NES controllers' state. There is no particular point in the frame where this occurs - however, since the frame is executed in a fraction of the time it takes on a real NES (e.g 2-3ms instead of 16ms), the odds of the input changing during the frame is pretty low. If the game expects the input to change between 2 points in the same frame, it's very unlikely that it would (the keypress would need to occur within that window). Odds are you are pressing the controller while the emulation thread is sleeping (between both frames) - this is probably why playing the game with no speed limit fixes the issue.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Spot bug in Mesen and Nintaco

Post by zeroone »

Sour wrote:I think I finally understand what might be going on. Mesen polls the keyboard/gamepads every time it needs to update the NES controllers' state. There is no particular point in the frame where this occurs - however, since the frame is executed in a fraction of the time it takes on a real NES (e.g 2-3ms instead of 16ms), the odds of the input changing during the frame is pretty low. If the game expects the input to change between 2 points in the same frame, it's very unlikely that it would (the keypress would need to occur within that window). Odds are you are pressing the controller while the emulation thread is sleeping (between both frames) - this is probably why playing the game with no speed limit fixes the issue.
Sounds like a plausible hypothesis. Any idea how you are going to resolve this?
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Spot bug in Mesen and Nintaco

Post by Sour »

Can't say I really have any good ideas on how to solve this.
The obvious way to do it is to space out the frame's emulation across the whole 16ms, but Windows is not a real-time OS - you can only expect so much precision from sleeps (e.g not much at all). It would be pretty tricky to do this without potentially causing issues on some computers (the thread may take longer than expected to wake, causing the whole frame to be delivered late, etc.)

At the moment I'm tempted to just ignore the issue, unless it's something that actually happens in several games and hinders gameplay. Of course, this is all assuming that my assumption is correct in the first place.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Spot bug in Mesen and Nintaco

Post by tepples »

User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Spot bug in Mesen and Nintaco

Post by zeroone »

Sour wrote:Can't say I really have any good ideas on how to solve this.
The obvious way to do it is to space out the frame's emulation across the whole 16ms, but Windows is not a real-time OS - you can only expect so much precision from sleeps (e.g not much at all). It would be pretty tricky to do this without potentially causing issues on some computers (the thread may take longer than expected to wake, causing the whole frame to be delivered late, etc.)

At the moment I'm tempted to just ignore the issue, unless it's something that actually happens in several games and hinders gameplay. Of course, this is all assuming that my assumption is correct in the first place.
There's probably a simple solution that will take care of Spot and Quattro Sports. The Spot options menu works in FCEUX and FCEUX is well-known for it's FM2 movie format. FM2 is a recording of input that is sampled only once per frame. Meaning, FCEUX is getting away with keeping the controller input values constants throughout entire frames. The likely difference, as mentioned earlier in this thread, is the point that the cached inputs are updated within the frame cycle. If only 2 known games are affected, then that seems like a reasonable engineering solution, even though it's not a perfect one.

Also, when I get a chance, I'll study the exact code to better understand how these games are doing their polling.
Post Reply