Originally Published: Tuesday, 26 June 2001 Author: John Hall and Loki Software
Published to: develop_articles/Development Articles Page: 2/6 - [Printable]

Linux Gaming APIs: Chapter 3 of PROGRAMMING LINUX GAMES

Today's Linux.com article, derived from Chapter 3 of the book Programming Linux Games by John Hall, takes a look at the various Linux gaming APIs you can use to construct your game. Don't reinvent the wheel, and don't compromise your open source roots, and check out this excerpt from No Starch Press.

Graphics APIs  << Page 2 of 6  >>

Graphics APIs

Linux offers several options for graphics programming. Most of today's Linux games use the X Window System in some way, as it is almost universally available, well supported, and at least tolerably fast [FOOTNOTE: The X Window System is incredibly flexible, and it's really not a bad platform for gaming. However, its design requires all graphics data to pass through certain pre-defined channels, and the use of extensions is required to achieve acceptable game performance in most cases (among these extensions are shared memory access and the XVideo extension). X was never really intended for today's level of high-speed graphics processing. Some people think X should be replaced with a new system, but I believe that it just needs a bit of reworking in some areas. X has a lot going for it.] Recently the Linux framebuffer device interface has been making inroads into gaming, and this interface has a lot of potential. Finally, SVGALib provides a way to get extremely fast access to SVGA compatible video devices.


As its name implies, SVGALib is a library for programming Super VGA-compatible video hardware, which is extremely fast because it directly accesses the system's video hardware. SVGALib has fallen out of favor recently, due to its inconvenient interface, its failure to fully support many of today's video chipsets, and its demand for root privileges. Furthermore, it is known to conflict with the X Window System, and in some cases it is incompatible with Linux's new framebuffer device system. While SVGALib is still under development, it is reasonable to predict that its use will continue to decline.

SVGALib is distributed with a sister library called vgagl (not to be confused with the OpenGL library). The vgagl library provides higher-level drawing and blitting functions that make an SVGALib programmer's life a bit easier. SVGALib also includes sub-libraries for keyboard and mouse access.

If you really want to mess with SuperVGA video cards, don't mind locking up your console occasionally, and don't care too much about wide compatibility, SVGALib may be worth looking into. Otherwise, your hacking effort is probably better spent elsewhere.


General Graphics Interface (GGI) is a massive, general-purpose, multi targeted graphics library that provides a complete graphics system for games and other applications. Its companion library, GII, provides portable input device support, and games that use it are meant to be easily portable to any platform. GGI does not depend on any one method of accessing graphics devices; instead, it provides a system of "back ends" that can support just about anything remotely resembling a graphics device. The GGI Project is also working on a kernel-based graphics infrastructure, KGI. GGI is free software, distributed under the GNU LGPL. The GGI Project's Web site is http://www.ggi-project.org.


Simple DirectMedia Layer (SDL) is a cross-platform multimedia library developed with commercial game porting in mind. (In fact, it has already been used to port a number of games from Windows to Linux, including most of Loki's titles.) SDL supports almost all of the major operating systems, including Linux, Windows, BeOS, and MacOS. In addition to fast graphics support, SDL provides interfaces for playing sound, accessing CD-ROM drives, and achieving portable multithreading.

SDL is also an excellent library for free software projects: Released under the GNU LGPL, it has everything a programmer needs to write fast, portable games. SDL has accumulated a collection of user-contributed libraries that provide additional functionality for game developers.

We will discuss the SDL library in detail later. SDL's website is http://www.libsdl.org, and a helpful group of SDL enthusiasts (including myself [FOOTNOTE: My name on IRC is "overcode". I'm not difficult to find.]) gathers on IRC at irc.openprojects.net, #sdl.


ClanLib is a C++ game-programming library that, like SDL, stresses platform independence and optimal use of the system's underlying multimedia resources. Released under the GNU LGPL, ClanLib's design is very clean and extensible. ClanLib is a higher-level library than SDL: Whereas SDL provides a relatively small set of C functions for accessing the computer's hardware in a portable way, ClanLib provides a complete C++ infrastructure for game development. We will cover SDL rather than ClanLib in this book, but ClanLib is certainly a worthy contender. You can find more information about ClanLib at http://www.clanlib.org.


OpenGL is a 3D graphics API designed by Silicon Graphics and developed by an Architecture Review Board (ARB) of graphics industry leaders. Although it was not originally intended as a game-programming library, OpenGL has found a place as a convenient interface standard for hardware-accelerated 3D graphics, and therefore lends itself well to gaming. The Mesa 3D Graphics Library is a free implementation of the OpenGL specification, and there are Mesa-based Linux drivers for several popular 3D accelerator cards.

Unfortunately, we can't cover OpenGL here in the detail it deserves (3D graphics is a subject of its own), but we'll at least demonstrate how to gain access to OpenGL from within SDL programs. This particular combination allows us to use the rendering power of hardware-accelerated OpenGL with the various amenities provided by SDL, and it is an excellent platform for developing games. Loki Software has successfully used SDL and OpenGL to port several commercial games to Linux, including Heavy Gear II and Soldier of Fortune.

For more information on OpenGL, see the most recent version of the OpenGL ARB's OpenGL Programming Guide, or visit http://www.opengl.org.


Plib is the collective name for several individual game-programming libraries written by Steve Baker. The purpose of this library is to build a usable game programming environment out of the OpenGL GLUT toolkit (more on GLUT in the next chapter). This collection includes sg ("Simple Geometry", routines for ast 3D math), ssg ("Simple Scene Graph", for manipulating 3D scene data), pui ("Picoscopic User Interface", a simple menu and dialog box system), sl ("Sound library", a portable sound interface), and several other useful components. Plib is available at http://plib.sourceforge.net. These libraries are free software, available under the GNU LGPL.


Glide is 3Dfx's native 3D programming library, designed specifically for 3Dfx graphics chips. It is a much lower-level library than OpenGL, serving mainly as a consistent interface for all video cards based on 3Dfx chipsets. Since 3Dfx no longer has a virtual monopoly in the 3D accelerator business, Glide has lost a certain amount of popularity recently. With the advent of accelerated OpenGL under Linux, there are very few good reasons to use Glide for new game projects, and now that 3Dfx is out of business it's even less of an issue. It is mentioned here only because it has been an influential API during the past few years.


Some game programmers eschew all of these "programmer-friendly" libraries in favor of using the X Window System directly (via the native Xlib API). While experienced programmers may achieve small performance gains this way, they do so at the expense of portability and simplicity.

Xlib is not particularly difficult to use, but it is intended as a base for constructing other toolkits, rather than as a library for writing actual applications. Xlib is a bit too verbose for my taste, but you might find it enjoyable. If you've ever written an application with the Win32 API, you have a good idea of what Xlib programming is like, except that in most cases Xlib requires even more library calls to get anything done. Remember that toolkits such as SDL and ClanLib already use a number of Xlib's tricks to achieve their level of performance, and if you code for Xlib directly you'll be duplicating this work.

If you're interested in learning Xlib (perhaps not a bad exercise, whether or not you actually intend to use it), you'll want to get one or two of the books from the official X Window System documentation series. See the Bibliography for more info.

Graphics APIs  << Page 2 of 6  >>