@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.
It doesnāt look too hard to add the extension to vulkan_common, but we didnāt have use any of the other extensions that itās meant to replace. I think it doesnāt really work with how RetroArch normally does things, though it would be useful for the second stage of what Iāve been working on (assuming it even does what I think it should)
No, it should be fine to skip that step.
You should be able to get rid of some of those errors by adding --disable-ffmpeg to your configure step (and --disable-al for the openal one). I think the libx265 and avutil ones are related to ffmpeg, as well, so that should get rid of them, too. Iām not sure about the libcairo one, though.
None of those features are needed for what youāll be testing.
Funnily enough, I was about to rebuild using the arguments you suggested so I went my MSYS2 home folder to delete the old RetroArch.exe but I double clicked it instead and it ran!
Update:
So far I have not been able to enable Threaded Video On in order to test the new feature.
If I open RetroArch then switch off Threaded Video, I get a black screen. If I press Enter, the UI comes back and Threaded Video is turned Off.
The Threaded Video On/Off toggle works fine in my regular RetroArch installation though.
I have a VRR 240hz monitor and i use frame limiters like RTSS and Nvidiaās own all the time for PC games. But very rarely for emulators and never for RetroArch. Itās better to not use frame limiters with it. I tried it a few times and i never got any benefit from it.
even arcade ports have issues. Eg in Windows port of kof98um and Samurai Spirits V, I notice exactly the same slow shadow flickering issue with Mame, if I enable fixed refresh rate on Nvidia. While it flickers correctly if I enable gsync. As a result of slower flicker, game inputs are affected.
It seems they target 60 hz monitors with fixed refresh and vsync on for default config.
VRR seems to be mandatory if you are both on PC games and emulators.
