diff options
Diffstat (limited to 'docs/README.DJ')
| -rw-r--r-- | docs/README.DJ | 451 |
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: dborca@yahoo.com
-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: dborca@yahoo.com +WWW: http://www.geocities.com/dborca/ |