Revert "Change where we break S9xMainLoop/Scan for input ("Brunnis lag fix")" - Causes incorrect behaviour in Super Punch-Out!!

[AkiteruSDA]

This reverts commit 10e0ef0.

Hello again,

This commit causes incorrect behaviour in Super Punch-Out!! due to punches starting earlier than they are supposed to after input. See here for a demonstration: https://www.youtube.com/watch?v=nHr5W12TYrg

The fastest possible time on Piston Hurricane is 5"49, which requires a manually timed gut punch at 2"05 on the in-game timer. Pressing Y one frame earlier will cause him to block your punch. On the left I demonstrate obtaining a 5"49 by frame advancing so you can see the timed punch. On the right, I try the same thing again on 1.56, but pressing Y at 2"05 causes him to block the punch because it starts earlier than it should. Delaying this punch by 1 frame allows you to complete the strategy on 1.56, but with a final time of 5"50, one frame slower than what should be possible. Reverting the polling change from 10e0ef0 fixes the issue. The current TAS of the game done on BizHawk 1.5.1 gets a 5"49, and here is a video of me obtaining a 5"49 on real hardware: https://www.youtube.com/watch?v=V_EMDAx9WcA

I believe there are other examples of strategies not working due to this, but this is the most commonly encountered due to it being one of the easier fights to execute. If there are other games that are similarly sensitive to frame timings, they may be affected by this as well.

Thanks.

[bearoso]

This shouldn't affect emulation accuracy. All it does is affect platform to emulator input latency (where do we stop and check if the keys changed). The lag is worse than console in both situations because we don't poll continuously. Frame advancing between the two won't be accurate because now changes made while frozen will affect the frame immediately after instead of the one after that.

[AkiteruSDA]

I do think this affects emulation accuracy. The Brunnis fix changes input polling to the beginning of vblank rather than the end, and game logic can still run during vblank, where it doesn't seem to expect new input based on this issue. I tried the bsnes-mercury performance and snes9x2002 cores in retroarch which both have this polling change without frame advance and both exhibit the same issue. I can see why this was considered an input lag fix, but I don't think it's accurate.

[bearoso]

The input polling in question is the emulator core polling the frontend. The change was made so the emulator core had the users latest values ready when the game logic during the vsync is run. You can still get the same behavior from the game, you just have to press the controls one frame later with respect to what you're seeing on screen than before.

The actual SNES has no controller interrupts. It's entirely continuous, so where we sample the host input during a frame should only have anything to do with input latency.