It is currently Mon Oct 23, 2017 12:09 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Aug 13, 2017 11:32 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 713
Location: New York, NY
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?


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 12:39 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 5:38 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 713
Location: New York, NY
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.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 8:14 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 713
Location: New York, NY
HalfNES also appears to be affected.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 8:23 am 
Offline

Joined: Wed Sep 13, 2006 12:45 pm
Posts: 55
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.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 8:26 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 713
Location: New York, NY
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?


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 8:34 am 
Offline

Joined: Wed Sep 13, 2006 12:45 pm
Posts: 55
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.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 8:53 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19120
Location: NE Indiana, USA (NTSC)
At what (x, y) position do writes to $4016 occur in both emulators where the game works and emulators where it fails?


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 9:40 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 713
Location: New York, NY
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.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 1:26 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 44
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.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 2:21 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 3:17 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 713
Location: New York, NY
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?


Top
 Profile  
 
PostPosted: Tue Aug 15, 2017 3:41 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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.


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 5:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19120
Location: NE Indiana, USA (NTSC)
Quattro Sports has the same problem.


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 7:15 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 713
Location: New York, NY
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group