the pi would still throttle itself if it hit thermal (or voltage) limits, AFAIK. this just stops it downclocking if it’s idle (or at least, thinks it is).
I think it needs a water-cooler (that would be 3 times its price lol).
I’ve run some more tests with the “dispmanx” video driver and video_max_swapchain_images = 2 using snes9x2010. It works quite well, but there are some issues. Although video looks smooth, there are some audio glitches here and there. It’s pretty obvious in Star Fox. Probably not much to do about it, but let me know if you have any ideas.
Maybe, but someone else will have to answer that, since I don’t know enough about it.
[QUOTE=dankcushions;49439]FYI i think the same result can be used at runtime by setting the CPU governor to ‘performance’. retropie can be configured to do this via its ‘runcommand’ bash script: https://github.com/retropie/retropie-setup/wiki/runcommand#configuring-runcommand
this would turn ‘turbo’ on for only the duration of a game being ran, rather than for the whole time your pi is booted. perhaps something similar could be integrated into retroarch. there are probably analogous CPU/GPU governors on other operating systems/hardware that could be bundled together under the same config option.[/QUOTE] Wow, I had no idea about that! And you’re right, using the performance governor is the same as setting force_turbo=1, so that solution is perfect.
Yeah, force_turbo does not push the Pi out of spec. It just makes sure it actually keeps itself at max clock and not fool itself to lower the clocks. Heat shouldn’t be a problem in this case, since the core’s actually have to be used to really heat up. Since emulators are generally single threaded, three of the cores will be mostly idle.
I believed I had played around with the audio_latency setting and tried to get rid of the audio issues that way, but apparently I didn’t test it well enough. I tried again, setting audio_latency to 96 instead of the default 64 (milliseconds). This seems to have solved most issues with Star Fox, which was the worst offender. So, it seems we may have to add some audio lag to get less input lag… I didn’t notice any delay with the added audio latency during a few quick tests, though, so it seems like a fair trade-off.
Also, I removed force_turbo=1 from my boot/config.txt and followed dankcushion’s advice to modify RetroPie’s runcommand instead. Seems to work great!
You’re mileage will vary of course, depending on what cores/games you run. I only run NES/SNES games and hopefully my testing can at least give you some idea of what to expect. I’ll test this setup by actually playing games over the coming days to see how it works out.
I am also for root enabled features in retroarch.(On rooted android too)
Set max clock speed. Set cpu governor. Set realtime priority. Read/write device files in /dev.
I have installed a fresh RetroPie 4.1 image on my Pi2 and edited the retroarch.cfg to this:
video_driver = "dispmanx"
video_vsync = true
video_threaded = false
video_max_swapchain_images = 2
video_frame_delay = 0
I also edited the runcommand to use Cpu in performance mode.
Is there something else to do to get less LAG?
Just out of curiosity, does anyone know how the new Nintendo NES Mini compares to a real NES regarding input lag ?
Also, there was definitely some lag detected when using it; It wasn’t bad and certainly much better then the Retron 5, but any hardcore gamer will notice right away.
[QUOTE=xadox;50737]I have installed a fresh RetroPie 4.1 image on my Pi2 and edited the retroarch.cfg to this:
video_driver = "dispmanx"
video_vsync = true
video_threaded = false
video_max_swapchain_images = 2
video_frame_delay = 0
I also edited the runcommand to use Cpu in performance mode.
Is there something else to do to get less LAG?[/QUOTE] That’s it! The only thing I don’t know is when the RetroArch executable in RetroPie 4.1 was built. I’d assume it is new enough to include the updated DispManX driver with support for the video_max_swapchain_images setting, but I don’t know for sure. I’d probably rebuild RetroArch from source to be sure.
Is there something else to do to get less LAG?
Increase frame delay as high as possible, but i’m not sure those things have enough power.
Thx @Brunnis for the feedback.
Are those fixes to the emulators by you already included in the latest RetroArch releases or do I have to install those fixed emualtors by self?
Edit: Using the standard gl driver and crt-shader ist not realy usable on the pi2.
I think the XMB menu is not compatible with the dispmanx driver, can someone confirm ?
@Tromzy That’s probably correct. I don’t think it supports GL at all, and XMB requires GL.
@xadox The changes are all in the buildbot cores. Which CRT shader are you using? CRT-Pi should be full speed on rpi2, though it may increase latency.
Yes I was using CRT-Pi with default gl driver. For me the framerate was dropping under 55.
You can try overclocking your RPi2:
[QUOTE=xadox;50789]Yes I was using CRT-Pi with default gl driver. For me the framerate was dropping under 55.[/QUOTE] If you’ve changed any of the crt-pi settings from the defaults you will have almost certainly have slowed it down. Make sure you’re overclocking your Pi to the Pi2 setting using raspi-config.
How are you measuring the frame rate? Turning on the frame rate display in retroarch with crt-pi looses a few FPS.
If you’ve tried to minimise latency by disabling threaded video that might hinder frame rate as well. Retropie defaults to threaded video for the reasons explained in this thread.
If you prioritise minimising lag over looks you’re best off using the dispmanx driver and forgoing shaders even if you can get your Pi running at a solid 60 FPS with them.
Used default values only. But the Pi2 is not overclocked.
Yes, frame rate display was enabled.
Yes, threaded video was disabled.
Actually I am using dispmanx again.
Hi! sorry if this has been answered before, but… if it is used a scanline image overlay instead of a scanline shader in Raspberry Pi, should it have a minor input lag effect? thanks!
for “reduce input lag”, this is important option : “disable desktop composition” for windows , it’s extremly important to desactivate windows aero : http://www.humanbenchmark.com/tests/reactiontime before : 240ms with aero , after 180ms disable aero !
And with anti-micro : https://github.com/AntiMicro/antimicro/releases you can reduce inputlag with gamepad poll rate setting at 1ms (anti micro must run in backround) in option/setting
for look the difference, go download keyboardtest : http://www.passmark.com/products/keytest.htm (free 30 day) and connect a game pad turbo . start antimicro and assing a button with keyboard , active turbo button and push the button : look at the “depresstime”, it’s always at _8ms, 16ms, 24ms, ect … now, change setting/option “gamepad poll rate” at 1ms and try again test : now the depresstime is 4ms, 8ms, 12ms, 16ms ect … I let you understand yourself because my English is too bad to explain to you, but i thing you understand what is happening , the gamepad is queried every 4ms instead of 8ms, this proves the action can start earlier !
it’s difficult to change a polling rate in windows 7 but with anti-micro is simple 
P.S : I think the gap between the inputs max 4ms it’s because of turbo joystick can not go faster, but the polling rate must be at 1ms, now mario jump with a turbo in the ass, mamamiiia !
1 Like
disable desktop composition should be ON or OFF? Mine was OFF and I’m sure I never turned that ON before.