See hardware requirements above, there is a list of hardware that has been found to work.
You need to be root, or setuid your
application to run a Glide based application.
For DMA, the driver accesses /dev/mem,
which is not writeable for anybody but root,
with good reasons. See the README in the
Glide distribution for Linux.
There are compelling case where the setuid requirement is a problem, obviously. There are currently solutions in preparation, which require changes to the library internals itself.
If you are using the analog pass through configuration, the common SVGA or X11 display might look pretty bad. You could try to get a better connector cable than the one provided with the accelerator board (the ones delivered with the Diamond Monster 3D are reportedly worse then the one accompanying the Orchid Righteous 3D), but up to a degree there will inevitably be signal loss with an additional transmission added.
If the 640x480 full screen image created by the accelerator board does look awful, this might indicate a real hardware problem. You will have to contact the board manufacturer, not 3Dfx for details, as the quality of the video signal has nothing to do with the accelerator - the board manufacturer chooses the RAMDAC, output drivers, and other components responsible.
You terminated your application with Ctrl-C, or it did not exit normally. The accelerator board will dutifully provide the current content of the framebuffer as a video signal unless told otherwise.
When you application terminates in dual screen setups, the accelerator board does not provide video output any longer. Thus powersave kicks each time. To avoid this, use
setenv SST_DUALSCREEN 1
If you are running X when calling a Glide application, you probably moved the mouse out of the window, and the keyboard inputs do not reach the application anymore.
If you application is supposed to run concurrently
with X11, it is recommend to expose a full screen
window, or use the XGrabPointer and
XGrabServer
functions to redirect all inputs to the application
while the X server cannot access the display. Note
that grabbing all input with XGrabPointer and
XGrabServer does not qualify as well-behaved
application, and that your program might block the
entire system.
If you experience this problem without running X, be sure that there is no hardware conflict (see below).
If the system definitely does not respond to any inputs (you are running two displays and know about the loss of focus), you might experience a more or less subtle hardware conflict. See installation troubleshooting section for details.
If there is no obvious address conflict, there might still be other problems (below). If you are writing your own code the most common reason for locking is that you didn't snap your vertices. See the section on snapping in the Glide documentation.
It is possible you have a problem with memory region overlap specific to S3. There is some info and a patch to the so-called S3 problem in the 3Dfx web site, but these apply to Windows only. To my understanding, the cause of the problem is that some S3 boards (older revisions of Diamond Stealth S3 968) reserve more memory space than actually used, thus the Voodoo Graphics (tm) has to be mapped to a different location. However, this has not been reported as a problem with Linux, and might be Windows-specific.
If you happen to use a motherboard with non-standard or incomplete PCI support, you could try to shuffle the boards a bit. I am running an ASUS TP4XE that has that non-standard modified "Media Slot", i.e. PCI slot4 with additional connector for ASUS-manufactured SCSI/Sound combo boards, and I experienced severe problems while running a Diamond Monster 3D in that slot. The system operates flawlessly since I put the board in one of the regular slots.
As Linux Glide will be version 2.4, this error should not occur. This function was not available in Glide and thus Linux Glide 2.2;; the latter has never been released to the public.
Your application's source is based on Glide 2.2, and
this function was removed in Glide 2.3;. It is not
available anymore and so may not be used with Linux Glide
2.4. Modify your application to use the function
grSstWinOpen instead.
As the Linux Glide integration with Mesa was based on Glide 2.2 originally, earlier versions of Mesa might produce compile time errors. The Mesa-2.3b3 release has been patched to be used with Linux Glide 2.3.1; make sure to get both the distribution and the patches, or, preferably, a later revision of Mesa.
test25: error in loading shared libraries libglide2x.so: cannot open shared object file: No such file or directory
ldconfig setup, the program will
not find the shared library. Check the name (e.g. libglide2x.so)
and make sure that the proper flags are used when compiling and
linking - e.g. -lglide might not work with the default
installation.
Note that the naming of Linux Glide revisions follows the conventions used in the 3Dfx Windows distribution, not the conventions common for Linux.
Be sure to set USE_GLIDE_FULLSCREEN
in fxmesa.h. Check whether the linkage options
(e.g. -lglide) match the name of the Linux
Glide library installed (e.g. -lglide2x instead).
Be sure to use the patches to Mesa-2.3b3 or a later
release, as all Mesa releases up to 2.3b3 were based on
Linux Glide 2.2. See above.
Be sure that you recompiled all the libraries (including
the toolkits the demo programs use - remember that
GLUT does not yet support Voodoo Graphics (tm)), and that you
removed the older libraries, run ldconfig,
and/or set your LD_LIBRARY_PATH properly.
Mesa supports several drivers in parallel (you could
use X11 SHM, off screen rendering, and Mesa Voodoo at
the same time), and you might have to create and
switch contexts explicitely (see MakeCurrent
function) if the Voodoo Graphics (tm) isn't chosen by default.