133 lines
4.7 KiB
Plaintext
133 lines
4.7 KiB
Plaintext
Mesa 4.0 DOS/DJGPP Port v1.0
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
Description:
|
|
~~~~~~~~~~~~
|
|
|
|
Well, guess what... this is the DOS port of MESA 4.0, for DJGPP fans... Whoa!
|
|
|
|
|
|
|
|
Legal:
|
|
~~~~~~
|
|
|
|
MESA copyright applies.
|
|
|
|
|
|
|
|
Installation:
|
|
~~~~~~~~~~~~~
|
|
|
|
Type "make -f Makefile.DJ" to compile the libraries. Make accepts some options
|
|
which are passed to compiler: the target cpu (CPU=..., default=`pentium') and
|
|
X86 specific options (HAVE_X86=1, HAVE_MMX=1, HAVE_SSE=1, HAVE_3DNOW=1). The
|
|
core library (libGL) requires LFN support during compilation. Also, you must
|
|
have the DXE2 package (available on SimTel.Net, courtesy of Andrew Zabolotny)
|
|
installed in order to build the dynamic modules; if you encounter errors, you
|
|
can fetch a patched version from my web page.
|
|
The demos are not built automagically (see Pitfalls below). To make them, use
|
|
one of the following rules:
|
|
Static:
|
|
gcc -o OUT.exe IN.c -lglut -lglu -lgl
|
|
Dynamic:
|
|
gcc -o OUT.exe -include dmesadxe.h IN.c -ligl -liglu -liglut -ldl
|
|
Usage of the dynamic modules requires three things:
|
|
- include DMESADXE.H in one of the sources, so references inside
|
|
dynamic modules will get resolved (or use `-include' directive)
|
|
- link against import libraries (libIgl*.a) and LIBDL.A, which will do
|
|
the dynamic linkage job for you
|
|
- put the DXEs somewhere along the library path (LD_LIBRARY_PATH) or
|
|
in the current directory
|
|
|
|
Tested on:
|
|
CPU: Intel Pentium w/ MMX @166 MHz
|
|
Mainboard: ViA Apollo VP2 w/ 128 MB SDRAM
|
|
Video card: Matrox Millenium 2064W w/ 2048 kB WRAM, BIOS v3.0
|
|
DJGPP: djdev 2.03 + gcc v3.0.3 + make v3.79
|
|
|
|
|
|
|
|
libGL (the core):
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
Of course, MESA 4.0 core sources are required. It will probably work with
|
|
MESA 3.5, but not a chance with earlier versions due to major changes to the
|
|
MESA driver interface and the directory tree. All should compile succesfully.
|
|
|
|
The driver has its origins in ddsample.c, written by Brian Paul and found by
|
|
me in MESA 3.4.2. I touched almost all the functions, changing the coding
|
|
style :-( Sorry!
|
|
|
|
Pitfalls:
|
|
1. The current version supports only RGB[A] modes, for it made no sense to me
|
|
to endorse color-index (aka palette) modes.
|
|
2. Single-buffered is not allowed at all. Until I can find a way to use *REAL*
|
|
hardware acceleration, it won't get implemented.
|
|
3. Another weird "feature" is that buffer width must be multiple of 4 (I'm a
|
|
lazy programmer and I found that the easiest way to keep buffer handling at
|
|
peak performance ;-).
|
|
|
|
|
|
|
|
libGLU:
|
|
~~~~~~~
|
|
|
|
Mesa GLU sources are required.
|
|
|
|
|
|
|
|
libGLUT (the toolkit):
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Well, this "skeletal" GLUT implementation is not mine. Thanks should go to
|
|
Bernhard Tschirren, Mark Kilgard, Brian Paul and probably others (or probably
|
|
not ;-). I only changed it to be self-standing (Allegro-free). The keyboard,
|
|
mouse and timer drivers were inspired from an old project of mine (D3Xl) and
|
|
fixed with some Allegro "infusions"; I deeply thank to Shawn Hargreaves et co.
|
|
|
|
My keyboard driver used only scancodes, but since GLUT requires ASCII values
|
|
for keys, I borrowed the translation tables (and maybe more) from Allegro.
|
|
Ctrl-Alt-Del (plus Ctrl-Alt-End, for Windows users) will shut down the GLUT
|
|
engine unconditionally: it will raise SIGINT, which in turn will call the
|
|
destructors (let's hope), thus cleaning up your/my mess ;-) NB: since the
|
|
DJGPP guys ensured signal handlers won't go beyond program's space (and since
|
|
dynamic modules shall) the SIGINT can't be hooked (well, it can, but it is
|
|
useless), therefore you must live with the 'Exiting due to signal SIGINT'
|
|
message...
|
|
|
|
The mouse driver is far from complete (lack of positioning, drawing, etc),
|
|
but is enough to make almost all the demos work.
|
|
|
|
The timer is pretty versatile for it supports multiple timers with different
|
|
frequencies. It may not be the most accurate timer in the known universe, but
|
|
I think it's OK. Take this example: you have timer A with a very high rate,
|
|
and then you have timer B with very low rate compared to A; now, A ticks OK,
|
|
but timer B will probably loose precision!
|
|
|
|
As an addition, stdout and stderr are redirected and dumped upon exit. This
|
|
means that printf can be safely called during graphics, but all messages come
|
|
in bulk! A bit of a hack, I know, but I think it's better than to miss them
|
|
at all. "Borrowed" from RHIDE (Robert Hoehne) or SETEDIT (Salvador Eduardo
|
|
Tropea)... I'm not sure.
|
|
|
|
Window creating defaults: 640x480x16 at (0,0), 8-bit stencil, 16-bit accum.
|
|
However, the video mode is chosen in such a way that first window will fit.
|
|
|
|
|
|
|
|
History:
|
|
~~~~~~~~
|
|
|
|
v1.0 mar-2002 initial release
|
|
|
|
|
|
|
|
Contact:
|
|
~~~~~~~~
|
|
|
|
Name: Borca Daniel
|
|
E-mail: dborca@yahoo.com
|
|
WWW: http://www.geocities.com/dborca/
|