andyp73 wrote:As ever, the devs don't tell us anything about what they are working on and when releases will happen so the best we can offer is informed speculation.
Unless the stutters are caused by a new feature in v6.0.0 that hasn't yet been optimised or are caused by a bug that affects other, more mainstream, guests (as defined by paying customers) then I wouldn't hold your breath! The use case you have described here is so much of a corner case it isn't likely to get too much attention.
Actually, there's a simple explanation with a far more common use case.
Twenty years ago, I programmed on DOSEMU, an emulator for Linux in the 1990s. Google "mdrejhon DOSEMU" and you'll see my work.
Now I'm the founder of Blur Busters and owner of TestUFO, a monitor testing website, so I'm very familiar with stutter problems.
So I can give you some insight from an emulator programmer, that can help Oracle's paying customers, with what may be a simple fix (if it turns out a more global bug than expected).
One thing I know, about the technology is that VGA 320x200 is a 70 Hertz mode.
And many old educational and scientific applications (not just games) use that mode too.
Some emulators
incorrectly emulate 320x200 as being a 60Hz mode, which causes either
(a) Either incompatibility with the DOS application (including scientific applications),
(b) Or the creation of severe stutters from converting 70Hz to 60Hz
I found there was an emulator that did two framerate conversions
70Hz(emulator)->60Hz(internal)->60Hz(actual monitor)
70Hz(emulator)->60Hz(internal)->72Hz(actual monitor)
70Hz(emulator)->60Hz(internal)->75Hz(actual monitor)
70Hz(emulator)->60Hz(internal)->85Hz(actual monitor)
70Hz(emulator)->60Hz(internal)->100Hz(actual monitor)
This amplifies stutters very badly. If VirtualBox does that, then that is a bug that needs to be fixed for the goodness of all use cases;
The assumption of a permanent 60Hz internal refresh rate, decreases user experience and increases stutter (even including window dragging) and gives emulators a bad reputation, and can reduce the sales of emulators & equipment associated with emulators if window-dragging, animations, fluidity is not as smooth as flick-scrolling on an iPad or Apple product (perfect framerate sync). While sometimes complex to fix, occasionally, it ended up being a simpler fix for a specific emulator than expected. Businesspeople just see "that emulator seems smooth like iPads, but your emulator is stuttery for window dragging on my 75Hz dell", while users like us are canary in coal mines. Indeed, maybe it was an edge case that only affected the DOS game, but I've encountered emulator code that was more globally flawed that businesspeople did not know how to debug (or assumed it's a limitation of emulator), but gamers like me did! Fluidity of emulators are often a hallmark of emulator quality, "wow, that emulator is good, I can scroll my CAD artwork smoothly in my old CAD software!", so debugging obscure causes of stutters are sometimes a good exercise. Even if you are just emulating a virtual machine on a business user who happened to have their Dell office monitor set to 75Hz instead of 60Hz, as one example, a far more common case than a gamer, and one that would probably be easily dismissed too, but bad stutters from window dragging (e.g. Windows Vista Aero being very stuttery inside an emulator running on a 75Hz monitor) are still a hallmark of emulator quality and sometimes just ended up being a simple bugfix. Maybe it is not on Virtualbox, but worth a look-see.
Emulators should be doing only a single conversion
70Hz(emulator)->60Hz(actual monitor)
70Hz(emulator)->72Hz(actual monitor)
70Hz(emulator)->75Hz(actual monitor)
70Hz(emulator)->85Hz(actual monitor)
70Hz(emulator)->100Hz(actual monitor)
Most office DELL computer monitors are capable of 75Hz or 72Hz (including probably at ORACLE's headquarters) and converting 70Hz(emulated)->75Hz(real) has less stutters than doing the flawed triple conversion 70Hz(emulated)->60Hz(internal)->75Hz(real).
Best practices, emulators should never have a permanent fixed internal refresh rate, full stop, period, no discussion. And should either synchronize to the source Hz or destination Hz, to avoid flawed stutter-amplifying triple conversion.
An excellent calibration application for perfect motion fluidity would be the MOTION.BAS program (QuickBasic 4.5, with accompanying compiled EXE) at marky.ca/files/dos/motion.zip which was an app I created for my FidoNet BBS in the 1990s. It has become a valuable tool for emulator authors to debug stutters in their emulator, which fixed stutters in all 320x200 70Hz applications.
(A) Quick move: I highly and strongly recommend at least a brief auditing VirtualBox whether it is doing the flawed triple-convert that might be unexpectedly amplifying stutters universally (not just game apps).
(B) Slightly more time-consuming move: (it will help 320x200 scientific/educational/etc applications too). Secondary, if more debugging time is warranted, get a copy of
Programmer's Guide to the EGA, VGA, and Super VGA Cards (many DOS emulator programmers already have it on their bookshelf) and make sure to implement the VSYNC-synchronization register correctly. To correctly emulate the register that indicates the timing of a display's refresh cycles -- make sure to use a closer-to-microsecond-accurate 70Hz timer event (use a multimedia timer event API), not a millisecond-accurate 70Hz timer (common standard-library timer events are not accurate enough to eliminate stutters) to emulate the VSYNC clock correctly. Alternatively, piggyback the VSYNC register value off the monotonically-increasing clock counter (RTDSC instruction or QueryPerformanceCounter or C++ stdlib
std::chrono::high_resolution_clock::now(); (microsecond accurate on Linux, PC, Mac, iOS, Android) .... these simple mathematic tricks to convert RTDSC numbers into a reasonably accurate flag of "Is the monitor currently between refresh cycles now?" VSYNC true/false from it for emulating any emulated refresh rate, including 70 Hz. Many DOS apps poll or WAIT on the register; so the DOS app blocks until the display begins a new (emulated) refresh cycle. You definitely want to do this microsecond-accurate, so do not use plain old event timers PLEASE for doing that. Inaccurate refresh-cycle timing is a common stutter-amplifying mistake in inaccurate emulation -- takes weeks for one programmer to debug but only 1 hour to fix for some other programmers (depending on complexity and how much they understand stutter). And is often a simple code modification too. This will minimize Hz-aliasing problems -- perfectly framepaced 70Hz emulated output will convert with fewer stutters to other real Hz output.
If possible, please audit both (A) and (B) and it covers more than 100x more use cases than DOS games. In simple scientific terms, stutters are simply a beat-frequency artifact between frame rate and refresh rate, so 70fps at 75Hz will generate approximately 5 stutter-vibrations per second for perfectly framepaced 70Hz onto perfect 75Hz. Any worse than that are in my experience, almost always caused by emulator bugs (given performance is already overkill, e.g. emulating apps made for an 8 Mhz 80286 on a 4 Ghz i7) that many emulator authors incorrectly assume is unfixable, simply because they don't understand causes of stutter, and because they don't realize millisecond-accuracy doesn't fix stutters.
Yes, maybe this is just simply a edge case and only specific only to that DOS game. But I'm
also a DOS emulator author and I can hereby confirm I've seen stranger things and I know a possible canary when I see a canary in a coal mine that I suspect affects >100x more users than that said edge case. Give it at least 15-60 minutes of investigation time to verify if that is the case.
Cheers,
Mark Rejhon
)
