DOS updates for new tree (Daniel Borca)

1 files changed, 226 insertions, 225 deletions

diff --git a/docs/README.DJ b/docs/README.DJ
index 0ddcea8baec..78512587661 100644
--- a/docs/README.DJ
+++ b/docs/README.DJ
@@ -1,225 +1,226 @@
-			Mesa 5.0.1 DOS/DJGPP Port v1.3

-			~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-

-

-Description:

-~~~~~~~~~~~~

-

-Well, guess what... this is the DOS port of Mesa 5.0.1, for DJGPP fans... Whoa!

-The driver has its origins in ddsample.c, written by Brian Paul and found by me

-in Mesa 3.4.2.

-

-

-

-Legal:

-~~~~~~

-

-Mesa copyright applies, provided this package is used within Mesa. For anything

-else, see GPL.

-

-

-

-Installation:

-~~~~~~~~~~~~~

-

-Unzip and type:

-

-	make -f Makefile.DJ [OPTIONS...]

-

-Available options:

-

-     Environment variables:

-	CPU		optimize for the given processor.

-			default = k6

-	GLU=[src|si]	specify GLU directory; can be `src' (src-glu = Mesa)

-			or `si' (si-glu = SGI's GLU -- requires GNU/C++).

-			default = src

-	GLIDE		path to Glide3 SDK include files; used with FX.

-			default = $(TOP)/include/glide3

-	FX=1		build for 3dfx Glide3. Note that this disables

-			compilation of most DMesa code and requires fxMesa.

-			As a consequence, you'll need the DJGPP Glide3

-			library to build any application.

-			default = no

-	MATROX=1	build for Matrox Millennium I (MGA2064W) cards.

-			This is experimental and not intensively tested.

-			default = no

-	HAVE_X86=1	optimize for i386.

-			default = no

-	HAVE_MMX=1	allow MMX specializations, provided your assembler

-			supports MMX instruction set. However, the true CPU

-			capabilities are checked at run-time to avoid crashes.

-			default = no

-	HAVE_SSE=1	(see HAVE_MMX)

-			default = no

-	HAVE_3DNOW=1	(see HAVE_MMX)

-			default = no

-

-     Targets:

-	all:		build everything

-	libgl:		build GL

-	libglu:		build GLU

-	libglut:	build GLUT

-	clean:		remove object files

-	realclean:	remove all generated files

-

-

-

-Tested on:

-	CPU:		K6-2 (CXT) @500(412.5) MHz

-	Mainboard:	ViA Apollo VP2/97 w/ 128 MB SDRAM

-	Video card:	PowerColor EvilKing3 (Voodoo3 3000 PCI) w/ 16 MB SDRAM

-	DJGPP:		djdev 2.04 + gcc v3.2.2 + make v3.79.1

-	OS:		DOS and Win9x

-

-

-

-FAQ:

-~~~~

-

-1. Compilation

-

-   Q) I tried to run `make' and it exits because `gcc' complains it cannot find

-      some stupid file.

-   A) You need LFN support.

-   A) When compiling for Glide (FX=1), pay attention to Glide path.

-

-   Q) Libraries built OK, but linker complains about `vsnprintf' every time I

-      compile some demo.

-   A) Upgrade to DJGPP 2.04.

-   A) Add `vsnprintf.c' to the CORE_SOURCES in `src/Makefile.DJ' (untested!).

-   A) The following hack should be safe in 90% of the cases, but if anything

-      goes wrong, don't come back to me crying. Anyway, patch `src/imports.c'

-      with the following line:

-	#define vsnprintf(buf, max, fmt, arg) vsprintf(buf, fmt, arg)

-

-   Q) `make' complains about DXE3 or something, yet it builds the libraries.

-   A) DXE3 refers to the DJGPP dynamic modules. You'll need either the latest

-      DJGPP distro, or download the separate package from my web page. Read the

-      DXE3 documentation on how to use them. Hint: build your export object

-      file; then link it with your application. For example:

-	dxe3res -o dxe3tbl.c gl.dxe glu.dxe glut.dxe

-	gcc -o dxe3tbl.o -c dxe3tbl.c

-	gcc -o OUT.exe dxe3tbl.o IN.c -liglut -liglu -ligl -ldl

-

-2. Using Mesa for DJGPP

-

-   Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much better...

-   A) Is that a question? If you have a Voodoo3/Banshee card, you're lucky (the

-      Glide port is on my web page). If you have a Matrox Millennium I card,

-      you just MIGHT be lucky... If you haven't, sorry; everything is done in

-      software. Suggestions?

-

-   Q) I tried to set refresh rate w/ DMesa, but without success.

-   A) Refresh rate control works only for VESA 3.0. If you were compiling for

-      Glide, see Glide info. If not, sorry!

-

-   Q) I made a simple application and it does nothing. It exits right away. Not

-      even a blank screen.

-   A) The pure software drivers (VESA/VGA) support only double-buffered modes.

-   A) Another weird "feature" is that buffer width must be multiple of 8 (I'm a

-      lazy programmer and I found that the easiest way to keep buffer handling

-      at peak performance ;-).

-

-   Q) My demo doesn't display text. I know I used the GLUT font routines!

-   A) Then you probably use GLUT as a DXE. Well, there is no direct access to

-      variables due to the way DXE works. Read the documentation. The author of

-      GLUT took this into account for _WIN32 DLL's only; I don't want to modify

-      his headers. The only workaround is to link GLUT the old way :-(

-

-   Q) The GLUT is incomplete.

-   A) See below.

-

-

-

-libGLUT (the toolkit):

-~~~~~~~~~~~~~~~~~~~~~~

-

-Well, this "skeletal" GLUT implementation was taken from AllegGL project and

-heavily changed. Thanks should go to Bernhard Tschirren, Mark Kilgard, Brian

-Paul and probably others (or probably not ;-). GLUT functionality will be

-extended only on an "as needed" basis.

-

-GLUT talks to hardware via PC_HW package which was put together from various

-pieces I wrote long time ago. It consists from the keyboard, mouse and timer

-drivers.

-

-My keyboard driver used only scancodes; as GLUT requires ASCII values for keys,

-I borrowed the translation tables (and maybe more) from Allegro -- many thanks

-to Shawn Hargreaves et co. 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 (hopefully) call the destructors, 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 drawing, etc), but is enough to

-make almost all the demos work. Supports the CuteMouse WheelAPI.

-

-The timer is pretty versatile for it supports multiple timers with different

-frequencies. While not being the most accurate timer in the known universe, 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. A bit of a hack, I

-know, because all messages come in bulk, but I think it's better than nothing.

-"Borrowed" from LIBRHUTI (Robert Hoehne).

-

-Window creating defaults: 300x300x16 at (0,0), 16-bit depth, 16-bit accum,

-8-bit stencil. However, the video mode is chosen in such a way that first

-window will fit. If you need high resolution with small windows, set initial

-position far to the right (or way down); then you can move them back to any

-position right before the main loop.

-

-The following environment variables can customize GLUT behaviour:

-	DMESA_GLUT_REFRESH	- set vertical screen refresh rate (VESA3)

-	DMESA_GLUT_BPP		- set default bits per pixel (VGA needs 8)

-	GLUT_FPS		- print frames/second statistics to stderr

-

-

-

-History:

-~~~~~~~~

-

-v1.0 (mar-2002)

-	initial release

-

-v1.1 (sep-2002)

-	+ added 3dfx Glide3 support

-	+ added refresh rate control

-	+ added fonts in GLUT

-	* lots of minor changes

-

-v1.2 (nov-2002)

-	* synced w/ Mesa-4.1

-	- removed dmesadxe.h

-

-v1.3 (mar-2003)

-	+ enabled OpenGL 1.4 support

-	+ added MMX clear/blit routines

-	+ enabled SGI's GLU compilation

-	+ added samples makefile

-	+ added new GLUT functions

-	+ added color-index modes

-	+ added Matrox Millennium MGA2064W driver

-	+ added 8bit FakeColor (thanks to Neil Funk)

-	+ added VGA support (to keep Ben Decker happy)

-	! fixed some compilation errors (reported by Chan Kar Heng)

-	* optimized driver for faster callback access... yeah, right :)

-	* overhauled virtual buffer and internal video drivers

-	* better fxMesa integration

-	* revamped GLUT

-	* switched to DXE3

-

-

-

-Contact:

-~~~~~~~~

-

-Name:   Borca Daniel

-E-mail: [email protected]

-WWW:    http://www.geocities.com/dborca/

+			Mesa 5.0.1 DOS/DJGPP Port v1.4
+			~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+Description:
+~~~~~~~~~~~~
+
+Well, guess what... this is the DOS port of Mesa 5.0.1, for DJGPP fans... Whoa!
+The driver has its origins in ddsample.c, written by Brian Paul and found by me
+in Mesa 3.4.2.
+
+
+
+Legal:
+~~~~~~
+
+Mesa copyright applies, provided this package is used within Mesa. For anything
+else, see GPL.
+
+
+
+Installation:
+~~~~~~~~~~~~~
+
+Unzip and type:
+
+	make -f Makefile.DJ [OPTIONS...]
+
+Available options:
+
+     Environment variables:
+	CPU		optimize for the given processor.
+			default = k6
+	GLU=[mesa|sgi]	specify GLU directory; can be `sgi' (requires GNU/C++)
+			or `mesa'.
+			default = mesa
+	GLIDE		path to Glide3 SDK include files; used with FX.
+			default = $(TOP)/include/glide3
+	FX=1		build for 3dfx Glide3. Note that this disables
+			compilation of most DMesa code and requires fxMesa.
+			As a consequence, you'll need the DJGPP Glide3
+			library to build any application.
+			default = no
+	MATROX=1	build for Matrox Millennium I (MGA2064W) cards.
+			This is experimental and not intensively tested.
+			default = no
+	HAVE_X86=1	optimize for i386.
+			default = no
+	HAVE_MMX=1	allow MMX specializations, provided your assembler
+			supports MMX instruction set. However, the true CPU
+			capabilities are checked at run-time to avoid crashes.
+			default = no
+	HAVE_SSE=1	(see HAVE_MMX)
+			default = no
+	HAVE_3DNOW=1	(see HAVE_MMX)
+			default = no
+
+     Targets:
+	all:		build everything
+	libgl:		build GL
+	libglu:		build GLU
+	libglut:	build GLUT
+	clean:		remove object files
+	realclean:	remove all generated files
+
+
+
+Tested on:
+	CPU:		AMD Duron @800 MHz
+	Mainboard:	EP-8KTA3 w/ 128 MB SDRAM
+	Video card:	Voodoo5 5500 AGP w/ 64 MB SDRAM
+	DJGPP:		djdev 2.04 + gcc v3.2.2 + make v3.79.1
+	OS:		DOS and Win98SE
+
+
+
+FAQ:
+~~~~
+
+1. Compilation
+
+   Q) I tried to run `make' and it exits because `gcc' complains it cannot find
+      some stupid file.
+   A) You need LFN support.
+   A) When compiling for Glide (FX=1), pay attention to Glide path.
+
+   Q) Libraries built OK, but linker complains about `vsnprintf' every time I
+      compile some demo.
+   A) Upgrade to DJGPP 2.04.
+   A) Add `vsnprintf.c' to the CORE_SOURCES in `src/Makefile.DJ' (untested!).
+   A) The following hack should be safe in 90% of the cases, but if anything
+      goes wrong, don't come back to me crying. Anyway, patch `src/imports.c'
+      with the following line:
+	#define vsnprintf(buf, max, fmt, arg) vsprintf(buf, fmt, arg)
+
+   Q) `make' complains about DXE3 or something, yet it builds the libraries.
+   A) DXE3 refers to the DJGPP dynamic modules. You'll need either the latest
+      DJGPP distro, or download the separate package from my web page. Read the
+      DXE3 documentation on how to use them.
+   A) When compiling for Glide (FX=1), make sure `glid3.dxe' can be found in
+      LD_LIBRARY_PATH (or top `lib' directory).
+
+2. Using Mesa for DJGPP
+
+   Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much better...
+   A) Is that a question? If you have a 3dfx Voodoo Banshee or higher card,
+      you're lucky (check http://sourceforge.net/projects/glide for the DJGPP
+      port). If you have a Matrox Millennium I card, you just MIGHT be lucky...
+      If you haven't, sorry; everything is done in software. Suggestions?
+
+   Q) I tried to set refresh rate w/ DMesa, but without success.
+   A) Refresh rate control works only for VESA 3.0. If you were compiling for
+      Glide, see Glide info. If not, sorry!
+
+   Q) I made a simple application and it does nothing. It exits right away. Not
+      even a blank screen.
+   A) The pure software drivers (VESA/VGA) support only double-buffered modes.
+   A) Another weird "feature" is that buffer width must be multiple of 8 (I'm a
+      lazy programmer and I found that the easiest way to keep buffer handling
+      at peak performance ;-).
+
+   Q) My demo doesn't display text. I know I used the GLUT font routines!
+   A) Then you probably use GLUT as a DXE. Well, there is no direct access to
+      variables due to the way DXE works. Read the documentation. The author of
+      GLUT took this into account for _WIN32 DLL's only; I don't want to modify
+      his headers. The only workaround is to link GLUT the old way :-(
+
+   Q) The GLUT is incomplete.
+   A) See below.
+
+
+
+libGLUT (the toolkit):
+~~~~~~~~~~~~~~~~~~~~~~
+
+Well, this "skeletal" GLUT implementation was taken from AllegGL project and
+heavily changed. Thanks should go to Bernhard Tschirren, Mark Kilgard, Brian
+Paul and probably others (or probably not ;-). GLUT functionality will be
+extended only on an "as needed" basis.
+
+GLUT talks to hardware via PC_HW package which was put together from various
+pieces I wrote long time ago. It consists from the keyboard, mouse and timer
+drivers.
+
+My keyboard driver used only scancodes; as GLUT requires ASCII values for keys,
+I borrowed the translation tables (and maybe more) from Allegro -- many thanks
+to Shawn Hargreaves et co. 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 (hopefully) call the destructors, 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 drawing, etc), but is enough to
+make almost all the demos work. Supports the CuteMouse WheelAPI.
+
+The timer is pretty versatile for it supports multiple timers with different
+frequencies. While not being the most accurate timer in the known universe, 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. A bit of a hack, I
+know, because all messages come in bulk, but I think it's better than nothing.
+"Borrowed" from LIBRHUTI (Robert Hoehne).
+
+Window creating defaults: 300x300x16 at (0,0), 16-bit depth, 16-bit accum,
+8-bit stencil. However, the video mode is chosen in such a way that first
+window will fit. If you need high resolution with small windows, set initial
+position far to the right (or way down); then you can move them back to any
+position right before the main loop.
+
+The following environment variables can customize GLUT behaviour:
+	DMESA_GLUT_REFRESH	- set vertical screen refresh rate (VESA3)
+	DMESA_GLUT_BPP		- set default bits per pixel (VGA needs 8)
+	GLUT_FPS		- print frames/second statistics to stderr
+
+
+
+History:
+~~~~~~~~
+
+v1.0 (mar-2002)
+	initial release
+
+v1.1 (sep-2002)
+	+ added 3dfx Glide3 support
+	+ added refresh rate control
+	+ added fonts in GLUT
+	* lots of minor changes
+
+v1.2 (nov-2002)
+	* synced w/ Mesa-4.1
+	- removed dmesadxe.h
+
+v1.3 (mar-2003)
+	+ enabled OpenGL 1.4 support
+	+ added MMX clear/blit routines
+	+ enabled SGI's GLU compilation
+	+ added samples makefile
+	+ added new GLUT functions
+	+ added color-index modes
+	+ added Matrox Millennium MGA2064W driver
+	+ added 8bit FakeColor (thanks to Neil Funk)
+	+ added VGA support (to keep Ben Decker happy)
+	! fixed some compilation errors (reported by Chan Kar Heng)
+	* optimized driver for faster callback access... yeah, right :)
+	* overhauled virtual buffer and internal video drivers
+	* better fxMesa integration
+	* revamped GLUT
+	* switched to DXE3
+
+v1.4 (jun-2003)
+	* accomodated makefiles with the new sourcetree
+
+
+
+Contact:
+~~~~~~~~
+
+Name:   Borca Daniel
+E-mail: [email protected]
+WWW:    http://www.geocities.com/dborca/