> Think I'll try to implement that on the train ride tommorrow. As far as trying
> to optimize it's really a good idea for me since my laptop isn't very cutting
> edge(3 year old celeron 1ghz) and the integrated graphics leaves something to be
By "very old" I meant 386, 486, and early Pentiums :)
> Now that I'm in the nitty gritty of drawing graphics how is it
> that you can set a certain speed for the program to run?
There are a few ways to do it.
You can program the PIT (programmable interval timer) to generate an interrupt at some frequency (say 30 or 60Hz) and wait at the end of each frame for that. This is kind of a pain in the ass because it can screw with system timing on DOS-based systems so you've got to call the original DOS interrupt vector at 18.2Hz to maintain time.
Alternatively, you can wait for the Vsync signal before blitting. The problem with this is that it's mode-dependent, but AFAIK, it will be the same for all systems at a given mode. For Mode 0x13, it occurs at 70Hz. For 320x240 Mode X it happens at 60Hz.
You'd want your game loop to look like this:
1. Game logic
2. Render to buffer
3. Wait for vsync
5. Goto 1
Step 3 consists of polling the VGA. Here's some code for it:
mov edx, 0x3da ; input status
in al, dx
and al, 8
jnz short .l0
in al, dx
and al, 8
jz short .l1
IIRC, bit 7 being set means the VGA controller has entered the Vsync period (when the monitor's beam is being retraced to the top and the VRAM is not being accessed by the VGA.) You will want to check up on that to make sure.
This code consists of 2 loops: The first (.l0) will keep looping until we're OUT of the vsync period (in case this routine was called while in the middle of a vsync.) The second will wait until vsync is entered.
I think you only really need the second loop. The first loop will essentially skip an entire frame (it just makes sure to wait for the next vsync period so we're guaranteed to be at the beginning of vsync when the routine exits.)