(Most of the information on this page has been based on the contents of emails from Michael Vance and Bernd Kremeier, but only the pieces specifically attributed to them are actually in their own words. Responsibility for any mistakes rests with Neal Tringham.) Linux (OS support library: glx)
Sections
X, changing screen resolution, and colour depths
Freely available drivers based on Mesa, in varying stages of development as of December 1999, are available for cards from 3dfx, NVidia and Matrox. Development work is also being done on cards from ATI and, I believe, 3DLabs (by SuSE). This list may well be incomplete. For most of these development efforts, the source code for the drivers is freely available, along with chip specs or an underlying low level API which has been ported to the platform. An interview with Brian Paul, the original author of Mesa, is available on Slashdot.
Bernd Kremeier adds that (as of 9th December 1999) he knows of the following Mesa based implementations:
------------------------------------------------------------------------------------------------
3dfx Voodoo (all kinds) / Mesa-3.x / Glide2 (binaries)
3dfx VB/V3 / Mesa+XFree86-4 DRI pre-release / Glide3 (open source)
Matrox G200/G400 /Mesa 3.2 + Utah GLX (open source)
ATI Rage Pro / Mesa 3.2 + Utah GLX (open source)
NVidia TNT/TNT2/geForce / Mesa-3.0 + XFree86 3.3.3 patched / (slow)
NVidia new driver release due 12/99 (binary)
Matrox released full specs a while ago. 3dfx just released full specs. nVidia released only obfuscated sources. No idea about the others. SuSE supports a bunch of cards (they were working on their own GLX).
------------------------------------------------------------------------------------------------
As of January 2000, the "Utah GLX" project mentioned by Bernd Kremeier above actually supports the Matrox G200 and G400, the ATI Rage Pro, the Intel 810, NVidia Riva series cards and the S3 Virge, in varying stages of development.
A more complete and very helpful summary of Mesa based drivers on Linux is also available. This link should also serve as a single source of information about Mesa installation, upgrades and support under Linux.
Matrox also have a page of notes on how to install accelerated glX for their hardware, with precompiled binaries.
Note that SGI have made the source for the platform support library, glx, freely available. SGI are now also supporting Mesa based implementations as their "preferred approach for delivering solutions on Linux".
There is also a SourceForge project for Glide, including Linux versions for Intel and Alpha processors.
Xig have also released a commercial X server for Linux with a different set of OpenGL drivers. Xig drivers can be purchased individually, and test versions downloaded, as of January 2000.
Another commercial implementation is in development from MetroExtreme.
SGI, VA Linux and NVidia are working on a commercial implementation of OpenGL 1.2 for Linux boxes with NVidia hardware installed. A Q & A about this commercial implementation is available online.
A very useful page of general information on accelerated commercial and free OpenGL and Mesa implementations under Linux can be found on the linux3d site. Interestingly, as of December 1999 the most popular gaming cards (e.g. 3dfx or NVidia hardware) are supported by open source rather than commercial implementations.
Bernd Kremeier writes (about open source architectures intended to be used with XFree86):
------------------------------------------------------------------------------------------------
There are basically 3 architectures: a) standalone Mesa with fake GLX (your basic libMesaVoodooQ3AGL.so if Glide is thrown in for good measure)
b) XFree86-3 glx.so loadable module and Mesa using this GLX (nVidia's Mesa-3.0 pre-release, Utah GLX for Matrox)
c) XFree86-4 GLX/DRI (no idea, but glx.so seems gone) (PI's/3dfx's pre-release for VB/V3)
Throw in /dev/3dfx and /dev/gart related kernel modules for good measure.
------------------------------------------------------------------------------------------------
Here DRI is Precision Insight's Direct Rendering Infrastructure, which allows drivers to access the hardware without a complicated protocol, and which is important to gain the speed required for games if glX is used. A Q&A session about the DRI is available online. There is now a DRI open source project on SourceForge.
glX is the operating system support library, now open sourced by SGI. "Utah" glX is an accelerated version of glX which can access Matrox accelerator hardware, but will not be as fast as an implementation which used the DRI to bypass much of the glX protocol. Old non DRI Voodoo drivers go straight to Glide, and bypass much of the normal glX infrastructure.
Here is a document on the status of XFree86 integration with Mesa and OpenGL, slightly out of date as of December 1999. This page contains information on the status of the accelerated glX project.
It seems likely that all current drivers will soon be using the DRI approach, and "3dfx standalone Mesa" and non DRI glX drivers will become obsolete. It also seems very likely that following the upcoming release of XFree86 version 4.0 using and configuring 3d on Linux will become very much easier, since XFree86 version 4 should include 3d support as part of the standard install.
Bernd Kremeier adds:
------------------------------------------------------------------------------------------------
OpenGL for Linux is a rapidly moving target, and convergence between the three architectures above has yet to happen. XFree86-4 might make things worse for a short time, but will make things a lot better (hopefully soon).
------------------------------------------------------------------------------------------------
The Xig and MetroExtreme commercial implementations have different architectures. Xig's drivers, for example, are designed to work with their own closed source implementation of X. More specific information about these designs may be available from the companies concerned under NDA.
X, changing screen resolution, and colour depths
In general, major OpenGL games for Linux are written to X, which has the level of support required to provide the needed services (e.g. available drivers, the DRI infrastructure etc). Sample code for initialising an OpenGL program under X, using the glX library, can be found in the Mesa demos (see e.g. glxdemo.c in the xdemos directory).
Changing screen resolution in X (so that e.g. you can "go fullscreen" by changing the resolution to be the same as that of your game's window) is normally done via the VideoModeExtension. Sample code using this extension can be found in the downloads section.
In order to change the colour depth in X you must restart the X server. One way of handling this is to start a second X server with a minimal window manager when the game is launched. The release of XFree86 4.0 should remove the need to restart the server to change colour depth.
Here are some general notes on programming X from the Little Unix Programmers Group Little Site.
Mesa drivers are OpenGL 1.2 compliant, although not all of the 1.2 interface may be hardware accelerated on any given card.
Current Mesa source trees (3.1/3.2/3.3) include support for many commonly used "game" extensions, such as EXT_compiled_vertex_array. The Linux OpenGL application binary interface standard is defining a common base set of extensions (ARB_multitexture, EXT_vertex_array etc) between commercial and open source OpenGL implementations on Linux, as well as adding support for glXGetProcAddress to allow runtime querying of extension addresses on Linux (and standardising other issues, such as the position in the directory hierarchy to which OpenGL libraries are installed).
A full list of the specifications of the various "officially registered" extensions can be found in the OpenGL extensions registry, maintained by Jon Leech.
A list of OpenGL extensions supported by different (free and commercial) implementations on Linux is also available.
Current Mesa versions now include geometry acceleration on processors with 3DNow! or Katmai support.
Mesa based drivers are generally built to support one particular card, and include their own software renderer to handle any defaults that may be necessary.
Drivers for 3d only Voodoo cards such as the Voodoo 1 or 2 will normally switch you over to the Voodoo display automatically as you load the driver, taking the screen size from your window size under X.
Mesa drivers can render in a window on the desktop on Voodoo 1 or 2 hardware by copying the contents of the 3d fullscreen output back to the desktop, at the expense of some loss of frame rate. This behaviour is controlled by the contents of the MESA_GLX_FX variable.
It is possible for a 3dfx standalone card and a "normal" 2d / 3d accelerator to co-exist in the same machine. An OpenGL program on such a machine will be accelerated by whichever card corresponds to the version of libGL.so it uses. This choice can be made at runtime by dynamically loading the library.
Linux does not have an obvious "standard" set of game specific libraries for handling the sort of non 3D low level issues (input, sound etc) which are dealt with by DirectX on Windows and various Sprockets on the Mac.
Perhaps the best candidate is Loki Games' open source library SDL, which supports pure 2d rendering, audio, input, threads and movie playback, works well with OpenGL, and has been used for ports of commercial games to Linux. In general, Loki Games do a static link against SDL, and do not need to ensure that specific drivers are installed on the target (other than OpenGL ones). Loki Games also host development for an open source Linux games installer and FMV player.
A possible alternative is Steve Baker's PLIB.
Andreas Umbach recommends libmikmod as an alternative to SDL for sound support.
The open source cross platform audio library OpenAL is also available as of March 2000, and should be easy to use with SDL.
Bernd Kremeier adds (9th December 1999):
------------------------------------------------------------------------------------------------
I actually want to get a modular toolbox for Linux put together that we use in-house, to be shared with interested developers. The pending release of the UnrealTournament Linux code modules, the sometime release of the original Quake engine source, and SDL plus SMPEG plus some more in-house tools should be a good foundation to get something together that works for many.
------------------------------------------------------------------------------------------------
Note that there is now a SourceForge project for Unreal's Linux modules, specifically XDrv, XMesaGLDrv, GlideDrv, XLaunch and Audio. The full Quake 1 source, including Linux OpenGL versions, is also available.
One classic issue that developers should be aware of on Linux is the existence of variant versions of libc. Michael Vance writes:
------------------------------------------------------------------------------------------------
Re: libc - different distributions have different, binary incompatible (ABI) libcs, which means that you have a binary app that only works for one libc, but people use multiple (we only support two right now, glibc 2.0, and glibc 2.1). You get to multiplex this across architectures if you're doing non-x86 dev, also. And there are nasty issues--people want to play quake3 on rh-5.2 systems, which use glibc-2.0, but our installer requires gtk+-1.2.X, which didn't come with rh-5.2.
Statically linking only gets you so far. We've had very subtle problems with binaries statically linked against glibc-2.0 not working right on systems with glibc-2.1--a particular kernel interface changed somewhere, and it happens that most glibc-2.1 systems are running newer kernels (but you're glibc-2.0 box runs an old one). getpid() I think did this somewhere (the move to 32-bit user id structures from the old 16-bit ones). Etc.
------------------------------------------------------------------------------------------------
Supporting only glibc-2.1 and requiring users to upgrade is probably the best policy from the development point of view (and should be reasonably future proof).
Other than this, there are no very obvious development issues other than those involved with delivering and upgrading OpenGL drivers which must work with multiple Linux distributions, X servers, window managers etc. OpenGL compatible drivers for Linux will presumably agree on a standard set of interfaces as defined by the Linux OpenGL Standard Base Initiative, and Mesa based free implementations do seem to be converging on a base technology of DRI access via X, but there is as yet no equivalent of GLSetup (for Windows) or the Apple OpenGL installer to handle installation and upgrade issues for end users. Such a system (for example, a GLSetup port to Linux, which has certainly been discussed) seems likely to appear after the forthcoming release of XFree86 version 4.0.