First post, by Alexander Finch
I am using NOLFB with Blood and Shadow Warrior. I can run this in 1280x1024 and 800x600 respectively but I'm getting a lot of screen tearing. VSYNC is forced through my graphics driver but this appears to only work for Direct3D and OpenGL. In 300x240 the frame rate are in the 700’s!
With that in mind could someone tell me how to lock this in DOS at 75Hz for example? Is there a tool out there that I can use?
P.S. I am not running this through DOSBOX (was to damn slow for these games at current – great program though!).
To summarise I need a tool or way to get VSYNC working in Dos Games.
Here is a reply from Ken Silverman: […]
Here is a reply from Ken Silverman:
"> how to force VSYNC in DOS Games do you?
> ...getting really bad screen tearing (around 700fps!)
You can always slow down the frame rate by increasing the resolution. Yes, I
do know a way you could force VSYNC. Using my NOLFB source code (NOLFB.ASM),
you could add a delay to VESA function call 0x4f07. 0x4f07 is the page flip
function and it's called exactly once per frame in all Build games (when
using VESA modes). You could use the RDTSC instruction as a high precision
timer to keep the frame rate stable."
Ken Yeah, ok. It turned out to be a bit more challenging than I originally thought. It was a challenge nevertheless, so I thoug […]
Yeah, ok. It turned out to be a bit more challenging than I originally
thought. It was a challenge nevertheless, so I thought I would take a crack
First of all, I forgot that NOLFB effectively disables all 0x4f07 calls
because when Build is in segmented mode, it uses an off-screen buffer and
blits the image instead of using true page-flipping. No problem. So I used
0x4f05 instead (the function that sets the 64k window). Still nothing. I
forgot another thing. Build calls this function through the VESA protected
mode interface - which effectively bypasses the use of interrupts. No
problem. I disabled the protected mode interface so it would use the
fallback 16-bit routines - kind of like what NOLFB does to the linear frame
buffer. Finally, the frame rate was limited... except there was now another
problem. The game physics was running in slow motion! The reason? When the
system is in 16-bit real mode, any interrupts that occur during that time
are discarded - including timer interrupts! If I had implemented bi-modal
interrupts back in the day, things might have worked ok - at least for the
BUILD editor and the KenBuild game executable. It would have done nothing
for Duke since it uses Jim Dose's sound library for timing. In any case, I
realized that long delays in real mode would not be feasible.
Then I remembered how Build was using those protected mode functions. How
convenient - if I could just hack those delays in the protected mode code,
then interrupts would not be lost and everything would be ok. The Build
Engine queries for the protected mode interface using VESA call 0x4f0a. All
I had to do now was make my own list of pointers with jumps to the original
routines. This turned out to be a bit more painful than I expected... but
hey, I'm Ken Silverman and pain is the equivalent of 1 hour in my world 😀
Please try the attachment. (Rename the obvious mis-named file to .COM first)
The above code (and writing this text) took a total of about 4 hours. If you
can understand half of technical information I wrote up there ^, I'd be
impressed. : P Don't worry about Paypal since I don't have an account, I
don't feel like registering for one right now, and I don't even know if the
damn thing works on your system anyway. If the utility works, then perhaps
you could save me the trouble of mentioning this utility to the guys at
vogons: http://www.vogons.org/ They seem to have fallen in love with
NOLFB - I'm sure they'd be happy to get their hands on this one too. And
FYI, they would actually understand some of the technical stuff : )