831 lines
26 KiB
Plaintext
831 lines
26 KiB
Plaintext
|
|
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
|