diff options
Diffstat (limited to 'docs/README.DJ')
| -rw-r--r-- | docs/README.DJ | 172 |
1 files changed, 125 insertions, 47 deletions
diff --git a/docs/README.DJ b/docs/README.DJ index e92d36cf4c0..444fe8947c5 100644 --- a/docs/README.DJ +++ b/docs/README.DJ @@ -1,4 +1,4 @@ - Mesa 4.0 DOS/DJGPP Port v1.0
+ Mesa 4.0 DOS/DJGPP Port v1.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -6,75 +6,149 @@ Description:
~~~~~~~~~~~~
-Well, guess what... this is the DOS port of MESA 4.0, for DJGPP fans... Whoa!
+Well, guess what... this is the DOS port of Mesa 4.0.3, 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.
+Mesa copyright applies, provided this package is used within Mesa. For anything
+else, see GPL.
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
+Unzip and type:
+
+ make -f Makefile.DJ [OPTIONS...]
+
+Available options:
+
+ Environment variables:
+ CPU optimize for the given processor.
+ default = k6
+ BIG_OPT=1 crazy optimizations; not very useful, though...
+ default = no
+ GLIDE absolute path to Glide library; used with FX.
+ default = $(TOP)/include/glide3
+ FX=1 build for 3dfx Glide3; use it if you have the Glide
+ SDK (designed for your platform), and, of course, a
+ 3dfx card... Note that this disables compilation of
+ actual DMesa code, as Glide does all the stuff!
+ default = no
+ HAVE_X86=1 optimize for i386.
+ default = no
+ HAVE_MMX=1 MMX instructions; use only if you assembler/compiler
+ supports MMX instruction set; backwards compatibility
+ with older processors is still preserved.
+ 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: 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
+ CPU: K6-2 (CXT) @500(412.5) MHz
+ Mainboard: ViA Apollo VP2/97 w/ 128 MB SDRAM
+ Video card: PowerColor Evil King3 (Voodoo3 3000) w/ 16384 kB SDRAM
+ DJGPP: djdev 2.03 + gcc v3.1 + make v3.79.1
-libGL (the core):
-~~~~~~~~~~~~~~~~~
+FAQ:
+~~~~
-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.
+1. Compilation
-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!
+ Q) I tried to run `make' and it exits because `gcc' complains it cannot find
+ some stupid file.
+ A) You need LFN support.
+ A) If FX is defined, pay attention to Glide path.
-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 ;-).
+2. Dynamic modules
+ Q) What are you mumbling about dynamic modules?
+ A) You must have the DXE2 package (available on SimTel.Net, courtesy of
+ Andrew Zabolotny) installed in order to build the dynamic modules.
+ Q) I have DXE2, but I couln'd build the `dxe2gen.exe'.
+ Q) I built `dxe2gen.exe', but it doesn't do the job right.
+ A) There is a patched version on my web page.
-libGLU:
-~~~~~~~
+ Q) DXE2 modules give me headaches...
+ A) The DXE2 modules are not compulsory. The static libraries are still built
+ and you can use them in the old-fashioned, classic way.
-Mesa GLU sources are required.
+ Q) Okay, DXE2 modules are built. How can I use them?
+ A) 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 (libI*.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
+ For example:
+ gcc -o OUT.exe -include dmesadxe.h IN.c -ligl -liglu -liglut -ldl
+
+ Q) The application dies with "Abort!" due to unresolved symbols.
+ A) This is bad! Extract the unresolved symbol list from this module. For
+ example:
+ dxe2gen --show-unres gl.dxe > u
+ Check DMESADXE.H; the symbols in `u' must either be present here or be
+ exported from another module that has to be loaded before your faulting
+ one. Then recompile.
+
+3. Using Mesa for DJGPP
+
+ Q) Does this build work in Win9x?
+ A) Yes.
+
+ Q) Does it work under NT (W2k, XP) core?
+ A) Uh... probably not!
+
+ Q) I made a simple application and it does nothing. It exits right away. Not
+ even a blank screen.
+ A) The current version supports only RGB[A] modes, for it made no sense to
+ me to endorse color-index (aka palette) modes.
+ A) Single-buffered is not allowed at all. Until I can find a way to use
+ *REAL* hardware acceleration, it won't get implemented.
+ A) 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 ;-).
+
+ 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 DJGPP port of Mesa 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 haven't, sorry; everything is done
+ in software. Suggestions?
+
+ Q) I have a super/mega/ultra monitor and all you can do is 60Hz? My eyes are
+ leaking from the orbits...
+ A) If you were compiling for Glide, see Glide info. If not, be aware that
+ refresh rate control works only for VESA 3.0. The environment variable
+ DMESA_REFRESH sets the default screen refresh. For example:
+ set DMESA_REFRESH=75
@@ -85,7 +159,7 @@ 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.
+fixed with many 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.
@@ -121,6 +195,10 @@ 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
|