| |
| 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 |