Input Lag Compensation to compensate for game's internal lag?



I don’t know about you guys but I think this is freakin’ incredible! Dwedit you’re a mad scientist! Retro Arch is already amazing having only one frame of lag on Windows 7 which I am perfectly happy with but damn, using a second core to look ahead to remove the frames of lag that exist on real hardware make me feel as if I am playing real hardware even on my laggy LCD TV. But beyond that it’s just so incredibly cool for you to exploit the shortcomings of the real hardware. Rest assured I will be playing all my SNES games with this feature engaged so I can report any bugs.


–removed- It’s merged, you can grab a recent nightly.

Compiled from the current PR branch Dwedit sent, rewritten in C.
Same support / compiler as the buildbot.


I notice it’s now running at the speed where you force the sync by stressing the controls.

With beetle-psx software, I could play with several frames ahead previously, as long as I wasn’t using the controls too much. Now it’s always the worst case: 1 frame ahead stutters.


Not experiencing that, trying out Beetle-PSX with Dragon Warrior 7. With run ahead 1 and no secondary core enabled, it’s slow. When secondary core enabled, it’s normal speed, when I hit buttons, it’s slow again.

Beetle-PSX probably needs some optimization, especially fast save states.

Is this related to variation in the position of the analog stick every frame? That would cause dirty input.


Shouldn’t the second instance have fixed audio stutters in all cores?


It fixes audio buffer discontinuties caused by improper save/load state, not performance issues that cause framerate to drop below 60FPS.


It’s with 2nd instance enabled and not using the analog stick.
I was playing Adventures of little Ralph, with 3 frames read ahead using your exe of the c++ version.
It was running fine most of the time as long as I wasn’t mashing buttons.

Now read ahead 1 frame is slower than 60fps with the C rewrite submission.
Quite a big difference.


Can you please have a look at Nestopia?; it still stutters in all configurations.


Can’t reproduce any issues with Nestopia. Hope this doesn’t mean that non-msvc builds are broken…


I can confirm the sound problem in Nestopia, with 1 or 2 instances.
Perhaps the 2nd instance option isn’t working?
I don’t see a message in the log saying it loaded another core like before?

Also Pce_fast sound isn’t skipping like before when using only 1 instance.


Confirming mingw builds are borked… fixing it…


Thanks everything works fine like before!
Psx is ok again.

And I realised the PCE thing was a different issue that already got fixed before, I mixed up things.


I tried the run ahead feature (using Windows buildbot version) with the px68k core, but it seems to do nothing at all with this core, pauze+k step frame stays at same frames of lag also. Is it supposed to work with this core? I tried Nemesis 90 Kai and Galaga 88.

(Same buildbot version with Snes9x and run ahead works fine, so it seems px68k core specific.)



  • If it encounters any errors when saving or loading state, the feature is silently disabled.
  • Cores which bypass the usual video frame callback and instead use the graphics API directly will still output all video frames, and run at half speed


Px68k doesn’t support save states atm.
I’m not sure if it’s in the source code?

BlueMsx is one were the save states code exist and could be used for RA.


I’ve sent in some pull requests for the Snes9x cores (2005, 2010, Main) now which will speed up the runahead feature dramatically. Uses Fast Savestates, disables rendering when video frames will get discarded, and if using a secondary core, disables audio DSP emulation on that. Maybe in a couple days or so, they’ll show up in the nightlies.

Some of the Snes9x builds I’ve posted here already preview the fast savestate feature.

edit: pull requests were added in, wait for the nightlies tomorrow.


The px68k doesn’t support save states indeed. Maybe it can be detected for cores that have no save state support, such that the run ahead feature gets disabled in the frame throttle menu?


Would be great if the save states in the BlueMSX core could be hooked up, but apparently it’s not so easy:


New snes9x is fast, great work (around 500fps in smw at 2 frames/2 instances on i5-3570k). :slight_smile:


how much was it suppose to be without runahead? on my crappy dual core it already runs at or about 500 fps without runahead, and 230+/- on runahead 2frames/2instance.