Input Lag guide
-
@dankcushions said in Input Lag guide:
i like this! that's good wording. i think with this change I would be happy with the rest of the updates.
I reworked the headers and added a message regarding their status as specifically being unsupported on the forums. Let me know if you can think of anything else that would make this come across more clearly, and of course, feel free to change any of my wording yourself as you see fit.
-
@dankcushions said in Input Lag guide:
@markwkidd said in Input Lag guide:
Wait till you see what is about to hit in 1.7.3 in terms of native CRT support in RetroArch
i don't think this helps retropie - pi uses a bespoke API for CRT resolutions and the current PR is only relevant to windows, right?
Native RetroArch Linux support for CRTs is incoming as well. It may get broken up into a second PR or wind up as part of the original.
-
This post is deleted! -
Im sorry for the double post but I just tested the new runahead feature on a Pi3B with the newest Retropie 4.4 and retroarch 1.7.3 compiled from source. It did make a nice difference. I was able to increase the fceumm core 2 frames, and picodrive 3-4 frames. It's awesome actually and feels really good/smooth.
Mame2003 has all types of errors, and Snes9x2010 was a nogo, even at 1 frame. All other snes cores also seemed to have issues, but fceumm and picodrive were champs and it made a noticable improvement. This was also while running crt-pi in nearest mode. The tv I tested on was not 1080p so I will have to test at that res next.
-
@dankcushions The dev has said on his youtube channel he is porting retroarch crt mode to the pi and linux is already working.
-
@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...
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.