Help
Duke4.net
DNF #1
Duke 3D #1
So some months ago I stumbled upon a topic at VOGONS forums with a list of VESA utilities (for real VESA video cards). Among others it listed two tools, S3 VBE/Core 2.0 and S3 Speed Up, with the latter being described as "a TSR program, which can speed up most banked VESA modes (no text or 4 bits/pixel modes) and VGA mode 13h (320x200x256) on S3 graphics cards."
As you know, by default DOSBox emulates a S3 Trio64 card so I thought I'd give it a try, especially since a different user previously reported success with speeding up Duke3D in DOSBox this way.
Initially I used the old Gulikoza build of DOSBox that has a built-in FPS counter, but the results felt inconclusive. Then I realised that Duke3D has a built-in frame counter accessible via the DNRATE code, so I ran a series of systematic tests by turning on the counter and then watching DEMO1 from the shareware 1.3D package.
I used the standard DOSBox 0.74-3, Duke3D shareware v1.3D (sound and music disabled to exclude any possible distortions of CPU performance) with DOS/32A, S3 VBE utilities and Ken Silverman's NOLFB. Host CPU is Intel Core i5-3230M 2.60GHz. The variables included:
- emulated CPU cycles count (max; max limit 26800; max limit 77000)
- emulated CPU core (simple, normal, dynamic)
- DUKE3D.EXE video mode (more on that below)
- screen resolution (320x200; 640x480 for VESA mode only)
- S3 Speed Up (off, on)
- NOLFB (off, on)
The initial batch of tests was at max cycles x normal core x 320x200 modes with or without S3 Speed Up. Now to explain the video modes in the DOS version. You probably know that while SETUP.EXE allows to choose between 320x200 "Normal Mode" (which is the standard VGA mode 13h) and 320x200 VESA 2.0 mode (mode 150h), there are a few more options available by editing DUKE3D.CFG. Out of these I picked S3 optimized (Screen Mode 5) and Chained (Screen Mode 0).
Duke's internal frame counter shows pretty consistent results across several runs in each video mode, and DEMO1 contains several scenes where you can look at peak and trough values to compare between different modes.
Without S3 Speed Up, the internal frame counter values are, from highest to lowest: Normal (Screen Buffered) Mode (2) -> S3 optimized (5) -> VESA 2.0 (1) -> Chained (0). That said, Normal Mode suffers from very pronounced screen tearing which is noticeable regardless of cycle values that I tried. Conversely, both S3 optimized and VESA 2.0 show no visible tearing at all.
I used the DOSBox debugger to determine that all modes except for VESA 2.0 were actually VGA mode 13h, so for them I would turn S3 Speed Up for VGA (VGA+), and for VESA 2.0, VESA+. For the latter I also ran both with and without NOLFB. This was needed because S3 Speed Up documentation specifically mentions that it only speeds up banked VESA modes, which is those that do not use LFB.
I have not noticed any significant change of frame counter values for VGA modes (frankly I dropped Chained at this point because it was too slow anyway), maybe something like around +1 gain for mode 5 when S3 Speed Up was loaded. Conversely, VESA 2.0 would get a more noticeable gain (~2-4 frames at max cycle setting) both at peak and trough points, even without running NOLFB which I assume means that LFB is not used for this mode. However, this boosted result would still be somewhat behind either Screen Buffered or S3 optimized modes.
I was then able to reproduce the observed results with cycles capped at 26800 (cycles=max 100% limit 26800), although the actual figures were lower of course, but comparatively they kept the same relational values, with VESA 2.0 mode being slower but getting a slight boost with S3 Speed Up on.
Finally on 640x480 VESA mode. This time I used max cycles capped at 77000 x dynamic core. Using normal core here results in very low frame rate, even at uncapped max cycles. This mode definitely uses LFB because there was no gain with S3 Speed Up on until I ran with NOLFB. However, the boost (~1-2 ticks up the internal counter) was offset by the introduction of screen tearing which is not present when LFB is used. This does not seem like a reasonable tradeoff considering that I could easily up cycles to limit 200000 for example to get better frame rates while keeping the vertical sync feature. But I still think it's an interesting experiment overall.
On a side note, Ken also released an updated NOLFBLIM utility to stabilize frames with LFB off. This was done for actual Windows 98 or so era hardware that did not allow Build games to run at all with LFB on. I did not fully test this in DOSBox with S3 Speed Up because there are unlikely any practical implications for this method, but I believe that it might resolve the screen tearing issue while benefitting from the S3 boost. However, this utility does some complicated "rewiring" of game instructions on the fly, and a preliminary test I just tried resulted in the game not being able to initialise the FM chip.
BTW, I was unable to reproduce the often-reported HUD weapon flickering issue when running 640x480 with max cycles and dynamic core. However if I ran the 320x200 Screen Buffered mode 2 with max cycles and dynrec, I'd get this:
Oh, and using simple core doesn't seem to be noticeably different from normal core overall.
