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.
1 Like
I think the frame advance feature is a good tool to test this since itās about actual frames of lag being shaved off.
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?
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.
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.
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.
3 Likes
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.
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:
- 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.
- 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).
- 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:
- Same as above, but store saves states of the last 7 frames.
- Same as above.
- 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)
1 Like
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.
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ā¦
2 Likes
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.
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.
1 Like
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.
Just made a Google Doc for tracking the Frame Settings I started with SNES feel free to add consoles and settings to the list:
2 Likes
Whatās the sound issue?
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.
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.