Synchronize Refresh — is this needed with wait for vsync?

[philexile]

Hello,

I was having some issues running older games such as Ms. Pac-Man and Gyruss at 100% — they would always stay at 97% or so even with frame_delay set to 0.

I managed to correct the issue by turning “synchronize refresh” off. I also noticed a performance improvement across the board. Games that need frame_delay lowered now play without any problem.

I still have wait for vsync on and all appears to be OK and I haven’t noticed any screen tearing but is this an OK thing to turn off?

Thank you

[philexile]

Ah, actually, I am seeing some tearing in games like LIFEFORCE.

Is there any reason why these older games don’t play well with sync refresh turned on?

Thanks

[Calamity]

I managed to correct the issue by turning “synchronize refresh” off.

GM requires syncrefresh on in order to do most of its thing.

Indeed it's more than that... GM is built around the syncrefresh feature. GM was created because baseline's syncrefresh was broken.

It doesn't make sense to turn it off. Instead, use the autosync option that will turn it off only in the special cases where it needs to.

Is there any reason why these older games don’t play well with sync refresh turned on?

The reason you can't have those running at 100% speed is because the target refresh GM can achieve is somewhat lower than the native one. This is because you're trying to run vertical games on a horizontal monitor. Horizontal resolution becomes vertical, and we soon hit the limit of the horizontal frequency your monitor can achieve. GM lowers the refresh in order to fit that unnatural number of lines within your monitor specs. As a consequence, the speed of the game is lowered too, because we're running in sync with the refresh.

You can control how much difference in refresh you're willing to tolerate, by means of the -syncrefresh_tolerance option. By default it's 2.0 Hz. Beyond that value, GM will turn syncrefresh off and enable triplebuffer instead. Triplebuffer brings speed back to 100% while avoiding tearing, but at the cost of loosing 1:1 frame accuracy. Frame delay does not work once triplebuffer is enabled.

[philexile]

It doesn't make sense to turn it off. Instead, use the autosync option that will turn it off only in the special cases where it needs to.

OK, sounds good!

The reason you can't have those running at 100% speed is because the target refresh GM can achieve is somewhat lower than the native one. This is because you're trying to run vertical games on a horizontal monitor. Horizontal resolution becomes vertical, and we soon hit the limit of the horizontal frequency your monitor can achieve. GM lowers the refresh in order to fit that unnatural number of lines within your monitor specs. As a consequence, the speed of the game is lowered too, because we're running in sync with the refresh.

Oh! I actually have Groovy set to rotate vertical games 90 degrees by default -- I was just being lazy.

So if I leave the vertical games as-is (rotated 90 degrees) then it will play at 100% by default?

You can control how much difference in refresh you're willing to tolerate, by means of the -syncrefresh_tolerance option. By default it's 2.0 Hz. Beyond that value, GM will turn syncrefresh off and enable triplebuffer instead. Triplebuffer brings speed back to 100% while avoiding tearing, but at the cost of loosing 1:1 frame accuracy. Frame delay does not work once triplebuffer is enabled.

OK, thanks for that info. So the default is 2.0 Hz, but what are the other values? Is there any advantage to adjusting this other than to activate Triplebuffer when needed?

[Calamity]

OK, thanks for that info. So the default is 2.0 Hz, but what are the other values? Is there any advantage to adjusting this other than to activate Triplebuffer when needed?

The other values are whatever you want: 5, 2, 0... Hz. The advantage is that it's automatic. You tell GM how much the refresh can deviate before triggering -triplebuffer.

E.g., if you set -syncrefresh_tolerance 0, no deviation is allowed, this means triplebuffer will probably enter when attempting 256p@60Hz (1942) with arcade_15.

-syncrefresh_tolerance 2 will probably allow -syncrefresh to be used in that case instead, making the game run at 58 Hz. On the other hand, pacman will run with triplebuffer because 288p can only run at max 52 Hz with the arcade_15 preset. If you wanted syncrefresh to be applied to pacman too, you'd raise syncrefresh_tolerance higher than 8.

etc.

I mean, once you see the relationship between vertical resolution and max refresh achievable, you see the sense of this setting.