That’s a good idea. I like the “Lookahead Frames” name that @e-tank came up with.
That’s a shame. That means you’ll have to experiment and probably apply some game specific overrides.
You still have to download the test build.
There is no set definition of what “input lag” means, but from what I’ve seen, the more common way to use the term is to describe the overall effect, i.e. “There is lag between applying input and receiving a response”.
Just made a quick test with Snes9x2010 and audio seems to work fine. Great job, @Dwedit!
I did observe a curious behavior on Snes9x that differs from Snes9x2010 (and QuickNES): When you return to the Quick Menu or pause the emulator with ‘p’, the screen goes black. Why is only Snes9x doing that?
Goes black screen on pause with GPGX too.
Did I understand correctly that there will be a problem with games that have only 1 frame of internal lag?
Also, will Nestopia be fixed?
The problem is if a game starts playing the audio for an input before actually showing it. For example, if you press jump and audio starts playing on the next frame but animation is delayed another frame. In such cases you’ll have to choose between scaling back/disabling the feature or losing 16.7 ms worth of audio.
Of course, if a game responds on the next frame with both audio and video during actual gameplay, this feature shall not be enabled at all.
Got tired of swapping exes so I made it a menu option you can save with core/game override.
It’s located into:
Settings->Frame Throttle->Lookahead Control Latency Reduction.
RetroArch download for win x64
edit: updated version later below…
I also finally set up my own repository too.
(DOWNLOAD LINK REMOVED)
I also added in a number of frames control, so you can select up to 6 frames to run ahead, but you really don’t want to exceed the number of lag frames the game actually has. Specifying 1 frame should almost always be safe.
The option is located in the “Frame Throttle” menu for some reason, don’t know why.
Running ahead 0 has the same effect as turning the setting off, yet I left the ON/OFF switch in there anyway.
Also fixes the framerate display, no longer says 120 or 180 or whatever.
The retroarch menu system was really hard to figure out, so thanks for the example of how to add a setting in there. Probably wouldn’t have done it so quickly without the example.
Yeah, it’s a real hassle. It’s one of those things we’d like to fix, but it’s hard without scrapping the whole thing.
Frame throttle seems like a good place for it, IMO, since that’s where rewind and slow motion are. That is, anything that fiddles with emu time.
How do you think I could do it myself? 
Frame throttle menu had the advantage of not being overcrowded.
edit: Got a blackscreen with your exe.
Compiling it from source I can’t change the frames ahead value, it’s empty.
Almost have fceumm working, but not quite.
Not sure if you noticed my previous post, but did you have a chance to try your version with shaders enabled?
For me it’s causing issues, see my previous message here: Broken shader output with lookahead version
Is Bsnes-mercury going to work with the fix ?
Okay, back to the drawing board, will delete my repository, and redo the edits against the Stable 171 version,.
Updated the download for win x64 with the number of frames you can change (thanks bparker for fix).
2 frames less is great for smw or PC Kid 2. Really cool.
edit: updated with memory leak fix
Fantastic!
On 6 I can clearly see what it’s doing.
Quite mind boggling, that it can “change the past”…
I thought reality should be time-invariant and memory-less. 
Yoshi’s Island filled up my RAM completely.
Perhaps a leak with Super FX games states.
edit: Happens in every core if the lookahead hack is activated.
You can see it happening faster with fast forward.
There was no memory leak with the previous code (without number of frames value).
Yep, 24GB here crashed system after 5 minuter of gameplay without watching the RAM.
Yeah, I accidentally made a second variable with the same name as the variable that gets freed, but it goes out of scope before it gets freed.
In the meantime, remove the void* declaration from statebuffer that was put in there by mistake.
Thanks that works, updated RA link above.
Just had a crazy idea to fix the audio issues more easily.
Copy the core DLL to a new temporary file, load that.
Run the main DLL for audio but no video, save state, have the secondary DLL load state and run for skipped frames and one video frame.