New emulation method to eliminate input lag
Here's a very positive development for lr-snes2010 on the Pi3b. I had read that some improvements were recently made to optimize for run-ahead, so I updated from source and was surprised to find that almost all games will now run at 60FPS. I did see the occasional momentary dip to 59.7, but it didn't happen often. This time I did all my tests at 1920x1080 and everything still managed to hold up as long as I had a second instance enabled. Once the second instance was deactivated, the frame rate plummeted. I also tested a few of the potential troublemakers noted above and there's no surprise that they didn't do nearly as well. Below are the lowest and highest frame rate I got with each of those tests.
'Star Fox' - 52-58 FPS
'Star Fox 2' - 43-51 FPS
'Super Mario World 2: Yoshi's Island' - 43-56 FPS
'Jurassic Park' - 50-57 FPS (With transparency blending) 59.7- 60.2 (Without)
'Kirby's Dream Land 3' - 46-55 FPS (With transparency blending) 59.7- 60.2 (Without)
Every other game tried (ten or so) - 59.7- 60.2
Darksavior last edited by Darksavior
I tried Genesis Plus GX again from source and that works. Again, like fceumm, it gets jerky in controls and tearing when the screen scrolls if you go to 3-4 (and it's 60fps all the time) so I keep it at 2.
For snes9x-2010 (built from source), I'll keep it off. It varies way too much per game and I'm lazy to thoroughly test each one. My usual go-to game to test is Megaman X 1's Octopus water level. ~45fps with run-ahead set to 1. I also have speed hacks on "compatible" which is a bigger game changer than this run-ahead thing:P
pce-fast (also from source) works with 2 but I get frame drops at 3 which means this emulator is probably not optimized for it.
I'm using a pi3b+ oc'd to 1.5ghz at 1080p with crt-pi shader.
like fceumm, it gets jerky in controls and tearing when the screen scrolls if you go to 3-4
For snes9x-2010 (built from source), I'll keep it off. It varies way too much per game
pce-fast (also from source) works with 2 but I get frame drops at 3
Are you activating the second core instance for these situations? It's probably a good idea just to leave it on in all situations, as the benefits are huge and according to the developer, there aren't really any drawbacks. If there's still an issue, it may be the crt-pi shader.
Darksavior last edited by
@mediamogul I'm not enabling the second core. Is there a difference?
Is there a difference?
Definitely. Without it being active, I get a drop of 20-30 FPS past a 2 frame run-ahead in both lr-fceumm and lr-snes2010 (The only two cores I've tested). I'm actually able to get a steady 60 FPS with no stutter in lr-fceumm with 5 frames of run-ahead and rewind enabled, which of course is a decent hit to the processor in and of itself.
Darksavior last edited by Darksavior
@mediamogul Ah ok, that helps a bit. Unfortunately, even with the crt-pi shader off, I still notice and feel the jerkyness when set to 3 or 4 (really noticeable at 4) on fceumm/genesis gx so I'll leave both instances enabled at 2. I have the overclock setting on for NES which it's really needed in megaman 3 and probably tons of others.
It also doesn't help when I enable the fix slowdown hack in snes9x2010, which I'll need to turn off and actually look into what games actually need it. So far it's just super rtype.
Interesting. Results with run-ahead on the Pi may end up varying greatly with users, depending on a number of factors. Fortunately for you specifically, if you do plan to continue using it, 1-2 frames generally seems to be all that is needed in most cases.
Are these input lag settings available on 1.7.1?
Shouldn't updating retroarch from source get me to 1.7.3? It still shows 1.7.1 on the GUI. Sorry for a likely dumb question.
@keltron3030 you have to update your retropie-setup script first.
Oh, got it thanks. Now I'm on 1.7.3 and I see latency settings; thanks. Now my hot keys don't work, dammit! 🤪
In trying to read as much as I can to understand run-ahead better, I found where the developer of the feature (Dwedit) has stated that a setting of 1 frame of run-ahead "should almost always be safe" in games that have inherent latency. This likely only excludes Atari 2600 titles, as there is no inherent latency for those games, by nature of how they were programmed, so naturally run-ahead would have no benefit there.
Oh, it's awesome. Totally fixed Contra and MegaMan 2 for me. Thanks guys for pointing this out.
Totally fixed Contra and MegaMan 2 for me.
Last night I held my own and survived all three rounds against Mike Tyson for my first time ever. Of course he won by decision, but my next goal is to "git gud" and send him to the mat with a second round TKO.
pjft last edited by
@mediamogul Thank you for the detailed response. I was hoping there'd be a stable "default-ish" setup that would work for the majority of cases in each system, and then I'd adjust the ones for which it didn't work.
From reading your developments, I believe 2 might hopefully be the right value for nes, genesis, and potentially snes as you're describing - with the 2nd core, of course.
I'll dig into that in the coming week, many thanks all!
I was hoping there'd be a stable "default-ish" setup that would work for the majority of cases in each system
A setting of '1' should actually be stable across the board, barring 2600 games. Anything more in many games will alter your timing in the opposite direction as latency and even create artifacts, such as single-frame 'game over' screens and sprite interactions that shouldn't carry over from your actual input. Still, a setting of '2' is only adding one more frame and it's possible that artifacting would rarely be noticed.
I'll dig into that in the coming week
Let us know how it goes.
Hey guys how to I enable the latency features for just some emulators. Do I need to setup custom emulator config files or is there an easier way to do this through the gui.
You could enable it for individual systems by adding
run_ahead_enabled = "true" run_ahead_frames = "1" run_ahead_secondary_instance = "true"
/opt/retropie/configs/chosen-system/retroarch.cfgabove the #include line
Excellent, thanks a lot.