aboutsummaryrefslogtreecommitdiff
path: root/nx-X11/extras/Mesa_6.4.2/docs/README.3DFX
diff options
context:
space:
mode:
authorftrapero <frantracer@gmail.com>2017-06-27 12:08:38 +0200
committerftrapero <frantracer@gmail.com>2017-06-27 12:08:38 +0200
commitb30506dface604c78e445905ce263f166945d67b (patch)
tree1c23f91f36eb445850b654daa9c5e30bb47072e5 /nx-X11/extras/Mesa_6.4.2/docs/README.3DFX
parentc032f0e341c981036e9b3245a0e0710ad61599d0 (diff)
parent663631725ee2d633d9ec5821cd48953ffd188d00 (diff)
downloadnx-libs-b30506dface604c78e445905ce263f166945d67b.tar.gz
nx-libs-b30506dface604c78e445905ce263f166945d67b.tar.bz2
nx-libs-b30506dface604c78e445905ce263f166945d67b.zip
Include mesa-6.4.2 project
Diffstat (limited to 'nx-X11/extras/Mesa_6.4.2/docs/README.3DFX')
-rw-r--r--nx-X11/extras/Mesa_6.4.2/docs/README.3DFX830
1 files changed, 830 insertions, 0 deletions
diff --git a/nx-X11/extras/Mesa_6.4.2/docs/README.3DFX b/nx-X11/extras/Mesa_6.4.2/docs/README.3DFX
new file mode 100644
index 000000000..037e8fa7c
--- /dev/null
+++ b/nx-X11/extras/Mesa_6.4.2/docs/README.3DFX
@@ -0,0 +1,830 @@
+
+ 3Dfx Glide device driver
+
+
+
+Requirements:
+-------------
+
+A Voodoo-based videocard/accelerator
+DOS (with DJGPP), Windows9x/2k (with MinGW), Linux
+Glide3x library for your OS
+
+http://sourceforge.net/projects/glide/
+
+
+
+How to compile:
+---------------
+
+DJGPP:
+ Place the Glide3 SDK in the top Mesa directory:
+ $(MESA)/glide3/include/
+ 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
+ $(MESA)/glide3/lib/
+ libgld3x.a, libgld3i.a, glide3x.dxe
+ Type:
+ make -f Makefile.DJ X86=1 FX=1
+ Look into the makefile for further information.
+
+MinGW:
+ Place the Glide3 SDK in the top Mesa directory:
+ $(MESA)/glide3/include/
+ 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
+ $(MESA)/glide3/lib/
+ libglide3x.a, glide3x.dll
+ Type:
+ make -f Makefile.mgw X86=1 FX=1
+ Look into the makefile for further information.
+
+Linux:
+ Place the Glide3 SDK in /usr/local/glide
+ /usr/local/glide/include/
+ 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
+ /usr/local/glide/lib/
+ libglide3x.a, libglide3x.so
+ Type:
+ make linux-glide
+ or
+ make linux-x86-glide
+
+
+
+Compilation defines:
+--------------------
+
+FX_DEBUG
+ enable driver debug code
+FX_TRAP_GLIDE
+ enable Glide trace code
+FX_PACKEDCOLOR
+ use packed color in vertex structure
+FX_TC_NAPALM
+ map GL_COMPRESSED_RGB[A] to FXT1. Works with VSA100-based cards only.
+FX_COMPRESS_S3TC_AS_FXT1_HACK
+ map S3TC to FXT1
+FX_RESCALE_BIG_TEXURES_HACK
+ fake textures larger than HW can support
+ (see MESA_FX_MAXLOD environment variable)
+
+
+
+Environment variables:
+----------------------
+
+The following environment variables affect MesaFX. Those that affect Glide
+only, are beyond the scope of this section. Entries that don't have a "Value"
+field, can have any value whatsoever
+ ex: set MESA_FX_IGNORE_CMBEXT=y
+
+"Note" (*) means that the environment variable affects Glide, too; also, if
+the var is not found in the environment, it is searched in windoze registry.
+"Note" (!) means that the environment variable is not working as expected;
+may have undefined effects, might have effects only at Glide level or might
+not have any effect whatsoever. Caveat emptor! Those are to be revised soon.
+
+It is recommended to leave the envvars alone, so that Mesa/Glide will run with
+default values. Use them only when you experience crashes or strange behavior.
+
+FX_GLIDE_NUM_TMU
+ OS: all
+ HW: dual-TMU cards (Voodoo2, Avenger, Napalm)
+ Desc: force single-TMU
+ Note: (*)
+ Value: "1"
+FX_GLIDE_SWAPPENDINGCOUNT
+ OS: all
+ HW: all
+ Desc: max # of buffers allowed to build up
+ Note: (*) (!)
+ Value: "0", "1", "2", "3", "4", "5" or "6"
+FX_GLIDE_SWAPINTERVAL
+ OS: all
+ HW: all
+ Desc: number of vertical retraces to wait before swapping
+ Note: (*) (!) works only at Glide-level?
+SSTH3_SLI_AA_CONFIGURATION
+ OS: all
+ HW: VSA100-based cards
+ Desc: SLI/AA setup
+ Note: (*) (!) works only at Glide-level?
+ Value:
+ 1, 2, 4 chip cards
+ "0" - SLI & AA disable
+ "1" - SLI disabled, 2 sample AA enabled
+ 2, 4 chip cards
+ "2" - 2-way SLI enabled, AA disabled
+ "3" - 2-way SLI enabled, 2 sample AA enabled
+ "4" - SLI disabled, 4 sample AA enabled
+ 4 chip cards
+ "5" - 4-way SLI enabled, AA disabled
+ "6" - 4-way SLI enabled, 2 sample AA enabled
+ "7" - 2-way SLI enabled, 4 sample AA enabled
+ "8" - SLI disabled, 8 sample AA enabled
+SST_DUALHEAD
+ OS: win32
+ HW: ?
+ Desc: ?
+ Note: (!) disabled?
+MESA_FX_NO_SIGNALS
+ OS: linux
+ HW: all
+ Desc: avoid installing signals
+ Note: (!) untested!
+MESA_FX_INFO
+ OS: all
+ HW: all
+ Desc: verbose to stderr
+ Value: any; special value "r" to redirect stderr to MESA.LOG
+MESA_FX_NOSNAP
+ OS: all
+ HW: Voodoo1, Rush, Banshee
+ Desc: do not snap vertices inside Mesa
+ Note: to be used with Glide3x that snaps vertices internally
+MESA_FX_POINTCAST
+ OS: all
+ HW: dual-TMU cards (some Voodoo1, Voodoo2, Avenger, Napalm)
+ Desc: try to use pointcast palette
+ Note: may give adverse effects on UMA cards (Avenger, Napalm)
+MESA_FX_IGNORE_PALEXT
+ OS: all
+ HW: all
+ Desc: disable 6666 palette
+MESA_FX_IGNORE_PIXEXT
+ OS: all
+ HW: Napalm
+ Desc: force 565 16bpp mode (traditional Voodoo, no 32/15bpp)
+MESA_FX_IGNORE_TEXFMT
+ OS: all
+ HW: Napalm
+ Desc: disable 32bit textures
+MESA_FX_IGNORE_CMBEXT
+ OS: all
+ HW: Napalm
+ Desc: disable Napalm combiners (color/alpha/texture)
+ Note: this option allows dual-TMU cards perform single-pass
+ trilinear, but some advanced (multi)texturing modes
+ won't work (GL_EXT_texture_env_combine)
+MESA_FX_IGNORE_MIREXT
+ OS: all
+ HW: all
+ Desc: disable mirror extension
+MESA_FX_IGNORE_TEXUMA
+ OS: all
+ HW: all
+ Desc: disable UMA
+MESA_FX_IGNORE_TEXUS2
+ OS: all
+ HW: all
+ Desc: disable Texus2
+MESA_FX_MAXLOD
+ OS: all
+ HW: non VSA-100 cards
+ Desc: enable large texture support using SW rescaling
+ Value:
+ "9" - 512x512 textures
+ "10" - 1024x1024 textures
+ "11" - 2048x2048 textures
+MESA_FX_ALLOW_VP
+ OS: all
+ HW: all
+ Desc: allow vertex program extensions
+MESA_GLX_FX
+ OS: linux
+ HW: Voodoo1, Rush, Voodoo2
+ Desc: display mode
+ Note: (!) experimental
+ Value:
+ "w" - windowed mode
+ "f" - fullscreen mode
+ "d" - disable glide driver
+ OS: win32
+ HW: Rush, Banshee, Avenger, Napalm
+ Desc: display mode
+ Note: (!) experimental
+ Value:
+ "w" - windowed mode
+
+
+
+Contact:
+--------
+
+Daniel Borca <dborca 'at' users 'dot' sourceforge 'dot' net>
+Hiroshi Morii <koolsmoky 'at' users 'dot' sourceforge 'dot' net>
+
+
+
+WARNING! The info below this line is outdated (yet some of it useful). WARNING!
+*******************************************************************************
+
+
+
+Info for Mesa 4.1
+-----------------
+
+The 3dfx Glide driver in Mesa is disabled by default. Not too many people
+use this driver anymore and at some point down the road it will be dropped.
+
+To use/enable the Glide driver either do this:
+
+'./configure --with-glide=DIR' Where DIR is the location of Glide, like
+ /usr/ or /usr/local
+
+OR
+
+'make linux-x86-glide' If using the old-style Makefile system.
+
+The rest of this file hasn't changed since Mesa 3.3. Some of it's out of
+date, but some is still valid.
+
+
+
+What do you need ?
+------------------
+
+ - A PC with a 3Dfx Voodoo1/2 Graphics or Voodoo Rush based board
+ (Pure3D, Monster 3D, R3D, Obsidian, Stingray 128/3D, etc.).
+ The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
+ under Linux (more information in the "Useful Glide Environment
+ Variables");
+
+ - The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine).
+ The Voodoo2 requires the Glide library 2.51. The Glide 3.1 is not
+ compatible with the Glide 2.x so it doesn't work with the current
+ version of the driver;
+
+ - A compiler supported by the Glide library (Micro$oft VC++ (tested),
+ Watcom (tested), GCC for Linux (tested), etc.);
+
+ - It's nice to have two monitors - one for your normal graphics
+ card and one for your 3Dfx card. If something goes wrong with
+ an application using the 3Dfx hardware you can still see your
+ normal screen in order to recover.
+
+
+
+Tested on:
+----------
+ Windows 95 - David Bucciarelli
+ Windows NT - Henri Fousse
+ MS-DOS
+ Linux - Daryll Strauss, Brian Paul, David Bucciarelli
+ FreeBSD
+ BeOS - Duncan Wilcox
+ MacOS - Fazekas Miklos
+
+
+What is able to do ?
+--------------------
+
+ - It is able accelerate points, lines and polygon with flat
+ shading, gouraud shading, Z-buffer, texture mapping, blending, fog and
+ antialiasing (when possible). There is also the support for rendering
+ in a window with a slow trick for the Voodoo Graphics (available only
+ for Linux) and at full speed with the Voodoo Rush chipset.
+ Under Linux is also possible to switch on-the-fly between the fullscreen
+ and in-window rendering hack.
+ There is also the support for using more than one Voodoo Graphics in the
+ some application/PC (you can create one context for each board and use
+ multiple video outputs for driving monitors, videoprojectors or HMDs).
+ The driver is able to fallback to pure software rendering when afeature
+ isn't supported by the Voodoo hardware (however software rendering is
+ very slow compared to hardware supported rendering)
+
+
+
+How to compile:
+---------------
+
+Linux:
+------
+ Here are the basic steps for using the 3Dfx hardware with Mesa
+ on Linux:
+
+ - You'll need the Glide library and headers. Mesa expects:
+ /usr/local/glide/include/*.h // all the Glide headers
+ /usr/local/glide/lib/libglide2x.so
+
+ If your Glide libraries and headers are in a different directory
+ you'll have to modify the Mesa-config and mklib.glide files.
+
+ - Unpack the MesaLib-3.1.tar.gz and MesaDemos-3.1.tar.gz archives;
+
+ - If you're going to use a newer Mesa/Glide driver than v0.27 then
+ unpack the new driver archive over the Mesa directory.
+
+ - In the Mesa-3.1 directory type "make linux-glide"
+
+ - Compilation _should_ finish without errors;
+
+ - Set your LD_LIBRARY_PATH environment variable so that the
+ libglide2x.so and Mesa library files can be found. For example:
+ setenv LD_LIBRARY_PATH "/usr/local/glide/lib:/SOMEDIR/Mesa-3.1/lib"
+
+ - You'll have to run Glide-based programs as root or set the suid
+ bit on executables;
+
+ - Try a demo:
+ cd gdemos
+ su
+ setenv MESA_GLX_FX f
+ ./gears (hit ESC to exit)
+
+ - You can find the demos especially designed for the Voodoo driver in
+ in the Mesa-3.1/3Dfx/demos directory (type "make" in order to compile
+ everything).
+
+MacOS:
+------
+ Check the WEB page at http://valerie.inf.elte.hu/~boga/Mesa.html
+
+MS Windows:
+-----------
+
+ For the MSVC++:
+ - The glide2x.lib have to be in the default MSVC++ lib directory;
+
+ - The Glide headers have to be in the default MSVC++ include directory;
+
+ - You must have the vcvars32.bat script in your PATH;
+
+ - Go to the directory Mesa-3.1 and run the mesafx.bat;
+
+ - The script will compile everything (Mesa-3.1/lib/OpenGL32.{lib,dll},
+ Mesa-3.1/lib/GLU32.{lib,dll}, Mesa-3.1/lib/GLUT32.{lib,dll} and
+ Voodoo demos);
+
+ - At the end, you will be in the Mesa-3.1/3Dfx/demos directory;
+
+ - Try some demo (fire.exe, teapot.exe, etc.) in order to check if
+ everything is OK (you can use Alt-Tab or Ctrl-F9 to switch between
+ the Voodoo screen and the windows desktop);
+
+ - Remember to copy the Mesa OpenGL32.dll, GLU32.dll and GLUT32.dll in the
+ some directory were you run your Mesa based applications.
+
+ - I think that you can easy change the Makefile.fx files in order
+ to work with other kind of compilers;
+
+ - To discover how open the 3Dfx screen, read the sources under
+ the Mesa-3.1/3Dfx/demos directory. You can use the GLUT library or
+ the Diego Picciani's wgl emulator.
+
+ NOTE: the MSVC++ 5.0 optimizer is really buggy. Also if you install the
+ SP3, you could have some problem (you can disable optimization in order
+ solve these kind of problems).
+
+
+Doing more with Mesa & Linux Glide:
+-----------------------------------
+
+ The MESA_GLX_FX environment variable can be used to coax most
+ GLX-based programs into using Glide (and the __GLUT library
+ is GLX-based__).
+
+ Full-screen 3Dfx rendering:
+ ---------------------------
+
+ 1. Set the MESA_GLX_FX variable to "fullscreen":
+
+ ksh:
+ export MESA_GLX_FX = "fullscreen"
+ csh:
+ setenv MESA_GLX_FX fullscreen
+
+ 2. As root, run a GLX-based program (any GLUT demo on Linux).
+
+ 3. Be careful: once the 3Dfx screen appears you won't be able
+ to see the GLUT windows on your X display. This can make using
+ the mouse tricky! One solution is to hook up your 3Dfx card to
+ a second monitor. If you can do this then set these env vars
+ first:
+
+ setenv SST_VGA_PASS 1
+ setenv SST_NOSHUTDOWN
+
+ or for the Voodoo2:
+
+ setenv SSTV2_VGA_PASS 1
+ setenv SSTV2_NOSHUTDOWN
+
+ Rendering into an X window with the help of the Voodoo hardware:
+ ----------------------------------------------------------------
+
+ 1. Start your X server in 16 bpp mode (XFree86: startx -- -bpp 16)
+ in order to have the best performance and the best visual
+ quality. However you can use any visual depth supported by X.
+
+ 2. Set the following environment variables:
+ export MESA_GLX_FX="window" # to enable window rendering
+ export SST_VGA_PASS=1 # to stop video signal switching
+ export SST_NOSHUTDOWN=1 # to stop video signal switching
+ OR
+ setenv MESA_GLX_FX window
+ setenv SST_VGA_PASS 1
+ setenv SST_NOSHUTDOWN 1
+
+ (the Voodoo2 requires to use "SSTV2_" instead "SST_").
+
+ 3. As root, try running a GLX-based program
+
+ How does it work? We use the 3Dfx hardware to do rendering then
+ copy the image from the 3Dfx frame buffer into an X window when
+ the SwapBuffers() function is called. The problem with this
+ idea is it's slow. The image must be copied from the 3Dfx frame
+ buffer to main memory then copied into the X window (and when the X
+ visual depth doesn't match the Voodoo framebufffer bit per pixel, it
+ is required also a pixel format translation).
+
+ NOTE: the in-window rendering feature only works with double-buffering.
+
+
+ On the fly switching between in window rendering and full screen rendering
+ --------------------------------------------------------------------------
+
+ The Mesa 2.6 has introduced the capability of switching
+ on-the-fly between the fullscreen/fullspeed rendering and the in-window
+ hack and vice versa. The on-the-fly switching requires a direct support
+ by the application but it is really easy to add. You have to start
+ your X server in 16 bpp mode and to add the following lines to your
+ application:
+
+ #if defined(FX) && define(XMESA)
+ #include <GL/xmesa.h>
+
+ static int fullscreen=1;
+ #endif
+
+ ...
+
+ /* In the GLUT keyboard event callback */
+
+ #if defined(FX) && !define(WIN32)
+ case ' ':
+ fullscreen=(!fullscreen);
+ XMesaSetFXmode(fullscreen ? XMESA_FX_FULLSCREEN : XMESA_FX_WINDOW);
+ break;
+ #endif
+ ...
+
+ See the 3Dfx/demos/tunnel.c program
+ for an example. You have to set the -DXMESA flag in the Makefile's COPTS
+ to enable it.
+
+ Rendering into an X window with the X11 software driver:
+ --------------------------------------------------------
+
+ Set the MESA_GLX_FX variable to "disable" your GLX-based program will use
+ the X11 software driver (the 3Dfx hardware isn't used at all).
+
+
+
+Useful Glide Environment Variables:
+-----------------------------------
+
+ - To disable the 3Dfx logo, set the FX_GLIDE_NO_SPLASH variable.
+
+ - To disable video signal switching:
+ setenv SST_VGA_PASS 1
+ setenv SST_NOSHUTDOWN
+ or for the Voodoo2:
+ setenv SSTV2_VGA_PASS 1
+ setenv SSTV2_NOSHUTDOWN
+
+ - To set the default screen refresh rate:
+ setenv SST_SCREENREFRESH=75
+
+ the supported values are 60, 70, 72, 75, 80, 85, 90, 100, 120.
+
+ - To force the Mesa library to swap buffers as fast as possible,
+ without any vertical blanking synchronization (useful for benchmarks):
+ setenv FX_GLIDE_SWAPINTERVAL 0
+ setenv SST_SWAP_EN_WAIT_ON_VIDSYNC 0
+
+ - You can slight improve the performances of your Voodoo1 board with
+ the following env. var.:
+ setenv SST_FASTMEM 1
+ setenv SST_PCIRD 1
+ setenv SST_GRXCLK 57
+
+ (don't use this setting with the Quantum3D 100SB or with any other
+ SLI configuration: it will hang everything !).
+ The following setting can be used with the Voodoo2:
+ setenv SSTV2_FASTMEM_RAS_READS=1
+ setenv SSTV2_FASTPCIRD=1
+ setenv SSTV2_GRXCLK=95
+
+ - The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
+ in order to work under Linux:
+
+ export SSTV2_FT_CLKDEL=5
+ export SSTV2_TF0_CLKDEL=7
+ export SSTV2_TF1_CLKDEL=7
+ export SSTV2_TF2_CLKDEL=7
+ export SSTV2_SLIM_VIN_CLKDEL=3
+ export SSTV2_SLIM_VOUT_CLKDEL=2
+ export SSTV2_SLIS_VIN_CLKDEL=3
+ export SSTV2_SLIS_VOUT_CLKDEL=2
+
+ (Thanks to Phil Ross for this trick).
+
+
+
+
+The Mesa/Voodoo Environment Variables:
+--------------------------------------
+
+ - Only for Windows/Voodoo Rush users, if you define the
+ env. var. MESA_WGL_FX:
+ export MESA_WGL_FX=fullscreen
+ you will get fullscreen rendering;
+
+ - Only for Windows/Voodoo Rush users, if you define the
+ env. var. MESA_WGL_FX:
+ export MESA_WGL_FX=window
+ you will get window rendering (default value);
+
+ - Only for Linux users, you can find more informations about
+ the env. var. MESA_GLX_FX in the "Doing more with Mesa & Linux Glide"
+ section;
+
+ - If you define the env. var. MESA_FX_SWAP_PENDING:
+ export MESA_FX_SWAP_PENDING=4
+ you will able to set the maximum number of swapbuffers
+ commands in the Voodoo FIFO after a swapbuffer (default value: 2);
+
+ - If you define the env. var. MESA_FX_INFO:
+ export MESA_FX_INFO=1
+ you will get some useful statistic.
+
+ - If you define the env. var. MESA_FX_NO_SIGNALS:
+ export MESA_FX_NO_SIGNALS=1
+ Mesa/FX will not install atexit() or signal() handlers.
+
+
+
+Know BUGS and Problems:
+-----------------------
+
+ - fog doesn't work in the right way when using the glDepthRange() function;
+
+ - Maximum texture size: 256x256 (this is an hardware limit);
+
+ - Texture border aren't yet supported;
+
+ - A GL_BLEND in a glTexEnv() is not supported (it is an hardware limit);
+
+ - Use the glBindTexture extension (standard in OpenGL 1.1) for texture
+ mapping (the old way: glTexImage inside a display list, download
+ the texture map each time that you call the display list !!!);
+
+ - Stencil buffer and Accumulation buffer are emulated in software (they are not
+ directly supported by the Hardware);
+
+ - Color index mode not implemented (this is an hardware limit);
+
+ - Thre is an know bug in the Linux Glide library so the in-window-rendering hack
+ and any other operations that requires to read the Voodoo frame buffer
+ (like the accumulation buffer support) doesn't work on Voodoo SLI cards.
+
+ - The driver switch to pure software (_slow_) rendering when:
+
+ - Stencil enabled;
+ - Using the Accumulation buffer;
+ - Blend enabled and blend equation != GL_FUNC_ADD_EXT;
+ - Color logic operation enabled and color logic operation != GL_COPY;
+ - Using GL_SEPARATE_SPECULAR_COLOR;
+ - The four values of glColorMask() aren't the some;
+ - Texture 1D or 3D enabled;
+ - Texture function is GL_BLEND;
+ - Using the Multitexture extension with Voodoo cards with only one TMU;
+ - Using the Multitexture extension with Voodoo cards with more than
+ one TMU, and texture function isn't GL_MODULATE;
+ - Point size is != 1.0 or point params vector != (1.0,0.0,0.0);
+ - Line width != 1.0 or using stipple lines.
+ - Using polygon offset or stipple polygons;
+
+ NOTE: this is list is not yet complete.
+
+
+Hints and Special Features:
+---------------------------
+
+ - Under Linux and with a Voodoo Graphics board, you can use
+ XMesaSetFXmode(XMESA_FX_FULLSCREEN or XMESA_FX_WINDOW) in order to
+ switch on the fly between fullscreen rendering and the in-window-rendering
+ hack.
+
+ - The driver is able to use all the texture memory available: 2/4MB on
+ Voodoo1 boards and 8MB (!) on high-end Voodoo1 and Voodoo2 boards.
+
+ - Trilinear filtering is fully supported on Voodoo boards with two TMUs
+ (high-end Voodoo1 boards and Voodoo2 boards). When only one TMU is
+ available the driver fallback to bilinear filter also if you ask
+ for trilinear filtering.
+
+ - The Voodoo driver support multiple Voodoo Graphics boards in the
+ some PC. Using this feature, you can write applications that use
+ multiple monitors, videoprojectors or HMDs for the output. See
+ Mesa-3.1/3Dfx/demos/tunnel2.c for an example of how setup one
+ context for each board.
+
+ - The v0.19 introduces a new powerful texture memory manager: the
+ texture memory is used as a cache of the set of all defined texture
+ maps. You can now define several MBs of texture maps also with a 2MB
+ of texture memory (the texture memory manager will do automatically
+ all the swap out/swap in
+ texture memory work). The new texture memory manager has also
+ solved a lot of other bugs/no specs compliance/problems
+ related to the texture memory usage.
+
+ - Use triangles and quads strip: they are a LOT faster than sparse
+ triangles and quads.
+
+ - The Voodoo driver supports the GL_EXT_paletted_texture. it works
+ only with GL_COLOR_INDEX8_EXT, GL_RGBA palettes and the alpha value
+ is ignored because this is a limitation of the the current Glide
+ version and of the Voodoo hardware. See Mesa-3.1/3Dfx/demos/paltex.c for
+ a demo of this extension.
+
+ - The Voodoo driver directly supports 3Dfx Global Palette extension.
+ It was written for GLQuake and I think that it isn't a good idea
+ to use this extension for any other purpose (it is a trick). See
+ Mesa-3.1/3Dfx/demos/glbpaltex.c for a demo of this extension.
+
+ - The Voodoo driver chooses the screen resolution according to the
+ requested window size. If you open a 640x480 window, you will get
+ a 640x480 screen resolution, if you open a 800x600 window, you
+ will get a 800x600 screen resolution, etc.
+ Most GLUT demos support the '-geometry' option, so you can choose
+ the screen resolution: 'tunnel -geometry 800x600'.
+ Clearly, you Voodoo board must have enough framebuffer RAM (otherwise
+ the window creation will fail).
+
+ - The glGetString(GL_RENDERER) returns more information
+ about the hardware configuration: "Mesa Glide <version>
+ <Voodoo_Graphics|Voodoo_Rush|UNKNOWN> <num> CARD/<num> FB/
+ <num> TM/<num> TMU/<NOSLI|SLI>"
+ where: <num> CARD is the card used for the current context,
+ <num> FB is the number of MB for the framebuffer,
+ <num> TM is the number of MB for the texture memory,
+ <num> TMU is the number of TMU. You can try to run
+ Mesa/demos/glinfo in order to have an example of the output.
+
+Did you find a lot BUGs and problems ? Good, send me an email.
+
+
+
+FAQ:
+----
+
+For a complete FAQ check the Bernd Kreimeier's Linux 3Dfx HOWTO
+available at http://www.gamers.org/dEngine/xf3D (it includes also
+a lot of informations not strictly related to Linux, so it can be
+useful also if you don't use Linux)
+
+1. What is 3Dfx?
+
+3Dfx Interactive, Inc. is the company which builds the VooDoo 3-D graphics
+chipset (and others) used in popular PC cards such as the Diamond Monster 3D
+and the Orchid Righteous 3D (more informations at http://www.3dfx.com).
+
+
+2. What is Glide?
+
+Glide is a "thin" programming interface for the 3Dfx hardware. It was
+originally written for Windows/Intel but has been ported to Linux/Intel
+by Daryll Strauss.
+
+3Dfx, Inc. should be applauded for allowing the Linux version of Glide
+to be written.
+
+You can directly program with the Glide library if you wish. You can
+obtain Glide from the "Developer" section of the 3Dfx website: www.3dfx.com
+There's a Linux/Glide newsgroup at news://news.3dfx.com/3dfx.glide.linux
+
+
+3. What is fxmesa?
+
+"fxmesa" is the name of the Mesa device driver for the 3Dfx Glide library.
+It was written by David Bucciarelli and others. It works on both Linux
+and Windows. Basically, it allows you to write and run OpenGL-style programs
+on the 3Dfx hardware.
+
+
+4. What is GLQuake?
+
+Quake is a very popular game from id software, Inc. See www.idsoftware.com
+GLQuake is a version of Quake written for OpenGL. There is now a Linux
+version of GLQuake with works with the Mesa/3Dfx/Glide combo.
+
+Here's what you need to run GLQuake on Linux:
+ PC with 100MHz Pentium or better
+ a 3Dfx-based card
+ Mesa 3.1 libraries: libMesaGL.so libMesaGLU.so
+ Glide 2.4 libraries: libglide2x.so libtexus.so
+ GLQuake for Linux.
+
+Also, the windows version of GLQuake works fine with the Mesa OpenGL32.dll,
+you have only to copy the Mesa-3.1/lib/OpenGL32.dll in the GLQuake directory
+in order to test 'MesaQuake'.
+
+
+5. What is GLUT?
+
+GLUT is Mark Kilgard's OpenGL Utility Toolkit. It provides an API for
+writing portable OpenGL programs with support for multiple windows, pop-
+up menus, event handling, etc.
+
+Check the Mark's home page for more informations (http://reality.sgi.com/mjk_asd).
+
+Every OpenGL programmer should check out GLUT.
+
+GLUT on Linux uses GLX.
+
+
+6. What is GLX?
+
+GLX is the OpenGL extension to the X Window System. I defines both a
+programming API (glX*() functions) and a network protocol. Mesa implements
+an emulation of GLX on Linux. A real GLX implementation would requires
+hooks into the X server. The 3Dfx hardware can be used with GLX-based
+programs via the MESA_GLX_FX environment variable.
+
+
+7. Is the Voodoo driver able to use the 4Mb texture memory of
+the Pure3D boards ?
+
+Yes, the Voodoo driver v0.20 includes the support for Voodoo
+Graphics boards with more than 2Mb of texture memory.
+
+
+8. Do the Voodoo driver support the Voodoo Rush under Windows ?
+
+Yes, Diego Picciani has developed the support for the Voodoo
+Rush but David Bucciarelli has a Pure3D and a Monster3D and Brian Paul
+has a Monster3D, so the new versions of the Mesa/Voodoo sometime are
+not tested with the Voodoo Rush.
+
+
+9. Do the Voodoo driver support the Voodoo Rush under Linux ?
+
+No because the Linux Glide doesn't (yet) support the Voodoo Rush.
+
+
+10. Can I sell my Mesa/Voodoo based software and include
+a binary copy of the Mesa in order to make the software
+working out of the box ?
+
+Yes.
+
+
+11. Which is the best make target for compiling the Mesa for
+Linux GLQuake ('make linux-glide', 'make linux-386-glide', etc.) ?
+
+'make linux-386-opt-glide' for Voodoo1 and 'make linux-386-opt-V2-glide'
+for Voodoo2 boards because it doesn't include the '-fPIC'
+option (4-5% faster).
+
+
+12. Can I use a Mesa compiled with a 'make linux-386-opt-V2-glide'
+for my applications/programs/demos ?
+
+Yes, there is only one constrain: you can't run two Mesa applications
+at the some time. This isn't a big issue with the today Voodoo Graphics.
+
+
+Thanks to:
+----------
+
+Henri Fousse (he has written several parts of the v0.15 and the old GLUT
+ emulator for Win);
+
+Diego Picciani (he has developed all the Voodoo Rush support and the wgl
+ emulator);
+
+Daryll Strauss (for the Linux Glide and the first Linux support);
+
+Brian Paul (of course);
+
+Dave 'Zoid' Kirsch (for the Linux GLQuake and Linux Quake2test/Q2 ports)
+
+Bernd Kreimeier (for the Linux 3Dfx HOWTO and for pushing companies to offer
+ a better Linux support)
+
+3Dfx and Quantum3D (for actively supporting Linux)
+
+The most update places where find Mesa VooDoo driver related informations are
+the Mesa mailing list and my driver WEB page
+(http://www-hmw.caribel.pisa.it/fxmesa/index.shtml)
+
+
+David Bucciarelli (davibu@tin.it)
+
+Humanware s.r.l.
+Via XXIV Maggio 62
+Pisa, Italy
+Tel./Fax +39-50-554108
+email: info.hmw@plus.it
+www: www-hmw.caribel.pisa.it