Force games to sync at monitor vertical refresh (even altering game speed)

[pakoman]

Hi.

Sorry if this has been already answered, but I can't find it.

I'm trying to run 70hz systems like MSDOS or Wonderswan on a LCD with a CRU custom 70hz (the LCD supports up to 75hz, probably a bit higher, but has no freesync support).

So I want the games to be forced to run at the monitor v refresh, even if that alters slightly the game speed (i.e. 70.086 forced to 70.1).

I know MSDOS games didn't care very much about this, but I', trying to get as closer as possible. Are there any settings for this?

I'm using W10 GM 0.228 and a Nvidia card for this one (don't hit me!  ).

 Thanks!

[Calamity]

Hi pakoman,

If you've created a 70.1 Hz mode already, then just force it on the desktop, then run GM with the -monitor lcd preset selected, and -syncrefresh (this should be automatically selected, but just in case).

Of course you could do it a bit better by not having to force a particular mode on the desktop, by following (more or less since you don't have AMD) this tutorial:



SR 2.0 already handles this with the automatic lcd preset without any extra configuration, but on Windows it just works for AMD cards.

[pakoman]

Then I must be missing something on my end:

I'm using Alien Syndrome for Msdos for testing, as the selected character in selection screen blinks every each other frame.

Desktop is running at 2560x1440@70.1
-monitor lcd  and -syncrefresh are in use
-game is 70.086hz using 2540x1440@70hz

But the character doesn't blink steadily. I don't know if the original was like that...

I've attached a log

[Calamity]

You need to set -waitvsync too, -syncrefresh doesn't force it alone (-autosync does handle both when enabled).

That said, the game you're running doesn't seem to request 70 Hz, but 60.0x instead.

[pakoman]

By using -waitvsync I get the same result.

If the game is supposed to sync at 60hz and I force it to 70, it should be smooth at the requested (faster) speed, shouldn't it?  That's not happening.

Efectively in the log says:
Switchres: Resolution change from 720x400@60.054866 normal to 320x400@60.054866 normal
Switchres: Calculating best video mode for 320x400@60.054867 orientation: normal

which seems to mean that everything is trying to use 60hz instead in 70hz, however Machine information screen reports 70.86hz when the emulation starts (ct486) and 70.085 when the game loads.

So the whole thing is running at 60.xx hz as reported by the log whereas the information screen reports 70.xx hz

In the other hand, if  the game is less than 62hz it should be fine on my freesync monitor but it's not Still does the same, which makes me think that Mame is not properly reporting the screen refresh for DOS games. Could that be the issue?

I think I'm having a deja-vu about this whole thing...except for the freesync monitor, that's new


I've tried wonderswan with a custom 75.47hz resolution and still the scroll stutters quite often, but it seems that even if I make a custum 75.47hz resolution it gets rounded somewhere in the process to 75hz. Which seems to be happening with Msdos as well (70.086hz rounded to 70hz).
It seems something in my setup is meesing up things   

[Calamity]

I've confirmed the problem here. GM picks the refresh from a screen property that doesn't seem to reflect the changes that happen as the emulated machine changes its refresh. I have changed it so it reflects the current frame period, and it works now. It'll be ready for next version (this week).

[pakoman]

Really?   

Great! happy to help even if it s just by finding a bug by accident...

Looking forward to try the new version

[Calamity]

Yes, and now I remember why I did it like this. The frame period is initialized as 60 Hz for all systems, so if I take that value as input for SR, all games would start at 60 Hz, then switch to their correct refresh. So I took the other value, that starts with the correct refresh but doesn't change later.

Now what I've done is to check if the frame number is zero and then take the refresh as I did before, then afterwards if frame number is more greater than zero, use the other correctly initialized value. It seems it's working fine so far.