An input lag investigation

No probs. I know what it’s like with young kids. It gets a little bit easier when the youngest (in your case both :slight_smile: ) gets about 3 - 4. But indeed even then with work and other stuff going on it’s hard to really spend late night hours (and hours…) on this stuff. (Other than risking your relation/marriage in the proces…).

That said here’s one vote up for looking into the MAME lag, and one vote down for the Snes9X2002 lag! :wink: :smiley:

Yep, I’m guessing it’s mostly used for Pi Zero nowadays. That’s also what I consider using it with.

Hehe, the part about risking your relation or marriage is so true. :smile:

Running bsnes balanced on OpenGL video driver I get like 4 frames of input lag for SMW. I’m using Hard Sync ON at 0 but when I enable run ahead (1 frame only) the framerate crawls, even with the second instance enabled. My CPU is an i5-4670K @ 4.1Ghz. Is this normal? On fbalpha I’m ok at 3 frames of runahead.

Run ahead doesn’t work fine with bsnes/higan.
(smw should react on the 3rd frame if it’s a bsnes core)

I could make it work but I had to go as low as “bsnes-mercury performance”, and enable the second instance for 2 frames runahead (next frame response). I’m not sure what I am sacrificing with the performance variant, specially on the mercury versions.

For anyone interested, you can find the lag fix implementation for snes9x2002 here:

Tested and works on Windows. Should work on Raspberry Pi/RetroPie, but haven’t had time to test yet. Will create a pull request as soon as I’ve verified it on the RPi as well.

Luckily, I didn’t have to mess around with the assembly code after all, but I did have to add an extra line of code in an ARM specific C file.

EDIT: I’ve now tested it on Raspberry Pi (RetroPie) and I’ve fixed an issue it caused with save states. Pull request has been submitted.


Hi and I thought it was appropriate to post it here, otherwise I’m sorry.
The device used is under Windows 10 is Retroarch 1.7.6 running Dolphin core (6fc5941).

Dolphin to like the MAME, has an additional input lag of 1 frame compared to the standalone, but the GC title has no additional lag.
The titles investigated are Gradius ReBirth (Wii Ware), Muramasa (Wii), Soulcalibur II (GC) and F-Zero GX (GC).

Why is there no 1 additional frame of input lag in GC titles?
Also, is it possible that 1 additional frame of input lag delay of the Wii title will be eliminated?


Just curious, HOW did you test the lag? Can you provide a step-by-step description how you tested it and came to the conclusion of one frame of lag?

If you provide these details the devs can maybe reproduce what you found and do something about it. Otherwise don’t get your hopes up.

Thanks for reply, It was done with a be simple test method.
After posing with P, hold the action button and press K to move to the next frame until the action is reflected on the screen.
As a result, it was found that the Wii titles has an additional input lag of 1 frame as compared to the stand-alone.

Gradius ReBirth was 0 frames for Stand-alone and 1 frame for RA core. Muramasa had 2, 3 frames turned into 3, 4 frames (This title was tested on the title screen or next difficulty selection, as there is an intentional additional input lag by the Vanillaware Ltd. developer for actions inside the game.)

But in the title of GC it was exactly the same input lag (2 frames) as stand-alone.
It’s too bad I do not have a camera that can record at 120 or 240 fps, so I can not do a concrete test.

Was the +1 frame additional delay in certain libretro cores (like mame) when pausing+stepping from retroarch also confirmed to be there when using high speed camera recording without pausing?

I’m asking since I got these results with the arcade version of shinobi with mame_libretro and native mame0209 when using the jump button.

  1. Retroarch + mame core with pause/step from Retroarch keys: 3 frames delay
  2. Retroarch + mame core with pause/stop from mame core keys: 2 frames delay
  3. mame0209 native: 2 frames delay

So when the mame core got paused by its own keys, its delay in retroarch matches the native mame’s delay. Which lead me to wonder if the additional +1 frame delay when pausing/stepping from retroarch’s buttons wasn’t some weird artifact of how retroarch unpauses/steps/pauses again in combination with certain cores.

I noticed that too.
When you use MAME pause key RA is not blocking and still runs its logic and polling regardless.
It would be interesting to record it with a high speed camera to confirm, but I think there’s an additional frame of input lag here.

The new bsnes “hd” core has 1 extra frame of lag once again.

It’s there when using the “next frame step” test method in stand-alone bsnes too so I tried to open an issue upstream:

I tried to change it myself but the code isn’t really the same and I couldn’t get somewhere.
This was the patch for the older bsnes core:

Also run ahead isn’t working fine: even 1 frame of reduction is making the core crawl, there must be something wrong with the way states are called.
2nd instance mode is jumping around.

1 Like