Documentation for video.inc vesa routines for
	Dieter Pawelczak's Pro32 DOS Extender
		code and doc by Chris Hazard

Vesa routines are not the easiest to create, but I have tried to
make them easy to work with.  I designed them for a game I am currently
working on: a 3d polygonal flying/shoot 'em up game which will probably
take about 2 years(I may eventually put my 3d graphic engine out for
others, but it isn't done yet, and I've put many of my own ideas into it
that are rather unique such as fast & pretty accurate displaying,
advanced anti-aliasing, etc., and I'd like to keep it to myself
for awhile.  It is well optimized for pentium processors
(not pentiumII or MMX yet), including paired instructions, and btb
branching, etc. (that optimizing took me awhile!).  Right now, I have a
CAD-like 3d graphic editing program (all 32 bit assembly), and I am currently
working on using fractals to draw 3d landscapes, riverways, and clouds.

Anyway, on to the doc...


(I'm assuming that your program likes speed in graphics!)
When you draw lots of graphics to the screen, and animate them by
clearing the screen, the last ones drawn can tend to flicker if you've got
a lot of processing.  To stop this, I've designed this around a screen buffer
(suprisingly named ScreenBuffer!!!).  
NOTE: it is designed for mode 101h. To make it for a different mode,
adjust the numbers in the declaration, and also adjust the 
FlushSBufferproc that I'll get to in a minute.

The way this is implemented is: instead of drawing directly to the screen,
output all of your graphics to 
ScreenBuffer:[whatever_x + screenlength * whatever_y]
where ScreenBuffer is a selector
then call FlushSBuffer (requires no params), which I believe reatains no
registers after calling (except all segment regs).
(if you want, you could write directly to the screen, but you'd have to
write that part - I don't see why you'd want to though...)



Now that you know how to use it, I'll show you how to set it up...
first, move whatever mode you want into ModeToSet, and move the offset of
your palette into edi (I'll get to palettes in a minute).  The routines will 
handle any errors that come up,and display them in blue writing in the
upper left of your screen.  If your video card isn't vesa compatable, tough
luck!

Now about the palette...
The palette is an array of colors displayed on the monitor, usually a
reference (unless you're using 24bit colors -"millions of colors").
(There are 256 asigned colors in mode 101h)
Each 3 numbers of the palette represent one color
e.g.
	Red	Green	Blue
	0	0	0	black
	63	63	63	white
	0	0	63	bright blue
	0	25	25	teal
	...
And that's the way they're layed out in the array (in bytes)
color1red, color1green, color1blue, color2red, color2green, ...
You simply set edi to point to an array of these, and call SetPal
(this is done in Initialize proc).  You can change the palette even in
the middle of real time animation!!!  I have included a "Fuzz Buster"
(in case you were wondering what those 9 lines of code was doing at the
beginning of SetPal) set of instructions that actually wait for the 
monitor's electron gun to reach the top again.  If you omit these
instructions, you will probably get fuzz everytime you change your palette
unless you have some hyper fast monitor.
(By the way, changing palettes is great for fade in/outs.  Simply change
the palette each time so that every color (set of rgb) aproaches black,
white, etc.)
The included palette is just some palette I had on my hard drive that
I don't know where I got it from.  (the ones I'm using in my game are
set up very different)

Before ending your program, be sure to call ReturnMode, or you will run
into nothing but trouble when you try doing stuff from dos (until you
use something that rechanges the video mode back, or close the dos window
when running in windows).

One additional note: I have not done much testing on video modes besides
101h.  If it doesn't work with other modes, play around with it.
Trivia: mode 101h has a little better resolution as a standard TV set!
	(I'm not positive, but prety sure).


Normally, I heavily comment my work, but in this case it's hard to do
because of all of the technical stuff.  I hope that you have learned
something here (at least you have vesa routines).  I've tried to make the
code readable, but there are a couple of areas that are confusing,
especially in the GetVesaModeInfo proc.  There are a couple of instances
that you should refer back to Dieter Pawelczak's Pro32 DOS Extender
manual and a vesa manual if you have one handy (many are availiable via
the internet).

Good Luck Coding!

If you have any questions, comments, suggestions, problems...
e-mail me

-Chris Hazard (yes, my last name truly is Hazard!)
	chazard@hartford.k12.wi.us (see other files for e-mail info)

This code may be freely distributed, but it must remain unaltered for
distribution.  Anyone reading this has permission to use all or any
portion of this code in any freeware, shareware, or commercial application.
The author is not liable for any damage or effects of this code, and it comes
with no gaurantees.  I do not require you to include any reference to
me in any application in which you use any or all of this code (including
commercial applications), but the inclusion of my name and what I did
(this code has no true name) in the credits/about would be greatly
appreciated.


p.s. The main reason I don't have my own web page yet is I don't have
	time, but I'll write one eventually.