I don’t think setting “video_refresh-rate” is doing what you expect it to do. It is not a way to request a particular refresh rate, it is used for dynamic sample rate control in the audio system. It must match your actual monitor refresh rate, otherwise audio will warble. I think the setting should be completely removed on Windows, and instead, it should query the refresh rate from DXGI or possibly D3DKMT.
Thanks for your reply !
I understand “video_refresh-rate” was not meant for that use, and that it does not force my screen to refresh at a specific rate.
But in the end, it is a very efficient way to force the core to run the game at the desired speed.
If you check my video, you’ll see it works (it’s a lot more obvious after 20 seconds game time). I used the “display statistics” frame rate counter to try and get as close as I could to 59.58 fps, which I guessed is the correct fps for CPS3 (which refreshes at 59.583393 hz).
The display statistics show the fps counter switching between 59.53-54 and 59.67-68 I did not even bother to try and get closer since at that time I was just assuming dps3 was running at 59.58fps. Later, I filmed the CPS3 to check my theory, which turns out to be correct.
It is not exact but it works ! If DXGI or D3DKMT are better ways of implementing a custom game speed option for people who run an obtuse LCD screen who will not change refresh rate no matter what, go ahead. Still, so far this, combined to the Runahead feature, allows to finally get very close to the arcade. This is priceless, many thanks Dwedit !
1 Like
the correct approach is to turn off or reduce the audio maximum timing skew option. what this feature does is to adjust the game speed and audio pitch to match with your vysnc hz, within a certain tolerance.
the default is 0.05, which means that, assuming 60hz display, any game reporting a native frame rate between 57-63 fps will be sped up/slowed down slightly to avoid frame judder. the typical use for this is for some (all?) console NTSC games which i think have a natively weird framerate of 60.xxxx
i would expect that mame internally reports the right framerate for CPS3, but this feature is bypassing it. if you lower the tolerance, you should get the right framerate, but if you have vsync on then you will of course get judder. personally, i prefer the smooth gameplay.
Having G-sync Freesync is pretty nice I must say (with “sync to exact framerate” in settings>frame throttle).
The only thing left you need to adjust then is cores that don’t adapt automatically themselves (gotta set MAME to throttle, genesisplus gx to PAL when running 50hz games…).
1 Like
I think it needs the ability to synchonize to content framerate, even with vsync on. This means dropping or skipping frames after a while. For example, a SNES needs to skip a frame every 10 seconds to maintain 60.098Hz on a 60Hz screen.
I think that’s what happens now if you set max timing skew to 0.0000 and have vsync on. It should avoid tearing at the cost of stuttering, right?
1 Like
I was looking into this for VRR screens limited to 60hz and I think doing it like that will introduce sound crackling.
1 Like
To try and run the game the closest to the original I do it like this: Create a resolution with the same dimensions as the original but exacly double refresh rate (becose I use a pc crt) then in RA disable “sound sync”, and enable “sync to game exact framerate”, “black frame insertion” and leave v-sync on. I do it with Crtemu driver, becose I have a radeon video card, but if you dont have one, try using CRU to create the refresh rate like Dwedit sugested, you dont need to enable “black frame insertion” if you dont use120hz.
Ohh… This stuff must’ve been why RetroArch Mednafen/Beetle PSX (PS1) netplay was almost usable on PC with my cousin sometime this year. I’ve looked around many times and never found this thread until now.
The netplay, once I finally got a chance to test it, worked surprisingly well sometime this year, despite how many times I was told it would probably be no good here. But this year it was, to me, surprisingly close, but still not full speed unfortunately.
Now me, I have actually never ever gotten a desync when using PS1 netplay on the standalone (non-retroarch) Mednafen. The big downside to me with that Mednafen is that you can’t do higher internal resolutions and make it look awesome like you can in RA. (Though RA still has some issues with that in some places.)
I really hope that Beetle PSX PS1 can get netplay up to full speed on PC at some point. Is that possible? Not possible? I’m no programmer.
Thank you very much for implementing such a useful and awesome feature. On my PC I’ve tried about 50 games across different platforms and emus (NES / Nestopia UE, SNES / bsnes Balanced, Genesis / Genesis Plus GX, PS One / Beetle PSX, PC Engine / Beetle PCE Fast) with RunAhead turned on and so far I haven’t had a single issue with it, everything works pretty much as intended if configured correctly.
However, I have a question. Is there a reason why it only allows to Run Ahead a maximum of 6 frames? Believe it or not, there are games that have more than 6 frames of lag built in. One good example is Prince of Persia for Sega Genesis / Sega Mega Drive, which has 9 frames of input lag (yes, it is unplayable in it’s vanilla state, but it is also one of the better looking ports of PoP). If there are no obstacles to making this limit higher and if it’s not too difficult to implement, I would like to request to raise the limit to at least 9 frames.
Every frame of runahead requires running the emulator that many frames, so 9 frames of runahead makes the emulator 9 times slower. If it’s fast enough, 9 times slower is still realtime.
You should probably retest that game, Prince of Persia has many situations where you can perform inputs, such as jumping up, crouching, changing direction, etc, and you’d need to see the variance of the number of frames before responding. Just because turning around might take 8 frames one time doesn’t mean it couldn’t take 6 frames if you started it at a different time.
@Dwedit Now that the MAME libretro core supports savestates, is there any chance that you could make the Runahead feature work with this core?
It would be a very welcome addition as the libretro MAME core still suffers from one added frame of input latency versus standalone.
1 Like