Please see: http://evil.inetarena.com/linux/state-o-glide.2001-02-26.txt for the original version in case the formatting gets messed up.
I wanted to see if much has changed from glide in CVS. Most importantly
I wanted to see how glide3 was fairing with XFree 3.3.x. The puchline,
so save you from having to read this whole thing, is that
Voodoo3 + XFree 3.3.x users should stick with glide2. I would not
even bother installing glide3 as it will just mess things up.
I will report later on the latest XFree4.0.2 (CVS).
Here is what I discovered and some how-to:
o Glide2 has not changed for a while. One can d/l the cvs version (module
name 'glide2') and d/l the module 'swlibs' in that directory. The
makefile.linux works however there is no install section. In order
to get Mesa-3.4.1 to use glide2, one must install
./glide2/h3/glide/src/libglide.so.2.60 into a directory searched
by ldconfig, say /usr/lib, as libglide2.so.2.60. Links also need to
be made for libglide2.so -> libglide2.so.2.60. In /usr/include/glide2 the
files 3dfx.h glide.h glidesys.h glideutl.h gump.h
linutil.h sst1vid.h and texus.h need to be installed. Some of them are
under ./glide2/h3/include and others are under ./glide2/swlibs/include.
If you have installed these libs and removed all other glide libraries
(i.e. glide3), then the configure script will find and use the glide2
o Glide3 is a whole other ball of wax. Getting it to compile as a non-dri
takes a bit of work. The cvs module to get is 'Glide3' which will get both
glide3 and swlibs. Follow the instructions in the INSTALL script. However,
it is important to note that the configure --help is wrong about building
non-dri libs. It says to use "--disable-fx-build-dri" however it should
be "--disable-fx-dri-build". If you build a dri glide3 with XFree 3.3.x
you will get errors like "non-existant SST". In this case you MUST do
a "rm -rf build" to clean out your build directory and try again. If
you do not do the recursive rm then the links will not get updated for
the non-dri build.
o After you run configure, you need to edit
./Glide3/h3/glide3/src/gglide.c.save. Copy (in the same area of the
file) the function grStippleModee from gglide.c.dri. If you do not
the lib will still compile but it will crash when you try to run
an OpenGL program.
o You can now compile and install glide3.
o To compile Mesa-3.4.1 you need to untar the files, run configure and
start the build (run make). It will go for a while and stop with an
error "/usr/lib/libglide3.la: file not recognized: File format
not recognized". You then need to edit ./Mesa-3.4.1/src/FX/libMesa.la
about line 17 that defines "dependancy_libs". Change it so it
reads "-lglide3" instead of "/usr/lib/libglide3.la" leaving the other
parameters alone. Run make again to finish the build.
o After doing all of this, I could run quake3 with Mesa+glide3. However,
the texture errors were still present just not as bad as the RPM
released glide3. The FPS seemed about the same as glide2, perhaps ever
so slightly faster.
I 'must' be doing something wrong then...
I first tried out the standard RPMs for glide and Mesa, and Unreal Tournament would run, but would crash very shortly into the game, and Quake3 displays a very scrambled version of the screen, that after figuring out how to exit crashes the XServer.
I followed your directions exactly, and recieved the same errors with the CVS release...
This driver set CVS'd (March 31 2001)
Red Hat 7.0
Kernel 2.4.2 (with DRI+3dfx and I2c enabled)
AMD Athalon 800mhz (was not compiled with 3dnow)
I am very lost at this point, and almost frustrated enough to either format to put an OS on that will let me play games, or buy a video card that has a little better support (and better documentation) then the 3dfx series, having half of the 3dfx driver sites (including 3dfx.gamers.com) drop their linux support (or just die altogether) doesn't help...
Log in to post a comment.