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

RetroArch General
#81

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.

#82

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…

(source here)

3 Likes
#83

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.

2 Likes
#84

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.

#85

How do you think I could do it myself? :smile:

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.

#87

Almost have fceumm working, but not quite.

#88

@Dwedit
The ‘newer’ build goes black screen when started, the older one works fine.

#89

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

#90

Is Bsnes-mercury going to work with the fix ?

#91

Okay, back to the drawing board, will delete my repository, and redo the edits against the Stable 171 version,.

#92

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

#93

Fantastic!
On 6 I can clearly see what it’s doing.

Quite mind boggling, that it can “change the past”…:sweat_smile:
I thought reality should be time-invariant and memory-less. :upside_down_face:

#94

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).

#95

Yep, 24GB here crashed system after 5 minuter of gameplay without watching the RAM.

#96

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.

1 Like
#97

Thanks that works, updated RA link above.

#98

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.

#100

Here’s the idea now:

  • Create a secondary copy of the RetroArch core by loading the DLL again. The only way to actually do this is by copying the core DLL to a temporary file.
  • Do not output audio on the secondary core at all, secondary core will only see the same input that the primary core last saw.
  • Run frame on primary core, outputting audio, outputting no video.
  • If input has changed, Save State, make secondary core Load State, and run ahead frames, outputting the last one. Otherwise continue running the secondary core for one frame.
1 Like
#102

I just hit an amusing bug… For some reason, the main core isn’t responding to input at all, and the secondary core is getting all the inputs instead. So the primary core is just playing the title screen music and the secondary core is actually playing the game and showing video.

So this does mean I got running a core twice working…

#103

Got the Secondary Instance feature working, and did a small amount of testing, it seems to work okay on my PC for a few cores I tried.

Primary Instance runs the emulation, input handling, and sound. Secondary instance runs the visuals one or more frames ahead. This prevents the Primary instance from loading state every frame, so there are less artifacts and crashes.

1 Like