We'll run through the different gaming libraries you'll see under Linux.
Glide2 is a low level graphics API and driver that accesses 3D hardware accelerated functions on 3dfx's Voodoo I, II and III cards, under XFree86 3.x.
A program can only use the special hardware accelerated features of these cards by using the Glide2 library in one of two ways:
directly written using Glide2 (Myth II, Descent III)
indirectly using Mesa built with a Glide2 backend to simulate OpenGL (Rune, Unreal Tournament)
3dfx opened up the specifications and source code to the open source community. This allowed Daryll Strauss to port Glide2 to Linux which enabled XFree86 3.x users to use Voodoo I, II and III cards under Linux.
Since Glide2 accesses the video card directly, Glide2 applications will either need to be run by root or be setuid root. A way around this was to create the kernel 3dfx module. This module (and its device file /dev/3dfx) allows Glide2 graphical hardware acceleration for non-root users of non-setuid applications.
Unfortunately, Glide2 is also a dead issue. It's only used for Voodoo I, II, III boards (which are becoming outdated), under XFree86 3.x (most people use XFree86 4.x). And since 3dfx is now a defunct company, it's a sure bet that no more work will be done on Glide2 and no more games will be written using Glide2.
Unlike Glide2, Glide3 is not an API used for game programming. It exists only to support DRI on Voodoo III, IV and V boards under XFree86 4.x. None of the games which use Glide2 will work with Glide3. This shouldn't be a surprise since Glide2 and Glide3 support different video cards and different versions of XFree86. The only video card that can use both Glide2 (under XFree86 3.x) and Glide3 (under XFree86 4.x) is the Voodoo III. It's reported that a Voodoo III using Glide2 will outperform a Voodoo III using Glide3.
When you use a Voodoo III, IV or V under XFree86 4.x, you want to use a version of Mesa (see Section 3.4) which was compiled to use Glide3 as a backend to ensure hardware accelerated OpenGL on your system.
OpenGL is a high level graphics programming API originally developed by SGI, and it became an industry standard for 2D and 3D graphics programming. It's defined and maintained by the Architectural Revision Board (ARB), an organization which include representatives from SGI, IBM, DEC, and Microsoft. OpenGL provides a powerful, complete and generic feature set for 2D and 3D graphics operations.
There are 3 canonical parts to OpenGL:
GL: The OpenGL core calls
GLU: The utility calls
GLUT: OS independent window event (mouse, keyboard, etc.) handler.
OpenGL is not only an API, it's also an implementation, written by SGI. The implementation tries to use hardware acceleration for various graphics operations whenever available, which depends on what videocard you have in you computer. If hardware acceleration is not possible for a specific task, OpenGL falls back on software rendering. This means that when you get OpenGL from SGI, if you want any kind of hardware acceleration at all, it must be OpenGL written and compiled specifically for some graphics card. Otherwise, all you'll get is software rendering. The same thing is true for OpenGL clones, like Mesa.
OpenGL is the open source equivalent to Direct3D, a component of DirectX (Section 3.14). The important difference being that since OpenGL is open (and DirectX is closed), games written in OpenGL are much easier to port to and co-develop on Linux than games written using DirectX.
Mesa <http://www.mesa3d.org> is a free implementation of the OpenGL API, designed and written by Brian Paul. While it's not officially certified (that would take more money than an open source project has), it's an almost fully compliant OpenGL implementation conforming to the ARB specifications. It's reported that Mesa is even faster than SGI's own OpenGL implementation.
Just like OpenGL, Mesa makes use of hardware acceleration whenever possible. When a particular graphics task isn't able to be hardware accelerated by the video card, it's software rendered; the task is done by your computer's CPU instead. This means that there are different builds of Mesa depending on what kind of video card you have. Each build uses a different library as a backend renderer. For example, if you have a Voodoo I, II or III card under XFree86 3.x, you'd use mesa+glide2 (written by David Bucciarelli) which is the Mesa implementation of OpenGL that uses Glide2 as a backend to render for graphical operations.
Graphics rendering has 3 players: the client application (like Quake 3), the X server and the hardware (the graphics card). Previously, client applications were prohibited from writing directly to hardware, and there was a good reason for this. A program that is allowed to directly write to hardware can crash the system in any number of ways. Rather than trusting programmers to write totally bug free, cooperative programs that access hardware, Linux simply disallowed it. However, that changed under X 4.x with DRI (Direct Rendering Infrastructure <http://www.dri.sourceforge.net>. DRI allows X clients to write 3D rendering information directly to the video card in a safe and cooperative manner.
DRI gets the X server out of the way so the 3D driver (Mesa or OpenGL) can talk directly to the hardware. This speeds things up. The 3D rendering information doesn't even have to be hardware accelerated. On a technical note, this has a number of virtues.
Vertex data doesn't have to be encoded/decoded via GLX.
Graphics data isn't sent over a socket to the X server.
On uni-processor machines the CPU doesn't have to change context between XFree86 and its client to render the graphics.
GLX is the X extension used by OpenGL programs, it is the glue between the platform independent OpenGL and platform dependent X.
Utah-GLX is the precursor to DRI. It makes some different design decisions regarding separation of data and methods of accessing the video card like relying on root access rather than creating the kernel infrastructure for secure access. It provides support for a few cards which are not well supported by DRI like the ATI Rage Pro family, S3 Virge (although anyone using this for gaming is, well, nuts), and an open source TNT/TNT2 driver (which is very incomplete). The TNT/TNT2 driver is based on reverse-engineering of the obfuscated source code release of the X 3.3 drivers by nVidia. However, they're really incomplete, and effectively, unusable.
Every once in awhile you'll see some sicko (said with respect) write a game in xlib. It is a set of C libraries which comprise the lowest level programming interface for XFree86. Any graphics programming in X ultimately makes use of the xlib library.
It's not an understatement to say that xlib is long winded, arcane and complicated. Because of this, there are lots of libraries like SDL (Section 3.10) for 2D graphics, OpenGL (Section 3.3) for 3D graphics and widget sets (Section 3.9) for widgets within windows which hide the details of different aspects of xlib programming.
While some games are written in xlib, like the Doom Editor Yadex, xlib itself is not a serious game writing library. Most games don't need the low-level interface that xlib provides. In addition, by using the higher level libraries, a game writer can develop his game on multiple platforms, even ones that don't use XFree86.
Widgets are objects that make up a GUI application's interface. They include things like text entry boxes, pulldown menus, slider bars, radio buttons and much more. A widget set is a collection of related widgets that are designed to have a common interface and a consistant "feel". Gtk is the canonical widget set on Linux, but there are many others like fltk (a small C++ widget set), Xaw, Qt (the widget set of KDE), and Motif (the widget set used by Netscape). Motif used to be the king of widget sets in the Unix world, but it was very expensive to license. The Open Group finally opened up Motif's license for open source operating systems, but it was too little too late. There are many completely open source widget sets which are more complete and much nicer looking than Motif, including Lesstif, a totally free Motif clone.
SDL <http://www.libsdl.org> is a library by Sam Lantiga (graduate of UCD, yeah!). It's actually a meta-library, meaning that not only is it a graphics library which hides the details of xlib programming, it provides an easy interface for sound, music and event handling. It's LGPL'd and provides joystick and OpenGL support as well. Unlike xlib (Section 3.8), SDL is very suited for game programming.
The most striking part of SDL is that it's a cross platform library. Except for a few details, a program written in SDL will compile under Linux, MS Windows, BeOS, MacOS, MacOS X, Solaris, IRIX, FreeBSD, QNX and OSF. There are SDL extensions written by various people to do things like handle any graphics format you care to mention, play mpegs, display truetype fonts, sprite handling and just about everything under the sun. SDL is an example of what all graphics libraries should strive for.
Sam had an ulterior motive for writing such a cool library. He was the lead programmer for Loki Software (he now codes for Blizzard Software), which used SDL in all of its games except for Quake3.
GGI <http://www.ggi-project.org> is a project which aims to implement a graphics abstraction layer in lower level code, put graphics hardware support into a common codebase, and bring higher stability and portability to graphics applications. LibGGI applications run on SVGAlib, fb, and X servers among others. Judging from their screenshots, this is quite a powerful library.
Applications that use LibGGI directly include Heroes, Ultrapoint, Quake, and Berlin. Most applications that use SVGALib can be run on X or any other LibGGI backend by using a wrapper library which re-implements SVGALib (Section 3.12) using LibGGI. SDL (Section 3.10) and clanlib (Section 3.15) applications can display on LibGGI but often the native drivers for these libraries are faster, however it's a good way to get SDL, clanlib, and SVGALib applications to run where they would not before.
GGI has a sister project, KGI, which is developing a kernel-level alternative to systems like the linux framebuffer and the DRI. This project is much less far along than LibGGI itself, but promises to combine DRI-level speeds and the stability and security UNIX users expect.
The console is the dark non-graphical screen you look at when your computer first boots up (and you don't have xdm or gdm running). This is opposed to the X environment which has all sorts of GUI things like xterms. It's a common misconception that X means graphics and console means no graphics. There are certainly graphics on the console—we will discuss the two most common ways to achieve this.
SVGAlib is a graphics library that lets you draw graphics on the console. There are many graphical applications and games that use SVGAlib like zgv (a console graphical image viewer), prboom and hhexen. I happen to be a fan of this library and of graphical console games in general; they are extremely fast, fullscreen and compelling. There are three downsides to SVGAlib. First, SVGAlib executables need to be run by root or be setuid root, however, the library releases root status immediately after the executable begins to run. Secondly, SVGAlib is video card dependent–if your video card isn't supported by SVGAlib, you're out of luck. Third, SVGAlib is Linux only. Games written in SVGAlib will only work on Linux.
Frame buffers are consoles implemented by a graphics mode rather than a BIOS text mode. Why simulate text mode in a graphical environment? This allows us to run graphical things in console, like allowing us to choose any font we want the console to display (which is normally set by BIOS). There's a good Framebuffer HOWTO available from LDP. Graphical console games written using the frame buffer suffer from the same deficiencies of the SVGA library: not all hardware is supported and the code will only run on Linux.
OpenAL <http://www.openal.org> aims to be for sound what OpenGL is for graphics. It started as a joint project between Loki Software and Creative Labs, setting out to be a vendor neutral and cross platform API for audio - the audio equivalent of OpenGL (Section 3.3). Loki is no longer in business, but Creative and the Open Source community have kept the project alive. It is licensed LGPL and the specs can be obtained for free from the OpenAL website. It has support from nVidia (nForce2/3 based motherboards come with OpenAL MS Windows libraries for the on-board audio), Apple has added OpenAL to their audio framework for OSX and it can also be found powering the Epic Games Unreal Engine
Currently, it's not all cross-platform goodness. There is almost no support for enhancements like EAX or any hardware acceleration on Linux, though it does it exist in the Windows implementation. However, if you have a Creative SoundBlaster or Audigy sound card (with an emu10x chip), and you use ALSA sound drivers, you can get OpenAL libraries from http://www.lost.org.uk that provide hardware acceleration and decent surround support.
DirectX is a collection of proprietary multimedia API's, first developed by Microsoft in 1995, for its various Windows OS's. It's a mistake to say something like "DirectX is like OpenGL" or "DirectX is like SDL", as is commonly said in DirectX tutorials. Multimedia API's are more centralized on Windows than they are on Linux. A more accurate statement would be something like "DirectX is like DRI, OpenGL and SDL combined". As of October 2004, the most recent version of DirectX is 9c. The components of DirectX are:
DirectDraw gives direct access to video memory, like DRI, so 2D graphics can be blitted directly to the video card. DirectDraw is like the graphical component of SDL, but the direct video card access is done by DRI rather than SDL. This is why a game can easily take out a Windows system but should not take down a Linux system.
Direct3D, like OpenGL, provides a 3D graphics API. Whereas OpenGL is open source, lower level and compiles under a multitude of operating systems, D3D is proprietary, higher level and only compiles on Windows. D3D first appeared in DirectX 2, released in 1996.
DirectAudio is a combination of 2 audio API's, DirectSound and DirectMusic, which allows direct access to the sound card for sound and music playback.
DirectInput gives support for gaming input devices such as joysticks.
DirectPlay gives support for simplified networking for multiplayer gaming.
DirectShow provides support for movie files like AVI and MPG. It was a separate API from DirectX, but was integrated with DirectX 8.
This API provides a way to install DirectX from within an application to simplify game installation.
Depending on the version of DirectX you're talking about, DirectX support in winex (Section 10.5.3) ranges from well supported to "kind of" supported. It's poorly supported by wine (Section 10.5.1), barely supported by vmware (Section 10.5.5) and unsupported by Win4Lin (Section 10.5.4).
One comment about portability: Each component of DirectX has multiple corresponding library on Linux. Moreover, a game writer who uses libraries like OpenGL, GGI or SDL will write a game which will trivially compile on Windows, Linux and a multitude of other OS's. Yet game companies persist using DirectX and therefore limit their audience to Windows users only. If you're a game writer, please consider using cross platform libraries and stay away from DirectX.
A company named realtechVR started an open source project, DirectX Port, <http://www.v3x.net/directx> which, like wine, provides a Direct3D emulation layer that implements Direct3D calls. The project was focused on the BeOS platform, but is now focused on MacOS and Linux. You can get the latest cvs from their sourceforge page at <http://sourceforge.net/projects/dxglwrap>.
ClanLib is a medium level development kit. At its lowest level, it provides a platform independent (as much as that is possible in C++) way of dealing with display, sound, input, networking, files, threading and such. ClanLib builds a generic game development framework, giving you easy handling of resources, network object replication, graphical user interfaces (GUI) with theme support, game scripting and more.