diff options
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.3DFX | 830 |
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 |