Prehistorik 2's skill-selection scroller (might?) be improved, too -- although it seems pretty messy on real hardware.

Hardware (lower drawn regions 'phases out' during vertical sweep)

https://www.youtube.com/watch?v=839fGMjX9qc

Baseline (text periodically judders back in-sync)

PR (text holds)

Prehistorik 2's skill-selection scroller (might?) be improved, too -- although it seems pretty messy on real hardware.

That's horrible, it's not supposed to look like that at all... The guy must have used some late era VGA card with bad backwards compatibility.

The text is supposed to be completely stationary, and the background image should be panning 100% smoothly. It actually used to be like that with DOSBox about a year ago; it was perfect.

It has some artifacts on my S3 (late VGA card) but nowhere near the horrible mess like on that youtube video.

Wonder if using tseng3000/4000 fixes anything.

Interesting 😄 You got this from DOSBox-X @kcgen ?

Not this one; I could change the "occurrence" rate by change the dos_rate so then started looking at other timings. Unfortunately it's a "stochastic" fix, in that I don't have a technical reference - and only using game correctness as a guide. So who knows.. we're probably in for another round of regressions 😅

Unfortunately it's a "stochastic" fix, in that I don't have a technical reference - and only using game correctness as a guide. So who knows.. we're probably in for another round of regressions 😅

Uhhuh... Well, the thing is, if games relied on such timings, that was a recipe for disaster. And that can explain why on some later VGA cards you got glitches. Like many demos requiring some specific brand/type VGA cards to work 100% correctly.

I'm wondering if it's worth messing around with stochastic fixes for a non-breaking glitch in a single game if it can cause regressions and it's not mimicing measured or documented hardware behaviour (too risky).

I think it's worth it - these two games were early 90s and normally look perfect on good hardware -- and both actually get better by tightening up this timing.

DOSBox's default was to lag by 50ms of tick time from when the request came in before it takes effect and to set the mode (and pushes the signal out to the monitor).

50 ms is over 3 frames of lag where the prior mode is still ticking along.. meanwhile, most games have prepared themselves for the new mode at the time of the request.

The fact that both these games' rendering glitches improve when we tighten this up says we're "pulling" it in a more correct direction.

(I've also regression tested the suite 'oddball video mode' games and programs, and all are still OK)

I think it's worth it - these two games were early 90s and normally look perfect on good hardware -- and both actually get better by tightening up this timing.

DOSBox's default was to lag by 50ms of tick time from when the request came in before it takes effect and to set the mode (and pushes the signal out to the monitor).

50 ms is over 3 frames of lag where the prior mode is still ticking along.. meanwhile, most games have prepared themselves for the new mode at the time of the request.

The fact that both these games' rendering glitches improve when we tighten this up says we're "pulling" it in a more correct direction.

(I've also regression tested the suite 'oddball video mode' games and programs, and all are still OK)

Yeah, we can give it a go, it's easily bisectable 😄 Actually, 99% of games just set a standard mode via BIOS anyway and then forget about it, which narrows down the regression testing to our "special" set of games that use weird custom resolutions, etc. This should make no difference to most programs, which is good.

Ok, let's give it a go! Thanks @Burrito78 for the testing, and @Grounded0 and @johnnovak for all the technical help 🚀