Input Lag guide
-
@tekn0 Interesting. Full 60fps at those runahead frames sounds interesting, to say the least.
Could you test lr-genesis-plus-gx if you do have the chance?
I suppose I'll have to try that out myself then, you got me curious :)
-
@pjft I did try it. I was unable to get an extra frame on the gx core. Only pico drive. I talk more about the other tests here. https://retropie.org.uk/forum/topic/17438/new-emulation-method-to-eliminate-input-lag/15
-
@tekn0 said in Input Lag guide:
@pjft I did try it. I was unable to get an extra frame on the gx core. Only pico drive. I talk more about the other tests here. https://retropie.org.uk/forum/topic/17438/new-emulation-method-to-eliminate-input-lag/15
Dang.. Dwedit specifically worked on the Genesis GX core so that it could use runahead on pretty much even the weakest systems RetroArch supports like the original xbox.
Something must not gel well with the rpi architecture. It may be worth filing an issue and getting Dwedit's attention, but it's good that picodrive works at least.
-
So when will 1.7.3 be available binary?
-
@markwkidd I remember reading in the release notes he was working on adding support for that core. I just updated from source and I can get 1 frame stable on the new GX core. :)
-
I was involved in a discussion elsewhere regarding the results @Brunnis posted in that libretro thread and which were used in this guide (the Super Mario World test). I'm curious about one thing: my own test using the "frame advance" yields 2 frames of lag on average. Similar to mine setup here says 7 frames. Can anybody explain why do they differ and how this works in general?
My setup:
RPi 3B+ @800 Mhz, CRT TV, USB DS4 pad
Only setting used was threaded=off, everything else unchanged -
@youxia the CRT is certainly the way to go. To the best of my knowledge, most of these effects, if the emulators are coded well, are only felt when using LCDs as they are the ones that have some delay in frame rendering. That's why some of them have game modes, to alleviate that by reducing some post-processing effects intended to improve video quality (mostly used for video).
So in summary, you shouldn't really feel much if on a CRT.
Edit: I'm tired and also not the most knowledgeable person about this here, so I'm sure someone will correct me and give you a better and more informed answer.
-
I don't think the video lag has much at stake here. If I remember correctly, from the libretro topic discussing this, the test was performed with a LCD having very little (<1 frame?) lag and the tests took into account the lag caused by the video display, so that only input + emulation lag was measured.
@youxia why not post on the libretro forum and ask about this ? Did you use the same testing process as @Brunnis ? -
@mitu well, that's what I get for trying to talk about things I don't know much about:) good morning!
-
@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.
-
@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.
-
@mitu I said it twice already :) Frame advance.
https://retropie.org.uk/forum/post/146923 -
-
@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.
-
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...
-
@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
-
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.
-
@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. -
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 :)
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.