I think it’s already the case and that Gregor adapted the netplay code to deal with the run ahead setting.
oh cool stuff. but I was also thinking about new games besides emulation. seems like a pretty ingenious idea to circumvent the input lag caused by the engine or platform. especially for fighting games this is always a hot topic for every new release.
Yeah, it could work for anything, conceptually. It does greatly increase the CPU requirements, but that could be mitigated if someone built a game around it from the ground up.
Hey there, first of all, thanks for the efforts, I just discovered RetroArch recently and I must say I am very impressed and pleased with it !
@Dwedit , thank you so much for the Runahead feature, this is something great !
However, I’ve been messing with this and RetroArch the past few months and I noticed Runahead works with the FBA core, but only for a short while (25-45 mins). After that, sound gets garbled and there are big frame drops. The second instance option doesn’t work at all, and completely disables the feature.
I don’t think I saw it reported, is it something you’re aware of and that is worked on ?
I shot some videos to test the reduction of input lag and it is really impressive ! While Runahead is activated, I have the same input lag as arcade playing on a LCD, with som light filters on.
Also, maybe slightly off topic, but thanks for pointing out the custom refresh rates options.
Never managed to get it to work on my PC, but thanks to you, I discovered I could adjust emulator speed a lot closer to any machine’s than what Mame would allow, by setting ” video_refresh_rate” and saving per folder overrides (e.g. I put CPS3 roms in a CPS3 folder, etc…). I made a video showing the difference of pace with a simple adjustment for CPS3 games, namely SFIII 3rd strike. (Contrary to what’s written in the video, I set “video_refresh-rate=59.299999” not 59.3333333 for CPS3 games to achieve something very close to the original).
For instance CPS3 refreshes at 59.583393 hz, and setting the FBA core to refresh at 59.299999 makes the game almost match the original game pace. Would you happen to know why I have to set cores to a lower “video_refresh_rate” setting than the desired one ? Seems to be the same with every core.
Degradation over time with FBA has been fixed by Dwedit in RetroArch recently, just grab a recent nightly.
The 2nd instance not working has also been fixed, but in FBA itself so you have to update the core.
whoohoo ! Great news !
Btw, @Tatsuya79 , thanks to you I changed crt_geom and now have nice scanlines without integer scaling, I don’t remember where I read your reply, but it’s worth a thanks
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 !
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…).
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?
I was looking into this for VRR screens limited to 60hz and I think doing it like that will introduce sound crackling.
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.