Nice quick fix @kcgen 🎉 , but we only need the last commit 😄 We've been back and forth on text mode special handling for a while and both of us came to the same conclusion that video output is video output — type of mode does not matter one bit. I'll say it again: I have experienced the issue both in graphics and text modes, in the past, and over the last couple of days too. Definitely in graphics modes as well in QPV, for example, and in the Quake video options menu!

I'll test this later on my Windows box, but just the last commit 😄 I'm quite certain the rest are not necessary (well, the text mode special handling is more than not necessary; that would only cause the fix to apply to text modes and leaving graphics modes half-broken, so that's no good). But we can always discuss, for sure 😄

I'll test this later on my Windows box, but just the last commit

Excellent. Just double check that you're running in throttled VFR mode to exercise that code path.

Then try feeding it changed frames with back-to-back timing tighter that 60 Hz to ensure that it's forced to drop frames (and the commit's "follow up present logic" is used).

Some tricks to ensure you're in throttled mode is to set vsync true in your conf, or have your video driver enforcing vaync and preventing/overriding applications from changing it.

Quake's time demo, especially using openglnb output, definitely runs > 70 fps (and it has a nice flashing graphical text cursor at the end when it reports the results).

Quake's time demo, especially using openglnb output, definitely runs > 70 fps (and it has a nice flashing graphical text cursor at the end when it reports the results).

Yeah, that's a good way. Running my monitor in fixed 50 Hz mode and simply using the DOS prompt in VGA mode at 70 Hz and just executing DIR or something is also a good way. The issue reliably happens then. Or using QPV and just moving around on the screen.

Round two ready:

• Removed text-mode handling.
• vsync = auto now only assumes it's enabled (as discussed above), but we still try to disable vsync (per original behavior).

Testing:

• Text and graphical modes are working fine for me on the Pi, Linux x86, and Mac OS with both output types, as well as windowed and fullscreen.

• Cursor blink rate and text updates are consistent and not visually jarring, despite my system running at 60 Hz.

• Quake timedemo results in 320x200 mode are coming in at reasonable rates (no regressions):

  • 149 fps on Apple M1 with --noprimeryconf
  • 110 fps on x86 Linux (with an Intel iGPU) with --noprimeryconf
  • ~200 fps on x86 Linux with output = openglnb and glshader = none (all other settings default)

Nice @kcgen , I'm gonna test this in 30 mins.

First thing, this fixed the problem @kcgen 🎉 Great job! 😎

Now on to the details:

Reproduction

I found a good way to spot the "too low dupe rate" problem that this PR 100% fixes. Starting at the cursor blink rate is not really reliable.

1. Use lower than 70 Hz host rate. Fixed 60 Hz is fine, 50 Hz is even better. You must use lower than 70 Hz rate to test this!
2. Launch DOSBox with the defaults (--noprimaryconf). Confirm that "throttled VFR" is picked.
3. Start DOS Navigator.
4. Open some directory that has a bunch of files in it
5. Keep pressing the up arrow five times in a row, then the down arrow five times, and keep repeating this, so the cursor bar moves and up down.
6. Establish an even rythm of keypresses. This is important!
7. The latency should be ideally roughtly constant, like on a real computer. But when the lower-than-host-rate frame rate dupe logic kicks in, the FPS effectively drops to 7-10 FPS or something, causing a very noticeable delay. This always throws me off my rhythm!

So, with current main, you get the variable latency problem, which manifests as "I pressed a key, but the screen got updated MUCH later, like 50+ ms later". Super jarring. With the current PR, this problem is finally gone! 🎉

Like it said, but to drive it home 100% this time 😅: not only text modes are affected!. But it's the easiest to spot this problem in text modes. You can do the "rhythm test" by typing the letter "A" or something in the DOS prompt at an even rhythm. Every few seconds, your even rhythm will be "broken" by an unexpected latency spike. Try it!

Results

Tried the above test, then just using thec command prompt randomly, DOS Navigator, QPV (with image preview turned off), a bunch of demos, switching between modes, windowed <-> fullscreen, etc. Throttled VFR was consistently picked in these scenarios and things just worked as they should.

Specifically:

• macOS, ProMotion built-in display (120 Hz capable). Tried running in 60 Hz, 50 Hz, 48 Hz, and 47.95 Hz modes, all work as expected.
• Windows 10, tested with fixed 50 Hz and 60 Hz. Same results, works splendidly, all weird dropped FPS problems and missing frame problems are gone.
• Win 10, custom 70.089 Hz mode. Now this is interesting, the default settings still pick throttled VFR. The scrolling in Pinball Dreams is jerky (both at the credits screen and in-game). If I set vsync = on, there is exactly zero difference or improvement. The only way to get 100% smooth scrolling in VGA games that sync to 70 Hz is to use presentation_mode = cfr. The vsync setting makes zero difference.
• For the record, on my 120 Hz (fixed) ProMotion laptop screen on macOS, the best result for Pinball Dreams is to leave everything on auto. That picks VFR, and the scrolling is not smooth, but it's not horribly jerky either. It's like something in-between, but that's the best we can do because 120 Hz is not an even multiple of 70 Hz.
• vsync = on makes some difference on macOS, but only in 50/60Hz modes, and not for the better. In 120Hz mode it makes no discernible difference.

So, to sum up:

• The defaults are good on all my systems.
• Throttled VFR now works as expected, no weird uneven frame pacing now and then when there are no constant screen updates.
• Throttled VFR just can't do proper smooth 70 Hz syncing, apparently not even when I'm in my custom 70.089 Hz mode. Only presentation_mode = cfr can. Not really a major issue, but wanted to call it out.
• vsync doesn't make anything better on my systems; it's a completely useless setting (on my systems, I need to stress).

Overall, great job, ship it! 😎 🤘🏻

Phew, thanks for raising this issue @johnnovak and running so many extensive tests. I feel like the approach is pretty robust heading into 0.81.
One day we'll all be running displays fast enough for DOS (and this code can all be tossed in favour of CFR all the time :-)

Phew, thanks for raising this issue @johnnovak and running so many extensive tests. I feel like the approach is pretty robust heading into 0.81. One day we'll all be running displays fast enough for DOS (and this code can all be tossed in favour of CFR all the time :-)

One day we'll all be running displays fast enough for DOS

Didn't know I needed some high tech display to run software from the 80s 😆

One day we'll all be running displays fast enough for DOS

Didn't know I needed some high tech display to run software from the 80s 😆

The first affordable 8k wide-gamut HDR 500 Hz+ VRR OLED will be a good candidate to replace my CRTs. Before that happens, it's a matter of different levels of compromises 😎