Written by Brunis:
There’s probably a good number of people still using RetroArch’s snes9x2002 core for SNES emulation on low-performance devices (primarily Raspberry Pi 1 and Zero). There’s probably also going to be a resurgence now that the Retroflag GPI Case is coming. Because of this, I had a look at snes9x2002, testing both the performance (frame rate) and input lag. Turns out snes9x2002 had two issues with input lag:
In the LibRetro layer: The emulator would first run to generate a frame, then the input would be sampled, instead of the other way around. This means that the input fed to the emulator was always that which was sampled after rendering the previous frame. This added between 0 and 1 frame of input lag, depending on frame rendering time.
In the emulator itself: Each time the emulator was kicked off to render the next frame, it would start at the first scanline and run to the last. Due to how most SNES games work (polling input at the beginning of VBLANK, running game logic during VBLANK and scanning out the resulting lines from scanline 0 to 226/240), the optimal thing to do is to start the emulator at VBLANK, just before polling input, and then run it for a complete frame until the start of the next VBLANK. That means you capture input polling, game logic and resulting image within one and the same emulator loop. This issue added exactly 1 frame of input lag.
I fixed these issues (with Tatsuya79 on GitHub helping out with committing the LibRetro layer fix) and the result is a reduction of input lag by 1-2 frames (16.7 to 33.3 ms), without any increased computational demands. The updated core is available now, by updating from source or using the Online Updater in RetroArch.
It’s important to mention that these fixes bring snes9x2002 up to par with the other RetroArch snes9x cores in terms of input lag. Unless you have a really low-performance device, you’re still better off using snes9x2005 and upwards for the superior emulation.