@MiroKostovBG
PAL and NTSC have different resolutions.
Perhaps when you are running PAL games, the screen output is resized to fit the extra vertical lines (576) onto the screen and that 'squishes' in the sides a bit. NTSC only has 480 lines.

You can probably eliminate the top/bottom black bars with overscan settings, but it seems like the left/right bars will likely always be there when playing a PAL game.

@mitu
Yep. Standard gnome ubuntu. Tried it with both wayland and X sessions.
Same problem though. Stutter won't go away.
Note that the stutter also affects sound. It's not a simple TV mode that's causing tearing. My TV is using Game mode.

Have you tried lr-mame2000 ? Should be less demanding than Mame2003.

@sleve_mcdichael

OK, I fiddled with it for like two hours and I found the culprit!

I restored backup of my "bad config" and it was lagging and doing 30 frames per second - as expected.
Then I started deleting lines half of the file at a time and after a lot of problems with auto-generated cfg in NES folder, I found that removing this line stops the stuttering:

video_vsync = "false"

To double-check it, I restored the original "retroarch.cfg.rp-dist" and added this line - it's 100% reproducible on my system. Put it on "false" and it's choppy, put it on "true" or remove it and it's not choppy.

Without this line, it is:
-> not choppy with vsync ON and any setting Max Swapchain images
-> not choppy with vsync OFF and Max Swapchain images 3 (default is 3).
-> choppy with vsync OFF and Max Swapchain images 1 or 2

If I put this line in, it's choppy whether the vsync is OFF or ON
-> It's choppy with vsync OFF and any setting Max Swapchain images
-> it's choppy with vsync ON and Max Swapchain 3 (default is 3)
-> it's NOT choppy with vsync ON and Max Swapchain images 1 or 2.

I guess something happens when retroarch.cfg has 'video_vsync = "false" ' line and Max Swapchain images is set to 3, behaviour is the same with Max Swapchain 1 and 2.

Also - why would vsync OFF make it choppy? It should make it less choppy with some potential screen tearing - it makes no sense!

I really dont have time to read that all, sorry.

@mitu yes, that is the file. Unfortunately I don't recall if I configured it with the Forced option during my install, but if you say that script is used only in the Force mode then I very likely did. Let me go back and reinstall to see.

Regardless, if that mode is available, some people will use it, and will run into this issue, even if as you say it is not recommended. In such cases hopefully their search will turn up this post.

We don't support 3rd party images, especially the ones loaded with ROMs. Ask the vendor for support or use the image from http://retropie.org.uk/download.

@Smeg this is why we have it disabled by default. see https://github.com/RetroPie/RetroPie-Setup/wiki/Input-Lag#unsupported-tweaks. on a pi4 there seems to be the CPU headroom to disable it on the 16-bit cores at least, but i've not done extensive testing.

@TeeEl Sorry to hear that. My arcade cabinet has a 32" tv, but the problem started for me a few months back. But I couldn't pinpoint exactly what caused the change (I already had a similar post about it). Thankfully for this post, I was able to find an option that worked for me. I hope you do too!

@mitu Thank you, this worked.

@Kalamabrew My guess is that you don't have proper/accelerated OpenGL support in your installation. Scanlines (a.k.a. Shaders) don't work unless you're using the gl video driver, the fact that you're not seeing them seems to indicate your video driver is not gl.
Can you run a Libretro emulator with verbose logging enabled - using the Runcommand launch menu, then get the log RetroArch log file (/dev/shm/runcommand.log) and put it on pastebin.com to take a look ? Do the same for the RetroArch configuration file (/opt/retropie/configs/all/retroarch.cfg).

Hey,
anyone got it FIX?
i have the same issue

The USB hub is internal, I can't change it (well, i could maybe). And I don't use that NESpi case, its a different one called NES case, which even don't look like an NES case (its black). Maybe same poor quality issue. I even don't use the fan, because it is loud as a jet. And that pcb is rated to be used with 4 usb connections plus the fan. Not sure if its a power issue.

For now, I will not try more as I don't want mess it up again. I will get a bigger sd card (from 32gb to maybe 128gb, or at least 64gb) and its all done.

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

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

You really should use FBA for certain Toaplan and Eighting / Raizing games, firstly due to the performance being better and with regards to
some games the Emulation of the sound and music is 100%............

I use FBA for all these for the above reasons

Armed Police Batrider
Batsugun
Battle Bakraid
Battle Garrega
Dogyuun
Fire Shark
FixEight
Ghox (Next FBA release will have sound)
Kingdom GP
Knuckle Bash
Out Zone
Rally Bike
Sky Shark
Sorcer Striker
Truxton
V-Five
Vimana

I checked in my network to see if the Pi would show up but it does not. Either way I get no wifi regardless on the PiZero W. In regards to the GBA, I forgot how the frame rates were on it lol but it seems to be normal. I will check up on a few more Roms on the SNES when I get back home to confirm if it's only a few games being affected.
Thanks for your input

@TMNTturtlguy Not a problem, it should be good to the best of my testing abilities. I did not make a lot of changes as well, so its impact should be fairly self-contained. As such, I don't see how it would have affected the saving.

There's an option to have game-specific core options saved, maybe you had some of those set? I don't see why that would be the case, but it is a possibility. If you do have created a game core for some of your games, then yes, the is the case. If you don't, then saving the option will affect all the games (as all read from the default options).

Cheers! Thanks for helping narrow down the cause for this!

@mediamogul I think I found out the source of the bug, it seems to be the steamcontroller driver. For whatever reason there was no log of it yesterday, but the syslog is filled to the brim with error message from its py script. Plus the timing fit perfectly, one message every 2 secs.
Gotta afk for a couple of minutes, but will report back on it soon enough.
I'm just gonna leave snipet of the log there: http://pastebin.com/qk9uW2dh

Gonna uninstall the steamcontroller driver for now and report the bug to github

EDIT : confirmed steam controller driver is faulty. Back to smooth footage and xbox controller for now I guess. Thanks for not leaving me alone on this one guys ^^.

@mediamogul more info about RetroArch and RetroAchievements compatibility can be found here: https://github.com/libretro/RetroArch/wiki/RetroAchievements