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

I’m starting a game with runahead activated, 2nd instance ON in FCEUmm.
Horizontal and vertical overscan cropping options are disabled.
Exclusive Fullscreen is ON (just realised the issue does not happen if you stay in windowed mode).

If I enable both to crop the picture, it stays the same like this:

If I go to the latency menu and disable runahead or 2nd instance, then it works:

1 Like

Nope, still can’t reproduce the issue at all.

Downloaded RetroArch Nightly, used Core Updater to get official version of FCEUmm.

Run a game in FCEUmm just to get the options menu, have FCEUmm set to no cropping, quit the game, quit RetroArch.

Turn on RunAhead with secondary instance, run the game again.

Turning vertical and horizontal cropping on and off works perfectly.


Second try, from a fresh configuration file…

Doing this sequence of commands:

  • Enable Fullscreen Mode
  • Load a game in FCEUmm
  • In Quick Menu > Options, turn off horizontal and vertical cropping (both on by default)
  • Press ESC to quit
  • Run RetroArch again
  • Turn on RunAhead and Secondary Instance
  • Load the game
  • Turn on cropping in Quick Menu > Options

I still see cropping turn on fine. Just can’t reproduce this issue at all.

It seems to go wrong after you go windowed to fullscreen here.
I start in windowed and then push F to go fullscreen.

1 Like

Found the issue, entering and leaving fullscreen mode destroys the environment hook.

The whole call stack:

CMD_EVENT_FULLSCREEN_TOGGLE > CMD_EVENT_REINIT > video_driver_reinit > CMD_EVENT_RESET_CONTEXT > drivers_init > menu_driver_init > menu_update_libretro_info > CMD_EVENT_LOAD_CORE_PERSIST > libretro_get_system_info > libretro_get_system_info_lib > libretro_get_environment_info

The function libretro_get_environment_info is wiping away all environment hooks I added, so the core never sees any options changes after entering and leaving fullscreen mode.

3 Likes

Thanks, it’s working fine now! :slightly_smiling_face:

New issue… :persevere:

Can’t activate runahead with fb alpha.
I did finish dodonpachi and esp galuda with it before but now impossible on the latest core version.
I get the “Can’t load state.” message, while loading/saving states work.

Somehow managed to get a secondary core desync in Snes9x 2010 while playing Final Fantasy II.

Hello all !!

Can anyone please explain to me why I can’t use the “Run Ahead Input Latency” feature on my PS3? Every ROM I try to run just results in a never ending black screen. If I run the game without enabling the feature and then toggle to Retroarch to enable it, I get crazy audio problems and some games (like Sonic) slow down worse than a slow motion picture!

Forgive me for my ignorance on the subject, I’m merely an end user trying to play some old SNES games, no programming skills whatsoever! I’m also sorry if this isn’t the right place to ask this question but I would really appreciate if someone told me if this is a recurring problem in all PS3s or just mine!

Thanks!

Sorry if it doesn’t work, I don’t have a PS3 and have never tested it on that system. From what you described, I have no clue why it’s failing.

Also make Retroarch and the cores are as new as possible, get nightly builds if you can.

1 Like

I’ve managed to get it working on my PC, but no luck on the PS3. Could it be the PS3 has not enough processing power to run the feature?

@Johnnyusp for the audio problem, try enabling the option, “use second instance” and as this is a cpu demanding feature, dont use “frame delay” or even hard gpu sinc, to see if it helps with the slow downs.

2 Likes

Thanks a lot for your responses!

Easiest way to see if it’s just a performance issue is to try a really light core such as QuickNES.

I was wondering, can this concept be combined with rollback netcode in online multiplayer like in fighting games? as far as I understand how this lag compensation works the netcode doesn’t even need to be changed but instead just do the fast forward trick for every game frame on the client side. and this should be pretty performant too since unlike with emulation doing some more loops through the frame data logic shouldn’t cost that much time.

I think it’s already the case and that Gregor adapted the netplay code to deal with the run ahead setting.

1 Like

oh cool stuff. but I was also thinking about new games besides emulation. seems like a pretty ingenious idea to circumvent the input lag caused by the engine or platform. especially for fighting games this is always a hot topic for every new release.

Yeah, it could work for anything, conceptually. It does greatly increase the CPU requirements, but that could be mitigated if someone built a game around it from the ground up.

1 Like

Hey there, first of all, thanks for the efforts, I just discovered RetroArch recently and I must say I am very impressed and pleased with it !

@Dwedit , thank you so much for the Runahead feature, this is something great !

However, I’ve been messing with this and RetroArch the past few months and I noticed Runahead works with the FBA core, but only for a short while (25-45 mins). After that, sound gets garbled and there are big frame drops. The second instance option doesn’t work at all, and completely disables the feature.

I don’t think I saw it reported, is it something you’re aware of and that is worked on ?

I shot some videos to test the reduction of input lag and it is really impressive ! While Runahead is activated, I have the same input lag as arcade playing on a LCD, with som light filters on.

Also, maybe slightly off topic, but thanks for pointing out the custom refresh rates options.

Never managed to get it to work on my PC, but thanks to you, I discovered I could adjust emulator speed a lot closer to any machine’s than what Mame would allow, by setting ” video_refresh_rate” and saving per folder overrides (e.g. I put CPS3 roms in a CPS3 folder, etc…). I made a video showing the difference of pace with a simple adjustment for CPS3 games, namely SFIII 3rd strike. (Contrary to what’s written in the video, I set “video_refresh-rate=59.299999” not 59.3333333 for CPS3 games to achieve something very close to the original).

For instance CPS3 refreshes at 59.583393 hz, and setting the FBA core to refresh at 59.299999 makes the game almost match the original game pace. Would you happen to know why I have to set cores to a lower “video_refresh_rate” setting than the desired one ? Seems to be the same with every core.

Degradation over time with FBA has been fixed by Dwedit in RetroArch recently, just grab a recent nightly.

The 2nd instance not working has also been fixed, but in FBA itself so you have to update the core.

1 Like

whoohoo ! Great news !

Btw, @Tatsuya79 , thanks to you I changed crt_geom and now have nice scanlines without integer scaling, I don’t remember where I read your reply, but it’s worth a thanks :wink: