Retroarch 1.6.9 update slowing emulations down?

[arcadez2003]

@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.

[AndersHP]

@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]

@slimy I use Pegasus. My pi's performance is fine. As I already told @AndersHP, we are getting nowhere in troubleshooting this...the easiest way is to try a clean install. Also, try building the emulators from source to see if that makes a difference.

[AndersHP]

@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)?

[dankcushions]

@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.

[Darksavior]

@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.

[AndersHP]

@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!

[psyke83]

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...

[AndersHP]

@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.

[psyke83]

@AndersHP

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.

[AndersHP]

@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?

[AndersHP]

@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.

[arcadez2003]

@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.

[dankcushions]

@psyke83 said in Retroarch 1.6.9 update slowing emulations down?:

@AndersHP

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 :/

[psyke83]

@dankcushions said in Retroarch 1.6.9 update slowing emulations down?:

@psyke83 said in Retroarch 1.6.9 update slowing emulations down?:

@AndersHP

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.

[dankcushions]

@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.

[psyke83]

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.

[Darksavior]

@andershp I knew it was a config problem. Try the same method for any other emulators causing slowdowns after updating to 1.6.9

[AndersHP]

@darksavior I did and it seems like it worked. My go-to point for latency testing has always been Batrider though, and this surely plays slower (=input laggier) than it did before. But I have not tried updating MAME2003 from source, will do this soon.

Maybe Batrider is generally just a game that's on the limit of the pi.. I tested a bunch of shooters and fighters yesterday and they all seem fine now.

[Darksavior]

@andershp Since batrider runs flawlessly for me, i'd say you still have a config problem. Retropie is already optimized for input lag so anything you modify you're on your own..

As I already said, fba is best with batrider. With the mame2003 binary I got like a .3 fps drop at best, with source like .2-.1 drop in areas where there's a lot happening. If I didn't have the fps counter on then I wouldn't notice.