Input Lag guide

youxia

@mitu I don't want to join a huge megathread on another forum, I'm just posting here in hope somebody clarify this for me (especially seeing as our input lag guide in the doc is based on this thread)

I suppose it has to do with me using the "frame advance" method which is not real time, as he says

By not running the emulator in real-time, we remove the input polling time, the waiting for the emulator to kick off the frame rendering, as well as the frame output. We have isolated the emulator’s part of the input lag equation!

I thought this method is the definitive lag measurement when I read about it in some thread here.

mitu

@youxia said in Input Lag guide:

I thought this method is the definitive lag measurement when I read about it in some thread here.

Which method ? The input lag guide (in this topic) has recommendations for improving the performance, but doesn't offer a testing methodology.

youxia

@mitu I said it twice already :) Frame advance.
https://retropie.org.uk/forum/post/146923

mitu

@youxia The method in the topic just measures the internal emulator improvement, but - as you said - you need to measure externally - as @Brunnis did - the input lag to get a good result. Sorry for the double post.

mediamogul

@youxia said in Input Lag guide:

I thought this method is the definitive lag measurement when I read about it in some thread here.

The frame advance test is only meant to determine how many frames of latency an individual game has built in. This should be a constant between systems so long as the same action is being tested. When testing 'Mike Tyson's Punch-Out!', I advanced the frames from the moment I initiated a punch to the moment that the animation began and the frame count was considerably higher than when I tested pressing 'Start' on the title card screen. My guess as to why this occurs is perhaps due to intentional latency added for game design reasons. Of course if that's true, it will be more difficult in some games than others to find a reliable point to test for the runahead feature.

youxia

Yes, I see it now. I've initially thought it's meant to be a good overall lag test. Now I also understand why any tweaks I applied when testing made no difference to the result.

So what would be a good method to test the entire lag, but without using the joypad LED or the iOS app which Brunnis did? I recall @thelostsoul tried something like that...

thelostsoul

@youxia Yes, i did test the entire lag on my setup. There are several stages where lag will or can be added to the whole:

the game's internal lag
the emulator itself and its configuration (some shader also add)
the output monitor device (with probably a converter)
the input device gamepad controller (don't forget USB polling rate)

How I achieved the test? I have an arcade stick as gamepad (USB) with builtin LED. That LED blinks when I have setup turbo mode and click a a button. In the emulator I enable display frame count while playing. The recording is done via my smartphone's (S7 Edge) slow motion video recording, which is 240fps. Now, start recording some jumps, while the LED on gamepad, the frame count and the jumping hero on the monitor are covered. From this point, you can just count the frames in the slow motion video until an action happens, when you press the jump button of your hero. That should be the total lag count. Note: This will be done in real-time, not in pause mode.

Here is a small animated GIF to illustrate how a test looks like on my end. The quality of the GIF is bad, the video based on it is higher quality: https://makeagif.com/gif/input-lag-retropie-44-raspberry-pi-3-donkey-kong-mame2003-emNiU0

youxia

Ok, thanks, got the idea. Might try it, but my phone's old so probably does not have 240fps. Maybe one of my big cameras does. Also no LED but it can be done without it too though it's slightly less precise.

thelostsoul

@youxia I tried it without LED, with my Buffalo SNES gamepad first. The problem was, I couldn't really tell when the internal electrical signal was done for button press. It was a range of 5 to 10 frames uncertainty (these numbers are just a guess), which makes it really hard to "know" when the press was done actually. About the recording with 240 fps, I think its important, as with lower fps you will get less fine granulated frames. You need a very slow recording to capture the moment of actual action on the screen.
I understand, if you don't have that equipment to test. But be aware a test not very precise can fool you. I am not sure if even my test is reliable too.

youxia

Oh, I agree - I based it on what Brunnis himself was doing comparing the press vs LED tests: differences were minuscule. See it here: https://forums.libretro.com/t/an-input-lag-investigation/4407/524

But he did have a 240fps cam. I'm not sure if I can be bothered myself, it's just an idea. Overall it's all just out of curiosity and old benchmarking habits, which I have since the days of 3dfx cards :P I don't need this to prove anything to myself or others, since I can live with this lag as it is at the moment.

One test though I would definitely would like to conduct is to take some people who claim that are "sensitive" to lag and do some blind trials on multiple setups with various slight differences. I think the results could surprise a few, especially those who swear that 1 -2 frames of lag makes games unplayable for them :)