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



Funnily, these past weeks I have been doing tests for UMK3 arcade vs various emulators and setups, using 60fps video.

Here is the input delay/lag results

And also, if anyone cares, here are the results of speed differences:


The Xbox 360 version hasn’t been updated in years yeah. That is a very old version. Hopefully I can get it resurrected at some point in time (already did the Xbox OG port). Would be nice to compare it to PC RA too.


May I just briefly report my own experience in MAME, in particular MAME 2010: With very snappy old school games, such as 1942, Gyruss or Pacman, this is indeed a game changer. Runahead of one instance of 2 frames, for the first time, brings me into real Arcade territory as it used to be in the old days. In particular 1942 is the best testing environment for this. Tested on my Mac under MacOS and Linux, apparently OpenGL. Shaders and Overlays play nicely. I am in Arcade heaven - finally :slight_smile: . Will continue testing, but until now already flawless.


@Dwedit, do you think anything can be done about making Secondary Instance work with Beetle PSX without the stuttering it exhibits right now?

At the moment I am experiencing stutter anytime I press any input with the Secondary Instance option enabled, regardless of the amount of Run-ahead frames specified.


Core is outputting multiple frames through hardware acceleration, so it renders two frames instead of one, waits for vblank twice, thus runs at 30FPS.

The systems for disabling frame output were designed for the cores which render to a frame buffer and call the video output callback, which gets disabled when frames should be discarded. There is no method right now of discarding frames when using hardware acceleration.

I currently don’t know the details of how hardware accelerated cores work. If the cores get an actual OpenGL driver, and call SwapBuffers, then there is no way for the frontend to stop that automatically.

The frontend does have a flag it can set to tell cores not render a frame, but the core needs to be modified to respect that flag.


Just to be sure, what you’re describing is also applicable when only using the software renderer within Beetle PSX, right?


Software renderer version does use the usual framebuffer and video callbacks, so it actually does work with runahead. The emulator is a little slow, so it doesn’t have enough oomph to runahead with secondary core and do Hard GPU sync at the same time. When I disable hard gpu sync, it can run at 60FPS with secondary core (this is emulating two systems at once) as long as you don’t hit any buttons.

Only issue is that savestates are very slow, so resyncing, and not using the secondary core are really slow. Also there is no frameskip feature in there yet, so there is no optimization due to skipping audio or video emulation.


I see, that is coherent with what I am observing since I typically only use the software renderer. Secondary Core performs fine unless you start pressing any inputs - and that’s when it begins stuttering.

I wonder if some of the optimizations that you had applied to snes9x, or in general some way to achieve faster savestates for example, might be worked into the software renderer of Beetle PSX to make it usable in actual gameplay with Run-ahead.


The first test is the actual arcade board? The game runs at 53 FPS I think on the actual hardware. I actually just picked up a umk3 pcb and plan on supergunning it to a pvm. I also have a x360 in a mk cab that runs mk9 and the arcade collection. I had an arcade player over a while back who said it felt different. I don’t have my cab wired jamma anymore. I might put in some work so I can have the 360 and pcb easily switchable or might just play the pcb on the pvm. I can’t decide yet.


Just seeing why Mednafen PSX core is so slow at runahead…

The reason seems to be that saving state is really really slow.

I briefly tried Runahead at the save game menu of Dragon Warrior 7, and it was spending just as much time saving state as it was running the game twice over.

Looking at the savestate code, it is going out of its way to avoid calling memory management functions on the pointer it was given by allocating a big buffer, and doing copies. The memory allocation/copying alone is eating up all the time, and not so much the actual job of saving the state.


Yeah, the savestate code in Mednafen is based on the savestate code in FCEU, it started out as an FCEU-based emulator before it grew into th multisystem project it is now.

I would be totally fine with you breaking the current existing savestate compatibility in Beetle PSX if you can get big performance gains out of doing so. It could also actually make netplay feasible hopefully.


I finally started playing around with this. In Genesis Plus GX, if you enable BootROMs for Gen, MS and GG there are issues if runahead is enabled when booting a game. Genesis games will show the TMSS bootscreen for a split second, then freeze on a black screen and crash. Master System games just freeze on a black screen. Game Gear games skip the boot logo, but play fine. Runahead works fine if I disable the BootROM core option.


This problem can also be triggered by simply saving and loading state during the TMSS screen, runahead has nothing to do with this here.


I deleted an inflammatory post not because I’m trying to silence the author or anything like that. I just don’t want to be a party to more silly scene drama.


Hey all. I did this video almost a month ago after playing with this feature which at the time was hot off the press. Just thought I’d share my results. Please forgive me calling the feature “look ahead” instead of it’s actual name “run ahead” because at the time this was one of the possible names for this feature before it was officially named “run ahead”. Thanks again to Dwedit and the Libretro Team for such an incredible breakthrough in latency.


I want to test this! do i need to download retroarch 1.71 and just replace the exe file with the experimental one?


It’s part of RetroArch now — you should download the latest “nightly” from the RetroArch site and then update the cores you want to test it with.


Thanks! Will try it later! is there an option i have to turn on to get it work?


Has there been a standardized place to put internal lag findings? I would love to be a part of crowd sourcing the data for a future meta data entry.


Settings -> Frame Throttle -> Run-Ahead to Reduce Latency: ON