You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 24, 2024. It is now read-only.
A program can tell that it's running on RusticNES because the buttons always change right at vblank. The games Spot and Quattro Sports depend on this and will not work reliably if the buttons always change at the start or end of vblank.
To reproduce:
Install RusticNES SDL
Start the input timing test ROM "Telling LYs" from little things
Press all 8 buttons in any order
Watch the arrow sprite at the right side
Expect: Arrow moves after each press, followed by "Pass", as on my NES with PowerPak
Actual: Arrow stays invisible of the screen, followed by a message that clearly isn't "Pass":
Incorrect behavior:
Controller state changes
on same line each frame
The Game Boy emulator BGB by beware passes this test. Normally it changes the input on the first scanline of vertical blanking to reduce input latency. But if a program reads input multiple times during a frame, the emulator starts to randomize on which scanline the input changes. This way, the program can't discern that it's being emulated and freeze on a copy protection screen, but it adds one frame of lag. Once the program returns to polling once a frame, BGB returns to the low-latency behavior.
A program can tell that it's running on RusticNES because the buttons always change right at vblank. The games Spot and Quattro Sports depend on this and will not work reliably if the buttons always change at the start or end of vblank.
To reproduce:
Expect: Arrow moves after each press, followed by "Pass", as on my NES with PowerPak
Actual: Arrow stays invisible of the screen, followed by a message that clearly isn't "Pass":
The Game Boy emulator BGB by beware passes this test. Normally it changes the input on the first scanline of vertical blanking to reduce input latency. But if a program reads input multiple times during a frame, the emulator starts to randomize on which scanline the input changes. This way, the program can't discern that it's being emulated and freeze on a copy protection screen, but it adds one frame of lag. Once the program returns to polling once a frame, BGB returns to the low-latency behavior.
The text was updated successfully, but these errors were encountered: