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

retroarch

#201

No, not that simple. For example, Mario World is two frames and Donkey Kong Country is one frame.

Then Kirby’s Adventure on the NES has two frames of input lag.

It just varies from game to game. It is more common to find two frames of latency on the SNES though.


#202

Thanks for the information regarding setting each game or not. Hopefully we can keep a running Google Doc or something once the feature is out in the wild. Its very promising feature and I look forward to it and I am sure the longer its out their the more information that will be gathered.


#203

Let’s start compiling lists of every game on the NES/SNES/Genesis/etc. and the amount of built-in lag frames they have.

I am willing to add new metadata to libretro-database for the purpose of adding lag frame information to game entries.


#204

What is the suggested way to test this? I have seen people use high speed cameras but it that the only way?


#205

Just a word of advice for people measuring the frame lag of the games. Some games do not run at 60FPS, such as Joe & Mac on the SNES, which runs at 30FPS. If you try counting the lag frames for that game, you will see it vary between 2 and 3 frames of lag, depending on whether you started on an even or odd frame. Please record the smaller value.


#206

I think the frame advance feature is a good tool to test this since it’s about actual frames of lag being shaved off.


#207

So, what are the cores so far that work nicely with this feature?

And what are the cores that do work but need a second instance?


#208

I’ve gotten a few hours of playtime on SNES9X and Genesis GX and they seem to work just fine. I’ve only used 1 frame so far because my setup has about 1 frame of lag. I just want to be at parity with the consoles.

The only time it was necessary to enable the 2nd instance for me so far was when playing Final Fight on Sega CD. The audio would be choppy until I enabled that but I haven’t seen a drawback by leaving it enabled.

I’m using Sunday’s nightly build so I will need to redownload the latest next time I play.


#209

Let me know if I’m getting something wrong, but I thought measuring internal input lag was trivial, you just have to press “P” to pause the game, hold a button and press “K” to advance frame by frame, counting how many frames it took for your input to register on the screen.


#210

Then you subtract one. So if you Pause, press Jump, then press “K” three times, then you see the character jump, there were two frames of lag, not three.


#211

If you see the character react on the third “K” press that means he jumps on the third frame, so the previous two count as lag. If he reacts on the second frame, that means 1 frame of lag. Your target is to see the character jump on the first K press, which means zero frames of lag.

With this in mind, you set the number of frames you want to omit. If it’s two frames (like in Mario World) then you set it to “2”.

I assume setting it to 1 frame is safe for 99% of games that aren’t on Atari 2600. After that, you can test if some games have additional lag frames to remove.


#212

Cool then I’ve been testing it right.

So the point of creating a database of each game’s internal input lag would be to automate the setting of how many frames to runahead, correct?

Seems to me that could be automated without a database, although not with a 100% certainty:

  1. Two instances of the same game could be ran simultaneously at fast forward, with one of them autofiring “start” at every frame and the other having no input.
  2. Each frame generated with one instance is compared to the frame of the other instance, if the two are running in sync and they differ even by a single pixel, that means that the input was registered and had an effect on the game (doesn’t matter what effect exactly).
  3. Register the frame in which the change ocurred and the frame in which the input ocurred, and count how many frames there were between the two.

I said “start” because that’s the usual button that is more likely to have an effect as soon as the game boots, there could be a set amount of frames (for example 30secs, i.e. 1800frames) after which this script would then try another retropad button, like “A”.

The problem with this is that some games have different input lag in-game than they have for example in the menu, so it wouldn’t always be accurate. Also, I don’t know how resource intensive this could be, if it takes too long to have the user waiting for it to finish then at least a similar method could be used to automate the creation of an internal input lag database to ship with retroarch.

Given how easy it is to measure internal input lag it sounds hardly worth the trouble to me, but I guess some users might care about that.

EDIT: I forgot to mention one thing, the above method would not be able distinguish which of the frames in which the input ocurred was resposible for the change in later frames, so it should be:

  1. Same as above, but store saves states of the last 7 frames.
  2. Same as above.
  3. Register the frame in which the change ocurred. Load state for 2 frames before, and repeat the test from that point. If there is a change on the same frame as it happened on the first test then the game has 1 frame of input lag, finish the test. If not, then load the state for 3 frames before and repeat the test, and iterate like this until the maximum possible amount of internal input lag is determined. (currently it’s 6)

#213

My hope when I asked the question was simply 1-1 parity with original hardware as soon as you fired up Retroarch. Or even the option to default to this parity. Thinking along the lines of the Zero Lag option which is the default on the Super NT.


#214

Well, from what I’m given to understand the problem is internal input lag is easy to measure by advancing frame by frame, but the input lag from your hardware stack is not, it can only be measured by testing with high speed cameras. So the only way to know if the total input lag is at a 1-1 parity with original hardware is also by testing with a high speed camera…


#215

As far as i know the NT has the same lag as the real console. This one however can potentially be even better than that.


#216

even if there is an automation, it is also necessary to give the choice of the number of frame to remove for the user as at present, it is very useful for those who have a TV delay frame.


#217

Yup and thats great would just be nice if we had that hardware baseline but of course knowing that baseline will only come with time and testing.


#218

Just made a Google Doc for tracking the Frame Settings I started with SNES feel free to add consoles and settings to the list:


#219

What’s the sound issue?


#220

Sound appears to be pretty garbled when running turning frame throttling on. If you turn it off its fine no issue. If you Runhead Use Second Instance it doesn’t fix the issue. I have only hit it with this rom so far. Everything else has been smooth on SNES.