Input change always happens at the same Y position

[Max833]

SourMesen/Mesen-S#63

[bearoso]

With the existing frontend implementations we break out to process input only before NMI.

bsnes does something different, and polls whenever input is requested during the frame.

But that's completely unnecessary and won't work for us. On a modern system Snes9x takes less than 1 millisecond to emulate the entire SNES frame. The rest of the time is spent waiting to time video and audio output properly. So even if we poll during emulation it's still going to be more than a 15/16 chance to occur on that break point anyway. This might be enough to pass their test, but as we get faster it gets even more centralized and less likely to pass.

We could stretch the emulation out to fill the whole time frame, but that introduces far more negatives than positives. e.g. No fast forward or run ahead. Or we could register the time between frame markers the input occurs and wait to introduce the input until a certain time, but that would add lag.

I'm going to vote "won't fix" for this one. We can't sacrifice performance and features to pass a homebrew-only edge case that would only 100% pass on a hardware implementation.

[OV2]

IIRC we also already have SNES_JOY_READ_CALLBACKS which works similar to the bsnes way, but it's only used in the win port for some obscure frame advance feature.

[pinobatch]

bgb by beware is a Game Boy emulator. It passes the Game Boy version of this test using the following algorithm:
If a program reads the controller more than once per frame, and movie recording isn't enabled, randomize on which scanline the input changes. That way, a program can't use this predictability to discern that it's being emulated rather than executed on an authentic console.