Some games feel stuttery (FBAlpha)?
-
Does lr-fbalpha have a frame skip feature? If so, it may be enabled. That, or something similar, would cause visual stuttering while technically still emulating at full speed.
-
@mediamogul said in Some games feel stuttery (FBAlpha)?:
Does lr-fbalpha have a frame skip feature?
No
-
@greenhawk84 I just tried all the games you mentioned on my rpi3@1.2Ghz :
- cps1/neogeo games use 35~45% cpu usage
- golden axe uses 45~70% cpu usage(i think you can lower the cpu usage a lot by playing around with the 3 core options related to sound for this one)
- turtle in time uses 80-85% cpu usage
I can imagine turtle in time stuttering from cpu usage on a non-overclocked rpi3, the others definitely won't.
Also, the dip to 59.X has been there since the old fba core (now named lr-fbalpha2012), and i'm pretty sure it doesn't affect anything (most likely a bad rounding issue with how retroarch compute this).All tests done with latest commit of lr-fbalpha, retroarch 1.7.0, gl video driver, alsa sound driver, scanline shader, core provided aspect ratio, threaded video on, and integer scale off.
-
Tried Turtles in Time, Golenaxe on FBA 2012, very smooth motion.
Here are some settings in FBAlpha photos from my setup:
-
@greenhawk84 Only differences i can see with my setup :
- i don't use integer scale (i don't think this is needed when using simple shaders like scanline.glsl)
- i have vertical sync on (which is the recommended setting, it is mentioned when using the xmb menu driver)
- i have the core option cpu overclock at 100 (using higher value will impact cpu usage on games benefiting from this setting, which include all neogeo games and a few others)
- i use alsa instead of alsathread (i never noticed the difference, and now i notice i have a new "tinyalsa" choice, what's this ?)
- i use xmb instead of rgui (i prefer beautiful menu with tips, even if it's not totally smooth on raspberry)
You didn't mention the shaders you are using
-
@greenhawk84 Also, you should probably consider updating retroarch to the latest stable version (the 1.7.0 release, which is the commit 0a2b44273da17d1b2372cd16469bb74791f7ac95, i don't know if you can force a commit when rebuilding something in retropie though), using retroarch versions outside of the official releases can sometimes lead to unexpected issues.
-
@barbudreadmon
This was apparently added in 1 6.3.RetroArch 1.6.3
General changelog
LINUX: Add a tinyalsa audio driver. Doesn’t require asoundlib, should be self-contained and lower-level.
-
@barbudreadmon, thank you for your tips. I don't use any shaders, only overlays such as the art border you see there. The screen area is transparent so the video is just raw/clean.
-
@greenhawk84 i just checked, there are actually quite a lot of games that will be affected by the cpu overclock core option :
- NeoGeo (all)
- CPS1 (all)
- CPS2 (all)
- System16 (all)
- Toaplan (all)
- Cave (all)
- Irem (all except oldest m62/m63 boards)
- Psikyo (oldest board only : Gunbird, Battle K-Road, Strikers 1945, Tengai)
- Taito (Taito H and Taito B boards only)
- Some unaffiliated games like "Double Dragon" and "1945k III"
With your setting you are basically asking all those games to double their cpu usage, i don't recommend this on a raspberry, you should probably consider using this only for games that have real speed issues in their original hardware (games like metal slug).
-
@barbudreadmon, I originally turned the CPU overclock to 170 to help Metal Slug 2 slowdowns. This was quite some time ago when FBAlpha was performing a lot better on my RPi3 and I never had an issue with other games. I turned it back to 100 per your advice but I still noticed motion jitter. The games are performing at 60fps.
I don't know if I am just sensitive to this issue and others would never notice.
-
I found a pretty good way to test this. Run TMNT: Turtles in Time and let it play the "Game Over" screens. There is plenty of motion with the letters going by and the sewer surf level etc. I ran this using Mame2010 and it was very smooth. I switched to FBAlpha and it was clearly stuttering.
-
@greenhawk84 Hmmm i have no issue in the "Game Over" screens, everything is smooth for me, including the sewer surf, and i'm generally good at noticing issues that appear for a few miliseconds.
Did you try enabling vsync ?Another thing comes to mind : your overlay (i have no experience with those), perhaps you should disable it temporarily to make sure it is unrelated.
PS : this time i didn't disable my overclocking, i ran with the following settings :
arm_freq=1350
gpu_freq=500
core_freq=500
sdram_freq=500
sdram_schmoo=0x02000020
over_voltage=5
sdram_over_voltage=2 -
@barbudreadmon it feels like it improved when I turned "threaded" video off. However, when I save core overrides it wont hold.
-
Threaded video is definitely changing it for me. Tried the first TMNT and it was really jittery until I turned off threaded video.
-
@robotronman I confirm that threaded video is causing this issue in FBA. Why is it when I try to save Vsync to "on" in the Retroarch menu, save core overrides is not activating?
Turn off threaded video and having vsync "on" is making my games in FBA very smooth again.
-
Phew boy, I still battle with all the layers of .cfg's and which ones override the others. I saved "core options" (via Retroarch in game menu) in FBA to Vsync "on" but it also saved integer scaling (because I was playing a game I wanted integer ON), now everything in FBA uses integer by default.
Ah well, I guess I finally narrowed it down to threaded video. Not sure if this is supposed to be on by default or if any of you use it on purpose.
-
@greenhawk84 I know it was a wild ride through this, but if it is any consolation, I know I messed with the threaded video setting on my previous build while I was trying to improve input lag. Of course, I did a lot of things in addition too, so I wasn't really in a position to zero in on this, but I am fairly confident now that you have narrowed it down that this is also why I saw the same thing in FBA.
-
@caver01 I did see a note within the config editor that warned threaded video "may improve performance but introduce stutter" or something close to that statement. I wonder which cases threaded video is useful, perhaps older Pi's needed it to get a leg up.
-
If you've modified the
video_max_swapchain_images, it's most likely the problem.Many "low latency" guides suggest setting this setting to 2 in order to reduce latency. Due to quirks in the Broadcom graphics driver, this setting didn't have any effect until special support was implemented in RetroArch, sometime in November-December. You're probably seeing the stutter because you've updated to a newer RetroArch build that now applies this setting correctly. Unfortunately, setting this to 2 introduces stuttering on intensive (16 bit or later) systems.
Set this back to 3 and performance should go back to normal.
-
@caver01 @GreenHawk84 Hmm this is still weird that i get no issue with threaded video on, so it's most likely a combination with another setting, perhaps the audio driver since threaded video will create separate video and audio threads ? As mentioned, i use alsa, not alsathread.
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.