Variable Refresh Rate monitor support and testing

[Kappa971]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

An emulator like 86box would benefit a lot from better support for Freesync/G-Sync displays, I could even argue that it would be the only way to be able to correctly display the various video modes and their refresh rates.
Currently, even in games like Epic Pinball that should run smoothly at 60Hz/fps, they aren't smooth. It seems as if the emulator doesn't faithfully display all frames and skips some, although the emulation speed is 100% and the emulated CPU has the necessary power.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Make 86Box more compatible with VRR displays, perhaps by making sure that frames don't skip and are instead displayed accurately.
Make sure that all renders communicate correctly with the monitor: the VRR monitor must sync to 70 Hz if a game runs at 70 Hz, to 60 Hz if a game runs at 60 Hz etc (video modes must be respected). This doesn't work with Vulkan currently. On a 144Hz VRR monitor, 86Box in Vulkan always displays 144fps even if the game is running at 60Hz or Windows 95 is set to 80Hz.

I recommend developers to buy a cheap VRR monitor with a compatible GPU (at least a GT 1030 with Displayport or an RX 550) when possible.
86Box supports a large amount of old machines, each with different video modes and refresh rates, so a VRR screen should be a minimum requirement for using an emulator like this. Fixed 60Hz refresh rate monitors are not good, for example, for DOS emulation.

I apologize for any grammatical errors. Thank you.

[ts-korhonen]

Make any 86box resolution (OS, games, etc) scale to the monitor's native resolution

You need to be more specific if you mean something else because 86Box already has multiple scaling modes just for this task.

The 86box must display the correct FPS related to the refresh rate of the virtual screen: for example if Windows 95 is set to 75Hz, 86box must display 75 FPS in order for the Freesync monitor to synchronize. Same thing if I start a DOS game running at 70Hz.

86Box outputs frames at the rate of the emulated system and it's up to the drivers and hardware to handle it from there. Personally I have a g-sync monitor and Nvidia RTX 2070S and I can confirm that the monitor will adjust to the guest FPS just like you described.

[Kappa971]

Maybe you are forcing Freesync/G-Sync in windowed mode as well? Until recently this created some problems.
Anyway all the emulators I know of support exclusive full screen which is how you are sure everything will work fine, eg DOSBox Staging, WinUAE, MAME, all emulators in Retroarch, etc, all these work perfectly without having to enable an operating mode that is not always stable.
Now if that's fine with the developers of 86box as it is and the work would not be worth your time, that's ok, I can close the discussion, I don't want to force anyone because I understand that this is an open source project, and it is done for passion and not for work, but I imagine that we shouldn't preclude an improvement like this, as we are talking about monitors that will be increasingly popular in the future and are already very important for accurate emulation.

[ts-korhonen]

Maybe you are forcing Freesync/G-Sync in windowed mode as well?

Yes, this is a requirement for it to work. 86Box doesn't have an exclusive full screen mode and the full screen we have is just a borderless window.

The exclusive full screen isn't something we can easily just enable, needs research and labour on all the supported platforms, and I'm not aware that any of the regulars are going to prioritize working on that. So basically it's a help needed situation or ETA someday.

[Kappa971]

I installed MS-DOS 6.22, forced Freesync (G-Sync Compatible) into windowed mode but it doesn't seem to work with 86box.

I understand your priorities, 86box I think is a very complex emulator to develop, but I also think that, if Freesync/G-Sync screens are the only way to display 86box "correctly", the exclusive full screen should be considered among the higher priorities because it affects the accuracy of 86box.

[Tasosgemah]

I have the same problem with OP. I also have a freesync monitor (240hz) but i can't make 86Box sync with it properly so i'm getting stutters/missing frames and irregular scrolling.

@ts-korhonen

Can you test a 2D scrolling game? Earthworm Jim should have smooth scrolling without irregularities or missing frames. That's how it looks when i play it in RetroArch/DOSBox-Pure. But in 86Box (using a similar host CPU), the scrolling looks very irregular and stutters (emulation speed is always 100%).

[shakeyourbunny]

You know that you are comparing apples and oranges?

DOSBox emulates a DOS system on a very high level, has no concepts of a proper system emulation target and is meant to let games run with acceptable results.

On the other hand, 86box / PCem emulates the hardware of a set IBM PC compatible configuration and is designed to do that alongside all other things coming with it. It is not designed for having the best gaming experience, but for best emulation of this system. This also means that it is not necessarily meant for DOS, you can also install run any other operating system the emulated hardware supports on it, ie Minix, Linux, CP/M(-86).

If there is some stuttering and other things, you should test the game first on the same physical hardware and if it exhibits the same quirks. If yes, the emulation is correct.

[shakeyourbunny]

Earthworm Jim does some funky things with the graphics card, as well as Jazz Jackrabbit and Cannon Fodder.

Especially the latter two games have some issues if you don't own the "right" graphics card (I'm talking about real hardware).

[Tasosgemah]

I assumed running the game on an emulated Pentium chip would result in smooth scrolling but yeah, i have no way to know for sure the game did run as smoothly as the consoles on a real system.

Do we know of any 2D scrolling game that's confirmed running at smooth 60fps on a 60hz monitor without hitching? I'd like to see if indeed freesync works with 86box on my system.

[ts-korhonen]

Tested Earthworm Jim 1 & 2, dos demo versions on 86Box, DOSBox staging and a real machine (P200 MMX).
Out of the three, dosbox does have the smoothest scrolling while 86Box and the real machine seem pretty much the same.

[Kappa971]

Any test I can do now is useless and I'll explain why: 86box (but also PCEm) display the fps only based on the maximum refresh rate of the monitor. For example: if I have a Freesync 144hz monitor, 86box always displays 144fps, regardless of the game or the settings of the emulated operating system. Of course, this will never work well on Freesync/G-Sync monitors.
Earthworm Jim (the DOS version) runs at a weird resolution, I think it's 320x224 72hz. On DOSBox Staging runs smoothly because it is "optimized" for variable refresh rate screens. When it comes to emulation accuracy, paradoxically 86box loses against DOSBox Staging in this case.

[ts-korhonen]

I'm pretty familiar with how 86Box renders and I can say that it does already supports variable framerates as it by default outputs frames at the same rate that the emulated system produces them. I can only assume it's down to some difference in host GPU, monitor or drivers if it doesn't "trigger" freesync/g-sync.

I can see windowed 86Box output 70fps on dos prompt, and here you can see it reported by fraps, but my monitor also has an fps overlay of it's own which shows the same number when enabled.

Here's shown how it adapts to selected refresh rate on win98

I don't know of anything else that could be done on 86Box side of things to further improve this (except the exclusive full screen to allow it without enabling windowed freesync/g-sync).

[Tasosgemah]

Maybe i didn't understand this correctly but VRR isn't just about being able to do different frame rates. It's about being able to sync those frame rates with the physical monitor so they are displayed evenly. Those 70 and 85 fps instances will never look smooth on a modern monitor without itself also being 70/85hz, unless it can do VRR at higher refresh rates.

I'm not sure if this is only about the drivers/monitor, i think the programs themselves need to be freesync/gsync compatible as well. For instance, a program like RetroArch has a freesync/gsync option that you can turn ON/OFF and the difference is very noticeable. Most other emulators don't have the feature and the motion they produce feels jittery while the same emulators in RetroArch core form are super smooth (the 3DS core is the most noticeable example) despite producing the exact same frame rates.

I'm not a programmer btw so sorry if this sounds stupid, it's just what it looks to me so far, having a 240hz VRR monitor for a few years and testing a lot of games/emulators.

[Kappa971]

I'm pretty familiar with how 86Box renders and I can say that it does already supports variable framerates as it by default outputs frames at the same rate that the emulated system produces them. I can only assume it's down to some difference in host GPU, monitor or drivers if it doesn't "trigger" freesync/g-sync.

I don't know of anything else that could be done on 86Box side of things to further improve this (except the exclusive full screen to allow it without enabling windowed freesync/g-sync).

I have a 144hz LG Freesync monitor that is "Nvidia G-Sync Compatible" certified so it doesn't have a real G-Sync module inside (but most "cheaper" PC monitors or TVs are like that) connected to an Nvidia GTX 1060.
All games and emulators support exclusive fullscreen so I've never had any problems. I had problems with DOSBox, then I switched to Staging and there too I had the same problem as you described above where DOSBox only draws "the changing frames" on the screen. This is not very good for these type of monitors, I pointed this out to the DOSBox Staging developers and they added a specific mode as mentioned before.

In my case, Freesync in 86box with my monitor doesn't work, even if I force it into windowed mode. This is the prime example of how to force Freesync into windowed mode, it may not work or work well. In my case it doesn't work at all.
Your last sentence actually gives the solution so this will work for everyone 100%, like in the other emulators.

[Kappa971]

Maybe i didn't understand this correctly but VRR isn't just about being able to do different frame rates. It's about being able to sync those frame rates with the physical monitor so they are displayed evenly. Those 70 and 85 fps instances will never look smooth on a modern monitor without itself also being 70/85hz, unless it can do VRR at higher refresh rates.

I'm not sure if this is only about the drivers/monitor, i think the programs themselves need to be freesync/gsync compatible as well. For instance, a program like RetroArch has a freesync/gsync option that you can turn ON/OFF and the difference is very noticeable. Most other emulators don't have the feature and the motion they produce feels jittery while the same emulators in RetroArch core form are super smooth (the 3DS core is the most noticeable example) despite producing the exact same frame rates.

I'm not a programmer btw so sorry if this sounds stupid, it's just what it looks to me so far, having a 240hz VRR monitor for a few years and testing a lot of games/emulators.

I'm not a developer either, but I see many emulator developers who, due to time, priorities or simply because they don't have such monitors, underestimate the importance of this technology, especially in emulators.
You can't display all those graphics modes correctly (even just considering MS-DOS) with a fixed refresh rate screen in the emulation.
I had a normal 60hz screen and it was very limiting in that respect. Obviously until a few years ago VRR monitors didn't exist and emulators were designed to work in an "acceptable" way with all the limitations, but now we have a new technology which in my opinion is extremely important for accurate emulation but, strangely, this is never in the developer's priorities.
I don't want to create controversy or tarnish your work, absolutely not! indeed I admire it, but you should open your eyes a bit and discover that you have a new way to take 86box emulation to the next level, with a more "targeted" support for Freesync/G-Sync that can work properly for all users of your emulator.

I think I have said everything, if this isn't in your plans (at least in the short term), no problem, I think I have made a fairly constructive speech, without insults or expecting anything, just wanted to point this issue out, thanks 🙂

[ts-korhonen]

Maybe i didn't understand this correctly but VRR isn't just about being able to do different frame rates. It's about being able to sync those frame rates with the physical monitor so they are displayed evenly. Those 70 and 85 fps instances will never look smooth on a modern monitor without itself also being 70/85hz, unless it can do VRR at higher refresh rates.

No you understood it correctly. VRR means that instead of display being fixed framerate, it's syncing to the program or game. Traditionally with displays that had fixed rate, programs could either sync to it or suffer from tearing.

RetroArch has a freesync/gsync option that you can turn ON/OFF

The full name of this setting would be "Sync to Exact Content Framerate (G-Sync, FreeSync)". This is actually a feature that 86Box has ON by default due to the nature of the rendering pipeline. On the OpenGL 3.0 renderer there is actually an option to turn this kind of sync OFF because some shaders require a fixed framerate.

In my case, Freesync in 86box with my monitor doesn't work, even if I force it into windowed mode.

Yes. This is the core of the problem. It should work as is. Have you tried other programs or games in windowed mode with the forcing on?

I think I have said everything, if this isn't in your plans (at least in the short term), no problem, I think I have made a fairly constructive speech, without insults or expecting anything, just wanted to point this issue out, thanks 🙂

And it is much appreciated! I hope this problem gets solved somehow, either via new contributors or getting picked up by the existing ones 🙂

[Kappa971]

Yes. This is the core of the problem. It should work as is. Have you tried other programs or games in windowed mode with the forcing on?

I forgot I set Vulkan as renderer. With OpenGL (3.0 Core) and forcing Freesync into windowed mode, something seems to be happening. 86box, on the DOS prompt, displays 70 fps but, in the monitor OSD, the frequency seems crazy (it goes from 50 to 144hz and vice versa). I think it shouldn't do it, considering the 86box is displaying fixed fps.
In DOSBox Staging (which works in exclusive fullscreen), on DOS prompt, the monitor OSD varies from 68 to 72hz and I think it's normal (probably also depends on the panel type), so Freesync in 86box works but probably it's not the optimal way, forced Freesync in windowed mode seems unstable.

[Tasosgemah]

So i spend the day testing PCem today (the latest dev version) where i made a similar guest machine and EWJ1 scrolling is much smoother. Not sure if this is the correct behavior of the game and it's definitely far more pleasing, but i wanted to report how the two programs behave differently.

I think PCem syncs better in general, i felt like other games seem a bit smoother without changes to the actual frame rate.

[Kappa971]

I can tell that 86Box on VRR monitor has some problems as I always notice some micro-stuttering even in DOS games where scrolling should be smooth (scrolling should be smooth even on real hardware, even if I can't test it).
Examples of DOS smooth scrolling games are all Pinball games (e.g. Epic Pinball), which suffer from the described problem on 86Box.
86Box doesn't seem to display frames accurately or I don't know what else the problem is.

[Tasosgemah]

I tested DOOM on PCEm and 86Box. On PCem the frame rate is even, at 35 fps (where the game is locked). On 86box it feels stuttery because of the lack of VRR/freesync. This is definitely an important feature, especially for users of high refresh rate monitors. It's the only reason i'm using PCem as my main, even though it has a host of other issues (like it's buggy CD audio).

[eddmanx]

If the main aim is to match the real display's refresh rate to 86box's virtual monitor refresh rate, one workaround could be to create custom resolutions with the desired odd rates (70 Hz, 85 hz, etc) in the video driver. The downside is that you'd have to manually switch to them every time.

Granted, it also matters if 86box does have a built-in always on vsync, or that it simply caps the max frame rate.
It does seem to use vsync, but if in doubt select OpenGL 3.0 which definitely does have it.

It's the only reason i'm using PCem as my main, even though it has a host of other issues (like it's buggy CD audio).

It works in general but if there are some games that don't behave properly, just mount the bin/cue on the host with something like daemon tools and select it in PCem.

[Kappa971]

What I've realized over the years is that DOS games work differently than Windows/modern games.
Some games run at 15 fps with a 70 Hz refresh rate (e.g. Gods) or 35 fps/70 Hz, others have no fps limit at all, for example System Shock or Build Engine games like Duke Nukem 3D, these produce as many fps the computer's CPU is capable of rendering. With an emulator and a FreeSync monitor, these games will never run smoothly because the monitor is syncing at 70Hz but the game isn't running at 70fps.
Instead Pinball games have some sort of vsync and the games run at 60 fps/60 Hz or 70 fps/70 Hz, so these games can run smoothly on FreeSync monitors, they do on DOSBox Staging. In 86Box these games don't seem as smooth as they should, this on Nvidia GPU and "G-Sync Compatible" monitor (so it's not a super expensive monitor with integrated G-Sync module). Now I have an AMD GPU and I haven't tried 86Box yet but I doubt the behavior is different. This makes me think that 86Box hasn't been tested on VRR monitors at all, which is strange because that's the only way to cover the vast video modes of DOS PCs.

[OBattler]

It hasn't been tested on VRR monitors because I don't have one, for the simple reason - I can't afford one. Which is why I'm still on this AOC monitor from late 2011.

[Kappa971]

I understand your problem, but cheap 75Hz VRR monitors (enough for DOS) don't cost any more than a 1080p 60Hz fixed refresh rate monitor in 2016, maybe they cost less ($100-150). I wouldn't be surprised if your old monitor cost more in 2011 😁.
I think as a developer of such an important emulator, sooner or later you will have to take this big step.
A developer of an emulator like 86Box should own a VRR monitor for testing, because a VRR monitor is the only way to correctly display all the various DOS modes, without tearing or stuttering (although this does not apply to all DOS games, as already mentioned).

Anyway take it as advice 😁

[Kappa971]

I tried the latest build of 86Box (v4.1.1 5605), with the same 144Hz FreeSync monitor but this time with an AMD GPU.
With OpenGL (3.0 Core) renderer, in fullscreen, same problem as with the Nvidia GPU. Games like Epic Pinball which should be smooth, they aren't smooth. It looks like some frames are skipped, but the emulation speed is 100% and the emulated CPU is a Pentium 233 Mhz MMX (more than enough for this game).
The Vulkan render is not good at all because even if the "emulated screen" runs at 70, 60 or 75 Hz, it always communicates 144 Hz to the monitor.

[Kappa971]

@PolyglotCow argue please.

It's not a threat, I'm curious to know what I wrote wrong and what is your opinion.

[Torinde]

Replying to "I can't afford one" with "I give you the advice to get one anyway" (because it's useful/better/cheaper-than-what-you-paid-for-dozens-years-ago/etc.) can be perceived negatively, I assume.

Sorry, if you're already using the Patreon/Paypal "Sponsor this project" options. In such case my comment is out of place.

[Kappa971]

Replying to "I can't afford one" with "I give you the advice to get one anyway" (because it's useful/better/cheaper-than-what-you-paid-for-dozens-years-ago/etc.) can be perceived negatively, I assume.

I understand but why?
Did I say "You must buy a VRR monitor!"? No
Did I say "I order you to develop on VRR monitors!"? No 😆
I simply stated that 86Box has problems on VRR monitors. The developer replied that he can't buy one. I assumed that maybe he is not up to date with monitor prices, and that 75 Hz FreeSync monitors (enough for emulation) are pretty cheap today. I also specified the minimum GPU requirement for adaptive refresh rate.
And I specified at the end that if, despite all this, the developers are still not interested, they can close the discussion and everyone will continue their life.

As already mentioned, 86Box on fixed refresh rate screens is very limited, VRR monitors should be the minimum requirement for good emulation and if developers don't care, that's a shame... not for me but for 86Box.

[OBattler]

Even if it's cheap, you have to realize that not everyone lives in the US where you guys earn thousands a month. I live in Slovenia where even if I had a job, I would be earning €878/month, well, I guess I currently make close to that from the combination of welfare + 86Box donations. So, as you can see, I don't exactly have the money to just throw at a monitor because someone wants VRR support implemented. If it's so important, then why is noone willing to invest the money so I can justify the expense of buying a new monitor when my current one isn't broken?

[OBattler]

And I just checked, the cheapest VRR monitor I can get is for €278.29. For FreeSync, I see €87.19 but that's used.

[Kappa971]

I don't live in the United States.
With a quick search, this is among the cheapest on Amazon Italia, €74.99: https://www.amazon.it/Philips-241V8L-00/dp/B08MQMWK82/ref=sr_1_5?dib=eyJ2IjoiMSJ9.LkfKWAPGe-B6sD9dxcKlphp3ehcxpF8QoxOxGF9r6f57IJ5ZvQ7uvgAut-6TlehQdIZr-aKIbBY0DYylVCNwjgkZv4j5UdlAoZzvRoyRgZxTuI8cx8L4B-vgoHUTyKkGcASai0SSMlMHAgEYPuhk3tN_UVa_3SdfKEm8IMFTUVjkmgHtTxJPvky7TzWPobablswtjL-_zIne5OZYwpxM65kes0T4n042-r6KP0FylK_paCPB7B0zwbLwtpMx18_naSSNIh9-fQjT7A0jHoo9tvOsUGsNJTz9aBeG_NGKiYA.Vz6fcoaQMqRifEpcD0oYrI5qwZ13661neiasRTyeyLo&dib_tag=se&keywords=75hz+Monitor&qid=1714063498&sr=8-5, but I don't know if it works acceptably.
Maybe in your country the prices are very different and so I understand the problem, €280 for a monitor is a lot of money...

[OBattler]

Slovenia is very small - only 2 million people total. This means the bulks ordered tend to be smaller as well, so the transport costs get divided by fewer units, which means the price per unit ends up being higher. That's why a used monitor here costs more than a brand new monitor in Italy or Austria.

[Kappa971]

This is really bad...

[Kappa971]

Considering the press silence, I think I can close this discussion.
It's sad that a major emulator like 86Box aims to only work "properly" on fixed refresh rate 60Hz screens (in reality this is not even the case because these monitors can't display, for example, 70 Hz DOS modes without tearing or stuttering), as well as being inaccurate for the emulation itself.
I hope the developers realize the problem and address it in the future. Good luck, bye.

[OBattler]

We realize the problem. I just have a large pile of work to do before I can get around to doing this and I'm still the one doing the majority of the work. I also don't have a variable rate monitor.

Though, I heard the emulator gets smoother if you choose the OpenGL 3.0 Core renderer, so try that.

[Tasosgemah]

I personally tried OpenGL 3.0 and it doesn't help. As mentioned this is not a performance problem, it's the variable refresh rate not working in capable screens.

[Tasosgemah]

You don't need to close the issue and tag it as "resolved". This will further confuse things and make the issue even less likely to be fixed in the future.

[OBattler]

Also, just to note - 86Box doesn't do any refresh rate limiting of its own, we blit at whatever refresh rate the guest is set to. QT is most likely doing limiting of its own. From a cursory look, I don't really find any way to enable it, but we're going to look into that.

[Kappa971]

Once you have a VRR monitor in your hands, I could help with testing (unfortunately I'm not a programmer).

If you think it's important, I can reopen the discussion but I think it's useless at the moment.

[Kappa971]

Ideally, a freesync monitor should sync with game's fps and not with emulated refresh rate, but some programmers told me that can't be done with emulation, so most DOS games will never run perfectly with the 86Box and a VRR monitor (but this is somewhat accurate with real hardware).

Perhaps with very high-end hardware, it might be possible with Windows 95/98 games with in-game vsync, as long as the game runs at the same frequency as the emulated monitor (e.g. with Windows 95 set to 60 Hz, and the game running at a fixed 60 fps).

[OBattler]

That can't be done even on real hardware - the real monitor has no way of knowing what FPS the game is running at or even what is running on the PC, all it knows is the signal sent to it by the graphics card, the timings of which are specified in the CRTC registers. 86Box replicates that. This isn't a console where the game's FPS is fixed to the refresh rate (consoles did that back in the day because they output an analog TV signal).

As for those games you mentioned - I don't exclude (S)VGA emulation bugs in 86Box, it's in fact more likely. But I also recommend trying the various emulated graphics cards, because a lot depends on the card's I/O access timings as well. You may have simply hit a slow card. Also,the emulated CPU's bus speed matters as well so try the different emulated CPU's as well.

Now, DOSBox and its forks basically emulate graphics cards (and all other devices except for things like the PIT and the sound cards as well) in an instant access way, therefore, not having any I/O access cycle penalty at all.

[Kappa971]

I find your explanation very comprehensive, thank you.
86Box actually emulates an entire PC, in every component (unlike DOSBox), so perhaps this could explain what is happening, or maybe Qt is doing something strange.

However the Vulkan render is not working properly. With Vulkan my monitor always runs at 144 Hz, and this doesn't happen with OpenGL 3.0, so that you know.

[Kappa971]

In fact OpenGL 3.0 has this option:

[Tasosgemah]

Ideally, a freesync monitor should sync with game's fps and not with emulated refresh rate, but some programmers told me that can't be done with emulation, so most DOS games will never run perfectly with the 86Box and a VRR monitor (but this is somewhat accurate with real hardware).

PCem runs fine with VRR.

[OBattler]

Yes, PCem supports native fullscreen, 86Box currently does not but it's in the plans.

[Tasosgemah]

You mean fullscreen in the host side or the emulated OS side?

Even if i use PCem in a window, vrr still works. Or at least i'm getting perfectly even frame rates which indicates vrr works.

[Kappa971]

The PCSX2 PS2 emulator has some interesting options that could perhaps help 86Box figure out where to go to improve things.

In PCSX2, Vulkan only runs borderless fullscreen (like 86Box with OpenGL 3.0). This causes microstuttering even if the emulation runs at full speed (like 86Box) but there are the following options that improve the situation:
Emulation > Maximum frame latency = 0 frames
Emulation > optimal frame pacing (enabled)
Graphics > Rendering > Keep GPU/CPU active while reading (enabled)

As @OBattler already mentioned in 86Box, the emulation of some hardware components maybe could also delay the frames.