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



We need to take into account an important factor while creating this database: some games react with a different amount of frames of latency depending on which action you are actually performing in-game.

For example, if I recall correctly Rockman / Megaman X on SNES reacts after 1 frame when shooting and 2 frames when jumping. This could make it difficult to establish a reliable baseline.

I suggest using the minimum value in the database, but if this automatic detection were to be implemented I would say it’s important to make it optional and keep the function to manually adjust the values at all times.


In the limited testing so far i have noticed what you are talking about. Oddly enough it seems consistently that the action with the minimum seems to be a jump. Movement to the left, right, up, or down is another one which seems to consistently be the minimum. I have only noted the minimum I can actually find in my document.


Mesen does not seem to work with runhahead, it crashes Retroarch.


I have the same desync problem that Bromheart85 in Super Mario Bros on Nestopia.

Edit : no, sorry, it seems to be a different issue.


Turns out that I was doing things in a different order than Retroarch does things.

RetroArch’s Order:

  • Init Symbols
  • Init Environment Callback
  • Init Core
  • Load Content
  • Init Callbacks (video, sound, input, etc)

My order:

  • Init Symbols
  • Init Callbacks (video, sound, input, etc) <- mesen crashed here
  • Init Environment Callback
  • Init Core
  • Load Content

The crash happened during while initializing the Audio callback. Changing the order to match Retroarch stopped the crash. Strange how only Mesen seems to care about what order these steps happen in.

edit: Note that Mesen is probably too slow to use with runahead, it would need more optimizations first.


Mednafen PSX HW does not work either : I get sound, but no picture.

Edit : and another one ! PPSSPP does not work, it crashes RA.


Yeah set_environment has to be set before retro_init Not sure why it would crash in this case though?


According to Sour, mesen was assuming that environment was set before the callbacks were set, which I wasn’t doing.


I was wondering if someone could build a Wii version of RetroArch with runahead enabled using the Snes9x 2010, core I just want to see if Runahead works at a playable speed on that platform.


I could enable HAVE_RUNAHEAD for the Wii version, the problem is that the Wii (and WiiU, and every other console) does not have HAVE_DYLIB or HAVE_DYNAMIC defined.

Will this prevent runahead from working altogether?


Runahead just needs savestates, no other requirements. You end up with runahead without using a secondary core, which requires good audio support from the core after loading state.

I ended up building a Wii version (fixed some compiler errors along the way, will push that), and now I can’t test it because my Wii just happens to be broken right now. It won’t boot the system menu, won’t boot the Homebrew Channel, it’s just stuck at Bootmii.

Edit: Somehow the wii just started working again… It ran Super Mario World at 38FPS when using runahead of 1.


With which core was this? Snes9x 2002/2005 should be significantly faster than 2010 even. But not sure if we have Wii targets for those yet, but it shouldn’t really be difficult to do them in case they are missing right now.

The WiiU and PS3 have a bit more horsepower, maybe runahead would be nice there.


@Dwedit hey, I’m responsible for the Retro Achievements integration in RetroArch.

Someone just made me aware of a possible issue with the runahead feature and achievements. So, quick question: do the runahead frames cause cheevos_test to be called? If not, we’re good.

Otherwise, imagine that the player gets an achievement in a runahead frame. But because the input state has changed, the frame is discarded, and in the new path the achievement is not really completed. Since it was already tested for, the player has already earned the achievement, and that action cannot be undone like the frame is.

The solution is to only call cheevos_test after frames that really contribute to the game and that are not discarded. If that means there will be a couple of frames of lag for achievements to trigger, it’s fine, achievements don’t have hard requirements regarding latency.


Cheevos_test is called after the core_run replacement code, so it can’t be called during runahead time. Also, the core_run replacement code never puts the primary core in a different state than simply running one frame.


I’m not sure I follow. The issue is not testing for achievements ahead of time, but testing after a frame that is later discarded. If that’s what you mean, than we’re good.


After calling “run_ahead”, it is never left in a future state once “run_ahead” completes, it just leaves it at the next frame, as if you had called “core_run” instead.


Awesome, thanks for the clarification.


HAVE_RUNAHEAD should now be defined for the PS3, Wii and WiiU builds.


Yeah, I’ve noted that too. Maybe the limit should be based on the genre of the game, for instance, megaman, being a platformer, its more importarnt to reduce lag on the jumps, becose its what will make you fall to your dead if you jump too close to the edge and the game dont react fast enough, in Mario games too. just my opinion.


Found a minor issue in Super Mario World. While most actions are lagged by two frames, pausing the game is only lagged by one frame. So with two frame runahead, the screen will snap back a pixel or so if you pause while moving. I’d still consider two frames to be the correct lag compensation though.