Spot bug in Mesen and Nintaco
Moderator: Moderators
Spot bug in Mesen and Nintaco
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?
Any ideas on what's special about this particular screen in this particular game regarding input?
Re: Spot bug in Mesen and Nintaco
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.
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.
Re: Spot bug in Mesen and Nintaco
Interesting. In fact, Nintaco also has the same issue; it works with PAL, but not NTSC.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.
Re: Spot bug in Mesen and Nintaco
HalfNES also appears to be affected.
Re: Spot bug in Mesen and Nintaco
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.
Re: Spot bug in Mesen and Nintaco
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 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.
Re: Spot bug in Mesen and Nintaco
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.
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.
Re: Spot bug in Mesen and Nintaco
At what (x, y) position do writes to $4016 occur in both emulators where the game works and emulators where it fails?
Re: Spot bug in Mesen and Nintaco
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.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.
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: Spot bug in Mesen and Nintaco
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.zeroone wrote: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.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.
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.
Re: Spot bug in Mesen and Nintaco
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.
Re: Spot bug in Mesen and Nintaco
Sounds like a plausible hypothesis. Any idea how you are going to resolve this?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.
Re: Spot bug in Mesen and Nintaco
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.
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.
Re: Spot bug in Mesen and Nintaco
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.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.
Also, when I get a chance, I'll study the exact code to better understand how these games are doing their polling.