Some games feel stuttery (FBAlpha)?
-
I uninstalled FBAlpha totally and installed from Source. The issue was still there. Loaded Goldenaxe on Mame2010 for a sanity check and it was very smooth.
@caver01 let me know if you find anything.
-
@greenhawk84 well, I am in the process of a total software rebuild on my mini NESPI where I saw this. My thought was along the line of video settings to improve input lag. I know I was playing with dispmanx, and a handful of settings from here. I am not sure if you were exploring similar settings, but it might explain why one emulator is having issues and not everything else if adjustments were made to its retroarch.cfg.
-
@caver01 said in Some games feel stuttery (FBAlpha)?:
dispmanx
I wouldn't recommend using dispmanx with lr-fbalpha, from my experience it prevents screen rotation, which is a big issue with arcade emulators, i don't know if there are other side effects though.
-
Just for the record, yesterday I updated from binary. So far I tried some mslug games and street fighter third strike, they all seemed to run full speed, no issues.
-
You might try running
topto see exactly what is taking up the most resources. Perhaps something is running that shouldn't be. -
@caver01, no I haven't adjusted anything, I keep everything stock except I run integer scale on some games and an overlay. I tried without those options and I saw the performance issue. I am not too savvy on how to confirm the game is running at full speed but displays some jittery movement anyway.
-
@greenhawk84 said in Some games feel stuttery (FBAlpha)?:
I am not too savvy on how to confirm the game is running at full speed
In the RetroArch menu, under 'Video' there's a selection to turn the FPS display on/off.
-
@mediamogul after enabling frame rate display I am seeing 60fps (with a dip to 59.X) once a while but mostly 60fps. I observed the jerkiness at the same time observing solid 60fps.
-
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
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.