Glide is a proprietary API plus drivers to access 3D graphics accelerator hardware based on chipsets manufactured by 3Dfx. Glide has been developed and implemented for DOS, Windows, and Macintosh, and has been ported to Linux by Daryll Strauss.
In the distribution is a libtexus.so
, which
is the 3Dfx Interactive Texture Utility Software.
It is an image processing libary and utility program
for preparing images for use with the 3Dfx
Interactive Glide library. Features of TexUS include
file format conversion, MIPmap creation, and support for
3Dfx Interactive Narrow Channel Compression
textures.
The TexUS utility program texus
reads images in several popular formats (TGA, PPM,
RGT), generates MIPmaps, and writes the
images as 3Dfx Interactive textures files
(see e.g. alpha.3df, as found in the distribution)
or as an image file for inspection. For details
on the parameters for texus
, and the
API, see the TexUS documentation.
Nope. Glide is neither GPL'ed nor subject to any other public license. See LICENSE in the distribution for any details. Glide is provided as binary only, and you should neither use nor distribute any files but the ones released to the public, if you have not signed an NDA. The Glide distribution including the test program sources are copyrighted by 3Dfx.
The same is true for all the sources in the Glide distribution. In the words of 3Dfx: These are not public domain, but they can be freely distributed to owners of 3Dfx products only. No card, No code!
Nope. The Glide source is made available only based on a special agreement and NDA with 3Dfx.
Currently, Linux Glide is unsupported. Basically, it is provided under the same disclaimers as the GLQuake DLL.
However, 3Dfx definitely wants to provide as much support as possible, and is in the process of setting up some prerequisites. For the time being, you will have to rely on the 3Dfx newsgroup (see below).
In addition, the Quantum3D web page claims that Linux support (for Obsidian) is planned for both Intel and AXP architecture systems in 2H97.
There are newsgroups currently available only on the NNTP server news.3dfx.com run by 3Dfx. This USENET groups are dedicated to 3Dfx and Glide in general, and will mainly provide assistance for DOS, Win95, and NT. The current list is:
3dfx.d3d.drivers 3dfx.events 3dfx.game.titles 3dfx.games.glquake 3dfx.glide 3dfx.glide.linux 3dfx.oem.products.diamond.monster3d 3dfx.oem.products.hercules.stingray128-3d 3dfx.oem.products.orchid.righteous3d 3dfx.oem.products.quantum3d.obsidian 3dfx.oem.products.realvision.flash3d 3dfx.products 3dfx.test
A mailing list dedicated to Linux Glide is in preparation
(ETA in late august). Send mail to
majordomo@gamers.org, no subject,
body of the message info linux-3dfx
to get
information about the posting guidelines, the
hypermail archive and how
to subscribe to the list or the digest when available.
Currently, you should rely on the newsgroup (see above), that is news.3dfx.com/3dfx.glide.linux. There is no official support e-mail set up yet. For questions not specific to Linux Glide, make sure to use the other newsgroups.
3Dfx will appoint an official maintainer soon. Currently, inofficial maintainer of the Linux Glide port is Daryll Strauss. Please post bug reports in the newsgroup (above). If you are confident that you found a bug not previously reported, please mail to Daryll at daryll@harlot.rb.ca.us
You could submit precise bug reports. Providing sample programs to be included in the distribution is another possibility. A major contribution would be adding code to the Glide based Mesa Voodoo driver source. See section on Mesa Voodoo below.
Yes. As of now, there is no other Voodoo Graphics (tm) driver available for Linux.
That depends on the application you are heading for. Glide is a proprietary API that is partly similar to OpenGL or Mesa, partly contains features only available as EXTensions to some OpenGL implementations, and partly contains features not available anywhere but within Glide.
If you want to use the OpenGL API, you will need Mesa (see below). Mesa, namely the Mesa Voodoo driver, offers an API resembling the well documented and widely used OpenGL API. However, the Mesa Voodoo driver is in early alpha, and you will have to accept performance losses and lack of support for some features.
In summary, the decision is up to you - if you are heading for maximum performance while accepting potential problems with porting to non-3Dfx hardware, Glide is not a bad choice. If you care about maintenance, OpenGL might be the best bet in the long run.
The version of Linux Glide to be released to the public is 2.4, as is the next release of Glide for DOS/Windows.
Note that this HOWTO has been written based on Linux Glide 2.3.1, as Glide 2.4 has not been released, and the Linux Glide 2.4 port as not been finished yet. As the API did not change, and as there are no changes planned for the Linux Glide distribution, this document should still address the most common problems.
The version of Linux Glide to be publicly released will be 2.4, following the release of DOS/Windows Glide 2.4. API and implementation are supposed to be identical.
Glide 2.2 has been ported to Linux in April 1997. The port of Glide 2.3.1 has been done in June 1997. Both lacked a key optimization for triangle setup, which will be included in the public Linux Glide 2.4 release. The previous ports have never been publicly available, and have been used for beta tests only.
There is exhaustive information available from 3Dfx. You could download it from their home page at www.3dfx.com/software/download_glide.html. These are for free, presuming you bought a 3Dfx hardware based board. Please read the licensing regulations.
Basically, you should look for some of the following:
You will find demo sources for Glide within the distribution (test programs), and on the 3Dfx home page. The problem with the latter is that some require ATB. To port these demos to Linux, the event handling has to be completely rewritten.
In addition, you might find useful some of the OpenGL demo sources accompanying Mesa and GLUT. While the Glide API is different from the OpenGL API, they target the same hardware rendering pipeline.