For Retroarch there is no need for frame limit. This is mostly for 3D games running above 60 fps. On Nvidia settings I have:
Max Frame Rate: off
Preferred Refresh Rate: application controlled
Vertical Sync: use 3d application setting
So Retroarch display the proper monitor refresh rate (100 in my case instead of 97)
There’s no need to cap the frame rate. It’s likely the frame rate limiting function is eating into the time margin per frame and leading to stuttering. ULL should work fine with RA. I use ULL globally.
I never used frame cap before. I was just curious that OP uses frame cap and why they don’t get the slowdowns I get when I enable frame cap.
Hey I disabled the global frame cap as it didn’t make much sense unless I was playing only pc games like Hades that easily reach the max frame rate without graphic settings trade offs and it wouldn’t make sense with a vrr display anyways since I can also play at 100 FPS for example and keep higher graphic settings. So I cap FPS on a game by game basis now.
So now for Retroarch I use 60 FPS cap via the Rtss capping option and it works great, frame time is perfectly steady now, just probably going to be bad for pal games limited to 50 FPS or other games limited to 30 FPS though. The Retroarch arch menu feels sluggish though at 60 FPS but I guess there’s not way around that. I removed the auto run ahead game and vsync.
There are systems that run higher than 60 fps. I would cap to 61 for NES/SNES or 70 if you use DOSBOX.
No Frame Limiter:
RTSS Frame Limiter at 60FPS:
RTSS Frame Limiter at 61FPS:
Seeing that different games and different systems operate at different sometimes non-standard (for modern displays) refresh rates, and system wide frame limiters only seem to offer custom profile granularity down to the application level (not different cores or games within a single app as with ReroArch).
I propose that RetroArch needs its own built-in frame limiter, which would operate in conjunction with the Sync To Content Refresh Rate Feature and set the appropriate frame limit to match the content refresh rate automatically.
While Sync to content refresh rate and VSync already offer relatively constant FPS, when a frame time graph is analyzed, it tends to show lots of inconsistency from frame to frame, within each frame.
This means that there is room for improvement in the emulation experience as these inconsistencies can sometimes affect gameplay and be seen, for example during sprite flickering effects which don’t look right.
RTSS Frame Limiter at 60FPS:
No Frame Limiter:
RTSS Frame Limiter at 54FPS:
RTSS Frame Limiter at 54FPS:
no Frame Limiter:
RTSS Frame Limiter at 53FPS:
RTSS Frame Limiter at 53FPS:
@hunterk, @Tatsuya79, @BarbuDreadMon, @MajorPainTheCactus
Is there any chance that we could get a built-in frame limiter so that we can have per game frame limiting and improved frame timing consistency based on the original frame/refresh rate of the content?
Currently if we have to use external frame limiters, they can only be applied to an entire application at a time, whereas for things to work optimally we would need to apply different limits to different content within RetroArch.
Have you compared frame time consistency with audio synchronization off?
I don’t think a frame limiter is quite right/necessary, but I have actually been working on a busyloop model that should do basically what you’re wanting. I’ve replaced the threaded video functionality in this fork, if you can build and test it: https://github.com/hunterk/RetroArch (that is, for now, you would turn on ‘threaded video’ in the settings, but I completely re-worked what the setting actually does)
The goal for this was, after talking to blurbusters Mark, he was saying that at very high refresh rates, RetroArch’s frametimes aren’t consistent enough for un-flicker-y beam-sim effects, so one of the solutions would be to break the video presentation off to another thread that is decoupled from the content and is instead throttled by the swap timing.
My implementation there is a bit naive in that it doesn’t talk to the individual drivers to get the most precise times (e.g., via that new vulkan extension from Themaister and co. that was just merged into Mesa drivers), but it should theoretically be an improvement over the existing method as far as frametimes are concerned.
I don’t have a good setup for testing that sort of thing, though, and I’m not sensitive enough to it to tell just by looking, so I’ve been waiting for testing/feedback of this initial work before going any further with it.
I tried the frame cap setting on my end. It does stabilize frame time but there are occasional blips and so the drop shadow test is not improved. Note that I don’t use V-Sync in RA. I use Fast V-Sync in NVCP.
No I haven’t, but audio is a completely different story. I find that I’m getting crackling in MK 2 in most if not all of the above scenarios even after trying different Audio Latency settings all the way up to the default 32ms. I wanted to save that audio troubleshooting for later though. I don’t mind running my consistency tests again with audio synchronization off.
I don’t mind trying to build and test but I haven’t tried to compile anything in a while so I’m a bit rusty and I think the last time I tried adding CG back in RetroArch, my build didn’t work.
I think I followed some very old build documentation back then. Can you (or anyone else) give me a crash course or at least point me in the right direction please? I’m on Windows 11 Pro 25H2.
I believe running at higher refresh rates / VRR seems to impact audio processing for some reason. When I was running at ~60 Hz (using custom modes to get the exact refresh rate with a non-VRR TV) I could make the audio latency very low. With my 120 Hz VRR setup I have to use XAudio with a latency of 32 to avoid crackles in all cores. Some cores I can use low latency, but in general it’s not the case.
Either that or there was a change in different RA versions, but I don’t think that’s the case. It seem to present itself when I started to use 120 Hz VRR.
I prefer to tackle one item at a time. I don’t generally have issues with audio despite running a 100Hz refresh rate and using VRR. So this Mortal Kombat 2 thing is something that I’ve only just noticed. I haven’t tested that game in ages though.
Mmm I remember if the in-game volume level is set too high, you’ll get clipping in the MK series boards. That’s just how audio on those Midway boards worked. But if your volume is low then it should not be crackling and could be the latency issue.
you can try this build I made awhile back: https://www.mediafire.com/file/v1v1rlrzdyrrrln/retroarch.exe/file
It was compiled using the libretro CI container, so it should work with the libs and whatnot from a typical RetroArch installation.
I’m using the latest nightly from 27/01/26 and I got a sort of soft crash when I enabled Theaded Video after trying the exe. It seems to be affecting my mouse cursor and RetroArch still hasn’t fully recovered even after a couple minutes.
It switched to Windowed Mode but it’s saying Not Responding with a light grey screen. I didn’t load any cores.
I don’t mind attempting the build myself, just would like to know where to start.
I even tried editing my config file and manually enabling Threaded Video but I got the same soft crash when launching RetroArch.
Update:
In the meantime, I ran some audio tests and the crackling only occured when I set my frame limiter to 53 and 54fps. Once I turned it off it was crackle free. It also didn’t occur when I set it to 61fps.
Turning Audio Synchronization Off did result in better frametimes and consistency.
RTSS Frame Limiter at 60FPS. Audio Synchronization On:
No Frame Limiter. Audio Synchronization On:
No Frame Limiter. Audio Synchronization Off:
RTSS Frame Limiter at 60FPS. Audio Synchronization Off:
weird about the freezing.
To compile, if you have a working msys2 toolchain set up, you just go into the RetroArch source tree and ./configure && make -j8 (replace -j8 with however many threads you want to give it; I use -j3 on my crappy laptop)
Not sure if it has anything to do with me being on the latest nightly but I’ve seen strange issues in the past on another system which used an RX6600 when enabling Threaded Video with the BSNES Core loaded. I think it used to immediately crash RetroArch to desktop and wouldn’t save the changes. It might have something to do with VSynch being enabled at the same time or something like that. That’s where I got the whole idea about changing the setting manually from.
Anyway, I just finished updating my msys2 environment and I’m at the part where I’m supposed to clone RetroArch and Libretro Repositories.
Following this guide:
https://emulation.gametechwiki.com/index.php/Building_RetroArch
So, I just opened minigw64 and ran
git clone https://github.com/hunterk/RetroArch.git
Update:
I then entered:
cd RetroArch
./configure && make -j12
Okay, so I built the retroarch.exe but I’m getting some code execution cannot proceed because avcodec-62.dll, avdevice-62.dll, avformat-62.dll & avutil-60.dll were not found.
So I read and I ran this and I can see the missing dlls.
If you are experiencing a missing DLL error, you can fetch all MSYS2 installed DLLs by executing this line:
for i in $(seq 3); do for bin in $(ldd *exe *dll | grep -i mingw | cut -d\ -f 3); do cp -vu "$bin" . ; done; done
Am I supposed to try to rebuild RetroArch.exe and it will now include the requisite dlls within the exe or something or am I supposed to copy these missing dlls to my regular RetroArch folder which never needed them in the first place?
Okay, I’m seeing the older dlls in my RetroArch folder so I guess I have to update them with the newer versions from the new build.
Update:
I copied all of the dlls which were requested at runtime, now I’m getting these errors which are preventing me from proceeding:
The procedure entry point clock_gettime64 could not be located in the dynamic link library RetroArch.exe.
The procedure entry point _ZSt28__throw_bad_array_new_lengthv could not be located in the dynamic link library libx265-215.dll.
The procedure entry point clock_gettime64 could not be located in the dynamic link library avutil-60.dll.
The procedure entry point nanosleep64 could not be located in the dynamic link library libopenal-1.dll.
I only got this one once though, while the others are recurring.
The procedure entry point FT_Get_Color_Glyph_ClipBox could not be located in the dynamic link library libcairo-2.dll.
Any ideas as to what I’m supposed to do now?
Could all of this be happening because I skipped this step:
Once you are running the MSY2 MinGW-w64 Shell, then you will need to clone the RetroArch and libretro Git repositories.
git clone https://github.com/libretro/libretro-super.git
cd libretro-super
./libretro-fetch.sh
…and went straight to cloning your repo @hunterk?
Is this necessary even if you have vrr display? Because Hdmi 2.1, Gsync compatible and Freesync have some issues that Gsync module displays do not.
Because in my case where monitor does have gsync module integrated, I did not experience any frame stability issues.
I saw that someone requested support in RA for that and it sounded exciting. Hoping some vulkan wizard can implement it without us having to wait too long.
