Retroarch 1.6.9 update slowing emulations down?
-
@andershp You can try and uninstall, then reinstall the emulators causing the problems. Not sure if that gets rid of anything that was altered. Still interesting how both of you have the same problem. You can also re-install retroarch from retropie-setup.
-
@darksavior
Hello from the other thread. I tried removing and re-installing retroarch as you suggested, but that did not work.Could the slowdown have something to do with the Pegasus frontend? Both myself and AndersHP had it installed, I think. I'm not using Pegasus right now, but I did still have it installed on the Pi with slowdowns. Although the slowdown still persists after I've uninstalled it.
-
@slimy said in Retroarch 1.6.9 update slowing emulations down?:
@darksavior
Hello from the other thread.I must have called a thousand times :)
Joke aside, here's a list of tested games and how they perform. Note that pretty much all games I've been playing before, with no problems.
MAME2003:
1941, 1942, 1943, 1944, Alien vs Predator, Battle Chopper, Dodonpachi, The Punisher: Everything OK.
19XX, Air Gallet, In The Hunt: sound stuttering when much happens on screen. Game playable though.
64'th Street, After Burner II, Dangun Feverun: All sound stuttering, including music. Very slow video & audio. Completely unplayable.Sega Megadrive & Sega Master System: All games tested ok!
NeoGeo (fba 0.2.97.39 romset): All games tested ok!
SNES (lr-snes9x2010):
Chuck Rock, Donkey Kong Country: All ok
Aero Fighters, Aladdin, Chrono Trigger, Choplifter III, Brawl Brothers, Donkey Kong Country 3: Sound stuttering, games playable though.
Alien 3, Clay Fighter: All sound stuttering, including music. Very slow video & audio. Completely unplayable.This was my list. I don't know how to check emulator versions - sorry for being such a n00b! But before testing I updated everything, cores, and kernels and whatever.
-
@slimy said in Retroarch 1.6.9 update slowing emulations down?:
MAME2003:
19XX, Air Gallet, In The Hunt: sound stuttering when much happens on screen. Game playable though.
64'th Street, After Burner II, Dangun Feverun: All sound stuttering, including music. Very slow video & audio. Completely unplayable.Hi i only made changes to the MAME2003 codebase i never touched the code for the consoles or FBA, from the list above i made small tweak
the CPU comms to fix game speed in Avenging Spirit i suppose in doing that it might have broken the game speed for the other Mega System 1
games eg 64th street it'll be easy to revert that change if it's causing problems although it doesn't on any other platform, Sega core
has been rolled back to the previous libretro mame-2003 version so that should be good again.You mention In The Hunt which is an IREM92 game Dangun Feveron is Cave i've touched nothing in those drivers which should affect
game speed so im at a loss here as to why this would happen in your build.Arcade Addict
-
@gamez-fan as stated earlier, I think the Retroarch update stresses my system in a way that's giving the pi less headroom. The games struggling seems to be the ones with more advanced graphics/sound, or is it just me? I don't think this is because of tweaking in the code.
I will try a clean install tomorrow and see if that rules out my microsd.
-
-
@darksavior said in Retroarch 1.6.9 update slowing emulations down?:
@slimy As I already told @AndersHP, we are getting nowhere in troubleshooting this...
As I stated, I'm no coder. But I provided a list above, hopefully this could help? Otherwise, please tell me what to look for.
the easiest way is to try a clean install. Also, try building the emulators from source to see if that makes a difference.
I will try rebuilding from source and then ultimately a clean install.
This is great and all, but as all my scraped art is on the SD, this process will take me many days to recover from, and will tell nothing about what happened.@Darksavior when you say Filezilla via Ethernet, do you mean connecting my pi to my router or Ethernet between pi and computer? Have you tried writing to EXT4 with either Paragon (Windows) or Fuse (Mac)?
-
@andershp i suspect it's your lag reducing settings: https://retropie.org.uk/forum/topic/13263/input-lag-guide/7
retroarch updates may have changed how they affect things, who knows. if you've been changing that sort of stuff then all bets are off.
-
@andershp You can make a backup of your whole Image with win32diskimager too if you don’t want to manually backup with transferring by FileZilla.
-
@dankcushions said in Retroarch 1.6.9 update slowing emulations down?:
@andershp i suspect it's your lag reducing settings: https://retropie.org.uk/forum/topic/13263/input-lag-guide/7
retroarch updates may have changed how they affect things, who knows. if you've been changing that sort of stuff then all bets are off.
You, sir, just saved me from a ton of work! Thank you!
@Slimy have you tried deleting your retroarch.cfg file in opt/retropie/configs/all and then reinstall Retroarch from the Retropie setup menu?I just did this, and then transferred only my changes regarding controls, to the newly generated retroarch.cfg file, and it helped in every one of the games with issues!
-
Can any folks who are experiencing slowdown with the new RetroArch 1.6.9 let me know their video_max_swapchain_images setting? If you check via the interface, it's the "Max swapchain images" in the Video menu.
The Broadcom vendor driver was not respecting a swapchain value of 2 or lower until support was added in RetroArch 1.6.9. Now it works, and a lower value does decrease input latency, but it also increases the GPU rendering strain. It's likely a good setting for 8-bit era emulators, but will cause strain for more CPU/GPU intensive emulators...
-
@psyke83 Yes. My old retroarch.cfg file had video_max_swapchain_images set to 2, and now I'm running it at 3. I don't know if this was the entire solution for me though, I can see there's many new lines in the new file.
-
Thanks. So the "solution" is to use the default swapchain of 3 for the intensive systems such as SNES. Guides that advocated using a swapchain of 2 were technically correct, but it never made any difference until now.
You could try tweaking other settings (e.g. enable threaded video rendering) to see if the stutter can be improved with a swapchain of 2, but I'm uncertain if that will put you in a better or worse situation when it comes to input latency.
-
@gamez-fan How do I get the optimized Batrider experience? I tried the 0.78 rom and lr-fbalpha, but this game generally ran much better on my old setup in 1.6.7 (with video frame delay 5 and video threaded set to false) in either case.
But should I update lr-MAME2003 from source before I get these optimizations?
-
@psyke83
Yes, this solved the problem, but had other video settings added, (see post above) - don't know if these added to the problem also. -
@andershp said in Retroarch 1.6.9 update slowing emulations down?:
@gamez-fan How do I get the optimized Batrider experience? I tried the 0.78 rom and lr-fbalpha, but this game generally ran much better on my old setup in 1.6.7 (with video frame delay 5 and video threaded set to false) in either case.
But should I update lr-MAME2003 from source before I get these optimizations?
Sure grab the the latest source and give the game a whirl i hear it does perform a bit better now.
-
@psyke83 said in Retroarch 1.6.9 update slowing emulations down?:
Thanks. So the "solution" is to use the default swapchain of 3 for the intensive systems such as SNES. Guides that advocated using a swapchain of 2 were technically correct, but it never made any difference until now.
You could try tweaking other settings (e.g. threaded video rendering) to see if the stutter can be improved with a swapchain of 2, but I'm uncertain if that will put you in a better or worse situation when it comes to input latency.
latency and stutter are two different things. these aggressive latency tweaks can only cause or increase stutter (frame drops) at the possible improvement in input latency. i cover them all here: https://github.com/RetroPie/RetroPie-Setup/wiki/Input-Lag
not that it appears it has dissuaded anyone from using these tweaks :/
-
@dankcushions said in Retroarch 1.6.9 update slowing emulations down?:
@psyke83 said in Retroarch 1.6.9 update slowing emulations down?:
Thanks. So the "solution" is to use the default swapchain of 3 for the intensive systems such as SNES. Guides that advocated using a swapchain of 2 were technically correct, but it never made any difference until now.
You could try tweaking other settings (e.g. threaded video rendering) to see if the stutter can be improved with a swapchain of 2, but I'm uncertain if that will put you in a better or worse situation when it comes to input latency.
latency and stutter are two different things. these aggressive latency tweaks can only cause or increase stutter (frame drops) at the possible improvement in input latency. i cover them all here: https://github.com/RetroPie/RetroPie-Setup/wiki/Input-Lag
not that it appears it has dissuaded anyone from using these tweaks :/
In an ideal world, reducing the swapchain count can theoretically work without introducing stutter. The problem is that the Pi is a low power device and many of the emulators are approaching the CPU/GPU limits.
My suggestion to enable threaded video with a swapchain of 2 is worth checking, since the Pi is quad core, but most emulators' logic runs on a single core. That may eliminate stuttering caused by a lower swapchain setting, but threaded video also increases latency, so the question becomes whether you will get a net benefit of reduced latency vs. a swapchain of 3 and threaded video disabled.
-
@psyke83 i see what you mean, but you should be clear that you mean to turn threaded_video on as typically they're all turning it off (on is the default in retropie). i actually have started making a little automated test suite which could be used to finally dial in what can and can't be handled by a pi: https://github.com/dankcushions/retropie-auto-testing (it's super not finished now), but it would still need a brunnis-style input lag test to see if there's actual benefits in such situations.
-
OK, I edited my post to make it clearer. I was replying to @AndersHP with the assumption that he/she applied all tweaks on the "Input Lag" page (including threaded video set to disabled), so I thought it would be obvious.
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.