Absolutely not, the guide is intended for NTSC games on 60Hz screen.
I intentionally used a PAL game on a 60Hz screen to clearly see and understand what every option does. If I used an NTSC game on 60Hz monitor I would never see/hear thus understand what every option does.
1 Like
@James-F this looks like a comprehensive guide. I may get this added to the documentation if thats fine with you and @hunterk or @anon24419061 feel it fits the scope of that site?
1 Like
If not good for docs maybe @James-F could copy this into the guides section of the forum before it gets burried away in threads
Feel free to link this thread or move it to another sub-forum, but copy-pasting is not a good idea because I constantly update it.
1 Like
Maybe tag me when you think its done.
I do think it would better for things like this to be in the guides section. As a whole it would be nice to see that new section build some content
Alright.
If I can edit in the guide section, you can move it there now.
Thank you so much for this guide! 
It would be great to see this become part of the documentation, either because @James-F is pushing commits to github or someone helps periodically updates a version in the docs that links to this thread for users that want the best and latest info.
I think a lot of people are looking for this information in the docs and not finding enough to get them started. Your work is a great step forward even as it is now.
Do you think one of those concepts makes sense in the paradigm for your work on this issue? I wouldn’t want to slow you down from working on the project right here in the thread regardless of any docs!
Are you sure about that? Every time I’ve heard this option discussed it’s been in the context of lowering input lag, not actually performing v-sync operations. In fact, I’ve turned it off and experienced no tearing whatsoever. So I’m pretty sure that isn’t accurate.
You are right, I’ve corrected the guide.
But for some strange reason when I tested it there was stuttering when “Hard GPU sync” was Off, and no stuttering with it On.
I cannot re-create this now, but something probably caused this issues…
The easiest way to see stuttering is to enable temporarily “Black Frame Insertion” even on 60Hz screen, this way it is much more visible when the video is not smooth or stuttering.
I updated the guide.
Removed the Audio Sync=Off nonsense, is should be On if “Estimated Screen Framerate” is properly calibrated.
I added and emphasized the importance of Retroarch being played on the PRIMARY monitor, as in my experience it is the biggest factor in macro stuttering and vsync loss.
I recently purchased few retro consoles (Genesis, Super Famicom) with their flashcarts from krikzz (Mega Everdrive X5 & SD2SNES), to have the real hardware to compare retroarch with.
The most noticeable factors are the feel of the controllers and how smooth the gameplay is.
I view smooth, stutter-free audio/video as a huge part of a good emulation experience.
Having said that, retroarch can give an excellent retro console experience and much more convenient on a CRT when properly set, so much so I choose to play Retroarch with my CRT even though the real consoles are right beneath the TV and also have quality RGB scart cables.
heh, yeah, same here. I have all of the consoles and CRTs, etc., but I usually just emulate via RetroArch for convenience.
Btw, what’s the adviced audio driver for the guide? Xaudio / DSound?
XAudio (default).
Hello all. The problem here is that, if we take the example of R-Type arcade, which has a frequency of 55hz / fps, when synchronizing at 60hz / 60fps, the game works significantly faster than in its original version so ,in my opinion, it breaks the experience. In addition to blocking the vsync of the rom and our screens, we need a speed selector (and/or automation) to adjust (to lower in this case) the speed percentage of the game. I hope you understand what I mean, and sorry for my english, its not my native language.
On a fixed refresh rate monitor, you can either run the game at the monitor’s native refresh rate (~60 Hz) with smooth sync/scrolling (RetroArch’s default settings), or you run the game at its native speed with tearing/stuttering (i.e., vsync OFF, audio sync ON; the ‘sync to exact content framerate’ also does this). There’s no other option.
With a variable refresh rate monitor, you can make your monitor sync at the same speed as the game (e.g., 55 Hz) to have smooth sync/scrolling, no tearing/stuttering and the proper speed (also ‘sync to exact content framerate’).
3 Likes
On MAME you have a ‘speed of emulation’ meter that means ‘1’ is 100%, 0.9 90%, etc …
What I mean is that if, after the whole sync process from 55 to 60 fps, we lowered the whole playback speed, then we do have the original speed with the updated framerrate.
I’m not seeing how that makes a difference. You can’t trick your monitor into running at 55 Hz. It either does (and you get perfect sync at the right speed) or it doesn’t (and you’ll never get perfect sync at the right speed).
1 Like
MAME has advanced options that allows you to keep the framerate attached to the screen refresh and at the same time reduce the speed of the game to maintain the orginal gameplay speed.
You need to calculate the percentage of speed that you have gained by synchronizing the framerate of the game with the screen refresh, and subtract it in the emlation speed option.
So, is it decoupling the speed of the game/engine from the game’s own vsync interval?? Because that’s the only way I can see that doing anything different, but that seems like it would cause all sorts of mayhem with timing/accuracy. Nevertheless, if that’s the case, it would have to be implemented on the core side, since the frame swap is the shared reference between libretro frontends and backends.
1 Like