Jittery/Stuttering graphics
-
Gsync enabled has solved the issue. I was wrong to say it doesn't happen in lr-fbneo because I started testing Samurai Showdown with and without it. I was able to switch it back and fourth and see that it was clearly having an impact. I played SFA2 again for mame for quite a while without any problems. There's some audio crackling and slowdown for lr-mupen64plus-next, which I never saw the problem occur in anyway, and in my few minutes with lr-pcsx-rearmed and lr-flycast I didn't notice any audio crackle or slowdown.
I'm glad I came here to ask. It's hard to believe there aren't more people bothered by the stuttering. That kind of stuff can drive me crazy. I hope you all can figure out all the beeps and boops. I'm gonna donate and play some crap now.
-
@Quackwalks Great to hear. Have fun and enjoy!
-
I've got the exact same issue with ES in general. V-sync simply doesn't work. Video previews suffer from tearing too.
"Sync exact framerate" option in retroarch enables synchronization BUT it slows down framerate. Last update of Redream with vsync enabled gives me screen tearing and stuttering too (sonic adventure).
My desktop Pi4 with Raspbian had the same issue, vsync didn't work at all. I had to install Compton and enable vsync in config file in order to have a smooth experience.
But in retropie it seems a little bit different. Installing compton in pixel desktop interface via the terminal makes some weird stuff like black screens and vsync is still off. I'm not a linux specialist so I don't know what to do next to have a decent framerate with vsync in Retropie...
I've tested 2 different monitors : a 4K Samsung Smart TV and a 1440p G-sync 144hz PC monitor. Screen tearing everywhere, or low framerate... Exact same scenario in each case.
Kernel 5.4 doesn't help either. -
@Yobiwan are you running retropie from the Pixel Desktop?
-
@dankcushions said in Jittery/Stuttering graphics:
the pi models do not support g sync/free sync.
I suspected as much. But what does that option that's clearly described as only working with GSync/FreeSync in the RGUI/XMB and the web? Are all the people who report that it helped them (presumely on a Pi) imagining things, or is the description wrong/incomplete?
@pjft said in Jittery/Stuttering graphics:
@Clyde Info on the option:
https://github.com/libretro/RetroArch/pull/7019 and https://github.com/libretro/RetroArch/pull/7042
Thanks, but both issues also only seem to address Variable Refresh Rate (VRR) on G-Sync compatible monitors as far as I understand.
That said, there was a similar discussion about this option in the FB Neo thread, beginning with this post, and followed by an interesting exchange between (mainly) @Riverstorm and @barbudreadmon.
Combining that with our discussion here brings me to the conclusion that this option really does something (undocumented?) even without the proper VRR hardware.
-
@Clyde i believe the option will disable retroarch's audio visual skew, which speeds up/slows down games to match your refresh rate, within tolerance. eg, SNES games which are something like 60.08hz, will be slowed down (imperceptibly) to to 60hz (assuming you're running at a 60hz mode), rather than you seeing a judder every so often. VRR mode may have other effects, but that particular one can be achieved by lowering/zero-ing the skew tolerance, so just do that, rather than leverage what IMO is a bug with the VRR setting. however it may have other effects.
obviously the setting should do nothing/be disabled on non-VRR hardware, but when i looked into it i believe it was hard to interrogate to see if a driver has VRR support since there are several frameworks, so i lost interest.
-
@BuZz No, retropie boots directly. I managed to get rid of tearing by enabling kms in config.txt. It looks great ! But I've got some sounds issue and crashes when scrolling titles. I will try to reinstall Retropie from the beginning and activate the kms driver before adding roms and configuring everything else.
-
@Yobiwan said in Jittery/Stuttering graphics:
@BuZz No, retropie boots directly. I managed to get rid of tearing by enabling kms in config.txt. It looks great ! But I've got some sounds issue and crashes when scrolling titles. I will try to reinstall Retropie from the beginning and activate the kms driver before adding roms and configuring everything else.
Just to confirm: You're using full KMS (vc4-kms-v3d) instead of fake KMS (vc4-fkms-v3d)? My experience is that Linux kernel 5.4 + vc4-kms-v3d removes any traces of tearing, but I haven't investigated if it was kernel 5.4 itself that did something or if it was the switch to full KMS. My assumption has been that it was the full KMS driver.
I'd recommend anyone having issues with the default config to try full KMS to see if it improves things. It's not ready for release and lacks some features of the fake KMS driver, but it might still be worth trying it out.
-
@Brunnis Yes, full KMS. I was using a custom image from the Supreme team (wolfanoz 256GB). Really impressive work, but I haven't found any solution to make KMS work correctly. I rebuilt an entire new image from official retropie 4.6 and it works amazingly well. I've spent a lot of time to configure all kind of stuff, and no more tearing. I don't know what this team has done but it was unplayable here.
-
@Yobiwan We don't support 3rd party images - wrong/broken configuration is one of the many reasons.
-
I was searching around for more instances of stutter or sync issues when I came across this thread. So I curiously went to video synchronization settings and disabled vsync and enabled VRR. I have to say I think this solved my issues with such games as MK2 on Mame2003 and RaidenDX on FBNeo (Pi4 stock). The monitor in my cabinet has freesync, it is an AOC gaming monitor. If this is actually the solution to my issues with Flycast, which I will have to reinstall and find out, I will post here. I had some major screen tearing with Flycast so I uninstalled it. But now I am very curious! This might set aside the notion that KMS is the end-all to the issues.
-
@greenhawk84 the pi is not capable of deliver a freesync signal. this is discussed above, but also see this comment from the foundation: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=225940&p=1386442&hilit=freesync#p1386442. should be easy enough to verify using the OSD of your monitor, if it outputs the current display hz.
now, enabling the option in retroarch does yet have effects on non-VRR systems. one of which is to stop retroarch's audio visual skew, the intention of explicitly to stop stuttering by matching the framerate to your display. so, if disabling it has the opposite effect that sounds to me like a misconfigured core, display, or system, but who knows.
on a game like MK2 the audio visual skew should not even be in effect since it's framerate is ~53hz (i believe raiden 2/DX is the same), which is way outside the default tolerance of 0.05 from display for the skew to take effect. to that end, one would expect stuttering with MK2 on a correctly configured system, because it's ~53hz on a (typically) 60hz display - that's correct behaviour. i would suggest what is happening is that when you disable vsync you are swapping a stutter for a tear, which perhaps is more pleasant, but it says nothing about the fkms tearing issues on normal 60hz content.
-
@greenhawk84 said in Jittery/Stuttering graphics:
games as MK2 on Mame2003
You should probably consider switching to FBNeo (or maybe a more recent version of MAME), nowaday our midway emulation is very accurate, as a matter of fact MAME2003 doesn't emulate shadows on MK2 while FBNeo does.
-
@barbudreadmon Mame2003 cores do emulate the shadows for MK, I just have the regular installs from the binaries. I have Mame2003 and Mame2003-plus installed for experimenting.
I found the vsync option in the main opt/retropie/configs/all/retroarch.cfg so I can globally disable vsync, but I cannot globally enable variable refresh. Does anyone know where that setting resides in the config files? For some reason, even though some are saying it does nothing, I honestly feel like it does do something. I dont know maybe if this is a placebo effect happening :D
-
@greenhawk84 said in Jittery/Stuttering graphics:
Mame2003 cores do emulate the shadows for MK
I was talking about MK2, shadows are missing on most stages when using mame2003 cores for me
Only a few stages seem to show them.
-
@barbudreadmon ohh, maybe I didn't test as thoroughly as you, I will try more stages to check it.
-
@greenhawk84 said in Jittery/Stuttering graphics:
@barbudreadmon ohh, maybe I didn't test as thoroughly as you, I will try more stages to check it.
You get to see 8 different stages in the attract mode, only one of those stages seems to have shadows (the one with the portal in the back). I'll be honest, i haven't done a playthrough to confirm the bug also happens outside of attract.
-
So back to the topic of jittering or tearing, I swear this setting is doing something good for my setup, because I was having screen tears and now they are gone:
Does anyone know where this setting is at in the .cfg files?
-
@pjft said in Jittery/Stuttering graphics:
@Quackwalks it should be
vrr_runloop_enable = "true"if I recall correctly. I ended up reading the code on GitHub and digging into it from the initial commit.
This is the option you're looking for.
-
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.