LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/Linux-Gamers-HOWTO.sgml

3043 lines
144 KiB
Plaintext
Raw Blame History

<!-- -*- fill-column: 100; tab-width: 3; -*- -->
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN">
<!-- Conventions:
2 spaces per indent level
4 spaces from left edge for <screen> environment
5 newlines between level 1 sections.
3 newlines between level 2 sections.
Capitalization: nVidia, Win4Lin
100 characters per line
Problems:
&ldquo; and &rdquo; aren't yielding `` and ''.
-->
<!-- TODO
1. Panzer leader port: http://lgames.sourceforge.net/index.php
2. LBA port: http://www.yaz0r.net/
3. Add "blitting" and "blit" in video card terminology
4. Try to make it more clear that I want people to send info and interact with me.
5. Ultima: http://www.peroxide.dk/ultima/
6. Add X Strike Force to "XFree86 and You". (is this dead?)
-->
<article>
<articleinfo>
<title>The Linux Gamers' HOWTO</title>
<titleabbrev>LG-HOWTO</titleabbrev>
<author>
<personname>
<firstname>Peter</firstname>
<othername role="middle">Jay</othername>
<surname>Salzman</surname>
</personname>
<email>p(at)dirac(dot)org</email>
</author>
<author>
<personname>
<firstname>Fr&eacute;d&eacute;ric</firstname>
<surname>Delanoy</surname>
</personname>
</author>
<!-- year-month-day -->
<pubdate>2004-11-13 v.1.0.6</pubdate>
<copyright>
<year>2001</year>
<year>2002</year>
<holder>Peter Jay Salzman</holder>
</copyright>
<copyright>
<year>2003</year>
<year>2004</year>
<holder>Peter Jay Salzman</holder>
<holder>Fr&eacute;d&eacute;ric Delanoy</holder>
</copyright>
<legalnotice>
<para>
<email>p(at)dirac(dot)org</email> /
<ulink url="http://www.dirac.org/p"></ulink>.
</para>
<para>
Distributed subject to the Open Software License, ver 1.1
</para>
</legalnotice>
<abstract> <title>Abstract</title>
<para>The same questions get asked repeatedly on Linux related mailing lists and news groups.
Many of them arise because people don't know as much as they should about how things "work" on
Linux, at least, as far as games go. Gaming can be a tough pursuit; it requires knowledge from
an incredibly vast range of topics from compilers to libraries to system administration to
networking to XFree86 administration ... you get the picture. Every aspect of your computer
plays a role in gaming. It's a demanding topic, but this fact is shadowed by the primary goal
of gaming: to have fun and blow off some steam.</para>
<para>This document is a stepping stone to get the most common problems resolved and to give
people the knowledge to begin thinking intelligently about what is going on with their games.
Just as with anything else on Linux, you need to know a little more about what's going on behind
the scenes with your system to be able to keep your games healthy or to diagnose and fix them
when they're not.</para>
</abstract>
</articleinfo>
<sect1 id="administrata"><title>Administra</title>
<para>If you have ideas, corrections or questions relating to this HOWTO, please email me. By
receiving feedback on this howto (even if I don't have the time to answer), you make me feel like
I'm doing something useful. In turn, it motivates me to write more and add to this document. You
can reach me at <email>p(at)dirac(dot)org</email>. My web page is <ulink
url="http://www.dirac.org/p"></ulink> and my Linux pages are at <ulink
url="http://www.dirac.org/linux"></ulink>. Please do send comments and suggestions for this
howto. Even if I don't take your suggestions, your input is graciously received.</para>
<para>I assume a working knowledge of Linux, so I use some topics like runlevels and modules
without defining them. If there are enough questions (or even protests) I'll add more basic
information to this document.</para>
<sect2 id="authorship"><title>Authorship and Copyright</title>
<para>This document is copyright (c) 2001-2002 Peter Jay Salzman, <email>p(at)dirac(dot)org</email>;
2003-2004 Peter Jay Salzman and Fr&eacute;d&eacute;ric Delanoy. Permission is granted to copy,
distribute and/or modify this document under the terms of the Open Software License, Version
1.1, except for the provisions I list in the next paragraph. I hate HOWTO's that include the
license; it's a tree killer. You can read the OSL at <ulink
url="http://opensource.org/licenses/osl-1.1.txt"></ulink>.</para>
<para>If you want to create a derivative work or publish this HOWTO for commercial purposes, I
would appreciate it if you contact me first. This will give me a chance to give you the most
recent version. I'd also appreciate either a copy of whatever it is you're doing or a
spinach, garlic, mushroom, feta cheese and artichoke heart pizza.</para>
</sect2>
<sect2 id="acknowledgements"><title>Acknowledgements</title>
<para>Thanks goes out to these people for extensive comments, corrections, and diffs. Their
effort is above and beyond the call of duty:</para>
<para>Fr&eacute;d&eacute;ric Delanoy, Moritz Muehlenhoff
<email>jmm(at)Informatik(dot)uni-bremen(dot)de</email>, Mike Phillips, Ioan Rogers
<email>buck(at)aiur(dot)co(dot)uk</email></para>
<para>I would also like to thank the following people for sending in comments and corrections.
Without their help, there would be more typos and mistakes than you could shake a stick
at:</para>
<para>Michael McDonnell</para>
</sect2>
<sect2 id="version"><title>Latest Versions and Translations</title>
<para>The latest version can be found at <ulink
url="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lgh/LG-HOWTO"></ulink> or <ulink
url="http://www.dirac.org/linux/writing"></ulink>, but this is my own personal working copy.
The version at my personal web site might be broken if I'm working on the HOWTO. The version
at sourceforge is bleeding edge but guaranteed to be not broken, however it may have glitches,
like unfinished paragraphs. :)</para>
<para>The most recent stable version can be found at <ulink
url="http://www.tldp.org"></ulink>.</para>
<sect3><title>Russian</title>
<para>Dmitry Samoyloff <email>dsamoyloff(at)yandex(dot)ru</email> is the maintainer of the
Russian translation. The most recent version can be found at <ulink
url="http://www.dirac.org/linux/writing"></ulink>.</para>
</sect3>
<sect3><title>Hungarian</title>
<para>L<>szl<7A> Daczi <email>dacas(at)korhaz(dot)rethy(dot)hu</email>, the Hungarian LDP
coordinator, announced that a Hungarian translation was produced by Szilard Ivan, and is
available at <ulink url="http://tldp.fsf.hu/HOWTO/Linux-Gamers-HOWTO-hu"
>http://tldp.fsf.hu/HOWTO/Linux-Gamers-HOWTO-hu</ulink>.
</sect3>
</sect2>
</sect1>
<sect1 id="definitions"><title>Definitions: Types Of Games</title>
<para>Not everyone knows the different types of games that are out there, so in an effort to form
a common language that we can all use, I'll run through each game type and provide a very brief
history.</para>
<sect2 id="arcade"><title>Arcade style</title>
<para>Although arcade games had their heydey in the 80's, they are nonetheless very popular.
Nothing will ever replace walking into a dark, crowded and noisy arcade gallery, popping a
quarter into your favorite machine and playing an old fashioned game of Space Invaders.
Arcade style games attempt to simulate the arcade games themselves. There is such a vast
number of these things that it's nearly impossible to enumerate them all, but they include
clones of Asteroids, Space Invaders, Pac-Man, Missile Command and Galaxian.</para>
</sect2>
<sect2 id="cardboard"><title>Card, logic and board games</title>
<para>Computer based card games simulate a card game like poker or solitaire. The program can
simulate your opponent(s).</para>
<para>Logic games usually simulate some well known logic puzzle like Master Mind or the game
where you have put sliding numbered tiles in order inside a box.</para>
<para>Computer based board games simulate some kind of board game you'd play on a table top
with friends, like monopoly, Mille Bourne, chess or checkers. The program can simulate your
opponent.</para>
</sect2>
<sect2 id="interactivefiction"><title>Text Adventure (aka Interactive Fiction)</title>
<para>Once upon a time, when Apple ][, Commodore, and Atari ruled the world, text adventures
were the game of choice of `intelligent folk'. You are given a scenario and can interact with
the world you're placed in:</para>
<screen>
You are in a room. It is pitch dark and you're likely to be eaten by a grue.
> Light lantern with match.
You light the lantern. This room appears to be a kitchen. There's a table with a
book in the center. You also see an oven, refrigerator and a door leading east.
> Open the oven.
In the oven you see a brown paper bag.
> Take the bag. Open the bag. Close the oven.
Inside the bag is a some garlic and a cheese sandwich. The oven door is now closed.
</screen>
<para>Back then, text adventures were self contained executables on a disk or casette. These
days there's usually a data file and an interpreter. The interpreter reads data files and
provides the gaming interface. The data files are the actual game itself, similar to the
relationship between first person shooters (<xref linkend="fps">) and <filename
class="extension">wad</filename> files.</para>
<para>The first adventure game was Adventure (actually &ldquo;ADVENT&rdquo;, written on a
PDP-1 in 1972). You can play Adventure yourself (actually, a descendent); it comes with
&ldquo;bsd games&rdquo; on most Linux distros. Text adventures became popularized by Scott
Adams (<xref linkend="scottadams">) and reached their height of popularity in the late 80's
with Infocom (<xref linkend="infocom">) which are also playable under Linux.</para>
<para>As computer graphics became easier and more powerful, text adventures gave rise to
graphic adventures. The death of commercial interactive fiction more or less coincided with the
bankruptcy of Infocom.</para>
</sect2>
<sect2 id="graphicaladventure"><title>Graphical Adventures</title>
<para>Graphical adventures are, at heart, text adventures on steroids. The degree to which
they use graphics varies widely. Back in the 80's, they were little more than text adventures
which showed a screen of static graphics. When you picked up an item, the background would be
redrawn without the item appearing. The canonical example would be the so-called `Hi-Res
Adventures' like The Wizard And The Princess. Later on, the sophisticated graphical
adventures had your character roaming around the screen, and you could even use a mouse, but
the interface remained purely text.</para>
<para>Next there are the `point and click adventures' which basically have no text interface
at all, and often have dynamic graphics, like a cat wandering around the room while you're
deciding what to do next. In these games, you point at an object (say, a book) and can choose
from a pull-down list of functions. Kind of like object oriented adventuring. :) There
aren't many graphical adventures written natively for Linux. The only one I can think of is
Hopkins FBI (which happens to be my favorite game for Linux).</para>
</sect2>
<sect2><title>Simulation (aka Sims)</title>
<para>Simulations strive to immerse the player behind the controls of something they normally
wouldn't have access to. This could be something real like a fighter jet or something
imaginary like a mechanized warrior combat unit. In either case, sims strive for
realism.</para>
<para>Some sims have little or no strategy. They simply put you in a cockpit to give you the
thrill of piloting a plane. Some are considerably complex, and there's often a fine line
between sims and strats (<xref linkend="strategy">). A good example would be Heavy Gear III
or Flight Gear. These days sims and strats are nearly indistinguishable, but a long time ago,
sims were real time while strats were turn based. This is awkward for modern day use, since a
game like Warcraft which everyone knows as a strat, would be a sim by definition.</para>
</sect2>
<sect2 id="strategy"><title>Strategy (aka Strats)</title>
<para>Strategy games have their roots in old Avalon type board games like Panzer Leader and
old war strategy games published by SSI. Generally, they simulate some kind of scenario. The
scenario can be peaceful, like running a successful city (SimCity), or not, like illegal
drug selling operation (DrugWars) or an all-out war strategy game like Myth II. The types
of games usually take a long time to complete and require a lot of brainpower.</para>
<para>Strats can be further divided into two classes: real time and turn based. Real time
strats are based on the concept of you-snooze-you-lose. For example, you're managing a city
and a fire erupts somewhere. The more time it takes for you mobilize the fire fighters, the
more damage the fire does. Turn based strats are more like chess---the computer takes a turn
and then the player takes a turn.</para>
</sect2>
<sect2 id="fps"><title>First Person Shooter (aka FPS)</title>
<para>What light through yonder window breaks? It must be the flash of the double barreled
shotgun! We have a long and twisted history with FPS games which started when id Software
open sourced code for Doom. The code base has forked and merged numerous times. Other
previously closed engines opened up, many engines are playable via emulators, many commercial
FPS games were released for Linux and there are quite a number of FPS engines which started
life as open source projects. Although you may not be able to play your
<emphasis>favorite</emphasis> FPS under Linux (Half-Life plays great under winex) Linux
definitely has no deficiency here!</para>
<para>First person shooters are characterized by two things. First, you pretty much blow up
everything you see. Second, the action takes place in first person. That is, through the
eyes of the character who's doing all the shooting. You may even see your hands or weapon at
the bottom of the screen. They can be set in fantasy (Hexen), science fiction (Quake II),
present day `real world' (Soldier Of Fortune) and many other settings.</para>
<para>Like text adventures, FPS fit the engine/datafile format. The engine refers to the
actual game itself (Doom, Quake, Heretic2) and plays out the maps and bad guys outlined by the
datafile (<filename>doom2.wad</filename>, <filename>pak0.pak</filename>, etc). Many FPS games
allow people to write their own non-commercial datafile. There are hundreds, even thousands
of non-commercial Doom datafiles that you can download for free off the net. Often, companies
release their engines to the open source community so we can hack and improve them. However,
the original data files are kept proprietary. To this day, you still have to purchase
<filename>doom.wad</filename>.</para>
</sect2>
<sect2><title>Side Scrollers</title>
<para>Side scrollers are similar to FPS but you view your character as a 2D figure who runs
around various screens shooting at things or performing tasks. Examples would be Abuse for
Linux and the original Duke Nukem. They don't necessarily have to be violent, like
<application>xscavenger</application>, a clone of the old 8-bit game Lode Runner.</para>
</sect2>
<sect2><title>Third Person Shooters</title>
<para>Similar to FPS, but you view your character in third person and in 3D. On modern third
person shooters you can usually do some really kick-butt maneuvers like Jackie Chan style back
flips and side rolls. The canonical example would be Tomb Raider. On the Linux platform, we
have Heretic 2 and Heavy Metal FAKK2.</para>
</sect2>
<sect2 id="rpg"><title>Role Playing Game (aka RPG)</title>
<para>Anyone who has played games like Dungeons & Dragons or Call of Cthulhu knows exactly
what an RPG is. You play a character, sometimes more than one, characterized by traits (eg
strength, dexterity), skills (eg explosives, basket weaving, mechanics) and properties
(levels, cash). As you play, the character becomes more powerful and the game adjusts itself
accordingly, so instead of fighting orcs, at high levels you start fighting black dragons.
The rewards increase correspondingly. At low levels you might get some gold pieces as a
reward for winning a battle. At high levels, you might get a magic sword or a kick-butt
assault rifle.</para>
<para>RPG's generally have a quest with a well defined ending. In nethack you need to
retrieve the amulet of Yendor for your god. In Ultima II, you destroy the evil sorceress
Minax. At some point, your character becomes powerful enough that you can `go for it' and try
to complete the quest.</para>
<para>While the insanely popular Ultima series, written by Richard Garriot (aka Lord British)
for Origin, was not the first RPG, it popularized and propelled the RPG genre into mainstream.
Ultima I was released in 1987 and was the game that launched 9 (depending on how you want to
count them) very popular sequels, finishing with Ultima IX: Ascension. You can play Ultima
VII under Linux with Exult (<xref linkend="exult">).</para>
<para>The canonical RPG on Linux is Rogue (the ncurses library started life as a screen
handling routine for Rogue!) and it has infinite variants like Zangband and Nethack (which has
many variants itself). Some RPG's are quite complicated and great feats of programming.
There seems to be a deficiency of commercial RPGs for Linux. Not counting the rogue variants,
there's also a deficiency of open source RPGs too.</para>
</sect2>
</sect1>
<sect1><title>Libraries</title>
<para>We'll run through the different gaming libraries you'll see under Linux.</para>
<sect2 id="glide2"><title>What is Glide2?</title>
<para>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.</para>
<para>A program can only use the special hardware accelerated features of these cards by using
the Glide2 library in one of two ways:</para>
<itemizedlist>
<listitem><para>directly written using Glide2 (Myth II, Descent III)</para></listitem>
<listitem><para>indirectly using Mesa built with a Glide2 backend to simulate OpenGL (Rune,
Unreal Tournament)</para></listitem>
</itemizedlist>
<para>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.</para>
<para>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 <filename>/dev/3dfx</filename>) allows Glide2 graphical
hardware acceleration for non-root users of non-setuid applications.</para>
<para>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.</para>
</sect2>
<sect2 id="glide3"><title>What is Glide3?</title>
<para>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.</para>
<para>When you use a Voodoo III, IV or V under XFree86 4.x, you want to use a version of Mesa
(see <xref linkend="mesa">) which was compiled to use Glide3 as a backend to ensure hardware
accelerated OpenGL on your system.</para>
</sect2>
<sect2 id="opengl"><title>What is OpenGL?</title>
<para>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.</para>
<para>There are 3 canonical parts to OpenGL:</para>
<itemizedlist>
<listitem><para>GL: The OpenGL core calls</para></listitem>
<listitem><para>GLU: The utility calls</para></listitem>
<listitem><para>GLUT: OS independent window event (mouse, keyboard, etc.)
handler.</para></listitem>
</itemizedlist>
<para>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.</para>
<para>OpenGL is the open source equivalent to Direct3D, a component of DirectX (<xref
linkend="directx">). 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.</para>
</sect2>
<sect2 id="mesa"><title>What is Mesa?</title>
<para>Mesa &lt;<ulink url="http://www.mesa3d.org"></ulink>&gt; 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.</para>
<para>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.</para>
</sect2>
<sect2><title>What is DRI?</title>
<para>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 &lt;<ulink url="http://www.dri.sourceforge.net"></ulink>&gt;. DRI allows X
clients to write 3D rendering information directly to the video card in a safe and cooperative
manner.</para>
<para>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.</para>
<itemizedlist>
<listitem><para>Vertex data doesn't have to be encoded/decoded via GLX.</para></listitem>
<listitem><para>Graphics data isn't sent over a socket to the X server.</para></listitem>
<listitem><para>On uni-processor machines the CPU doesn't have to change context between
XFree86 and its client to render the graphics.</para></listitem>
</itemizedlist>
</sect2>
<sect2><title>What is GLX?</title>
<para>GLX is the X extension used by OpenGL programs, it is the glue between the platform
independent OpenGL and platform dependent X.</para>
</sect2>
<sect2><title>What is Utah GLX?</title>
<para>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.</para>
</sect2>
<sect2 id="xlib"><title>What is xlib?</title>
<para>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.</para>
<para>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 (<xref linkend="sdl">) for 2D graphics,
OpenGL (<xref linkend="opengl">) for 3D graphics and widget sets (<xref linkend="widgetset">)
for widgets within windows which hide the details of different aspects of xlib
programming.</para>
<para>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.</para>
</sect2>
<sect2 id="widgetset"><title>What is a widget set?</title>
<para>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.</para>
</sect2>
<sect2 id="sdl"><title>What is SDL (Simple DirectMedia Layer)?</title>
<para>SDL &lt;<ulink url="http://www.libsdl.org"></ulink>&gt; 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 (<xref linkend="xlib">), SDL is very suited for game programming.</para>
<para>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.</para>
<para>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.</para>
</sect2>
<!-- sent an email 12 june 2002 about comments/suggestions. No reply so far. -->
<sect2 id="ggi"><title>What is GGI?</title>
<para>GGI &lt;<ulink url="http://www.ggi-project.org"></ulink>&gt; 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.</para>
<para>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 (<xref linkend="svgalib">) using LibGGI. SDL
(<xref linkend="sdl">) and clanlib (<xref linkend="clanlib">) 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.</para>
<para>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.</para>
</sect2>
<!-- sent an email 12 june 2002 about comments/suggestions -->
<sect2 id="svgalib"><title>What is SVGAlib? Frame buffer? Console?</title>
<para>The console is the dark non-graphical screen you look at when your computer first boots
up (and you don't have <application>xdm</application> or <application>gdm</application>
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&mdash;we will discuss the two most common ways to achieve
this.</para>
<para>SVGAlib is a graphics library that lets you draw graphics on the console. There are
many graphical applications and games that use SVGAlib like <application>zgv</application> (a
console graphical image viewer), <application>prboom</application> and
<application>hhexen</application>. 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&ndash;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.</para>
<para>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.</para>
</sect2>
<sect2 id="openal"><title>What is OpenAL?</title>
<para>OpenAL &lt;<ulink url="http://www.openal.org"></ulink>&gt; 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 (<xref linkend="opengl">). 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</para>
<para>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
<ulink url="http://www.lost.org.uk"></ulink> that provide hardware acceleration and decent
surround support.</para>
</sect2>
<sect2 id="directx"><title>What is DirectX?</title>
<para>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:</para>
<variablelist>
<varlistentry><term>DirectDraw</term>
<listitem><para>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.</para></listitem></varlistentry>
<varlistentry><term>Direct3D (D3D)</term>
<listitem><para>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.</para></listitem></varlistentry>
<varlistentry><term>DirectAudio</term>
<listitem><para>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.</para></listitem></varlistentry>
<varlistentry><term>DirectInput</term>
<listitem><para>DirectInput gives support for gaming input devices such as
joysticks.</para></listitem></varlistentry>
<varlistentry><term>DirectPlay</term>
<listitem><para>DirectPlay gives support for simplified networking for multiplayer
gaming.</para> </listitem></varlistentry>
<varlistentry><term>DirectShow</term>
<listitem><para>DirectShow provides support for movie files like AVI and MPG. It was a
separate API from DirectX, but was integrated with DirectX
8.</para></listitem></varlistentry>
<varlistentry><term>DirectSetup</term>
<listitem><para>This API provides a way to install DirectX from within an application to
simplify game installation.</para></listitem></varlistentry>
</variablelist>
<para>Depending on the version of DirectX you're talking about, DirectX support in winex
(<xref linkend="winex">) ranges from well supported to "kind of" supported. It's poorly
supported by wine (<xref linkend="wine">), barely supported by vmware (<xref
linkend="vmware">) and unsupported by Win4Lin (<xref linkend="win4lin">).</para>
<para>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.</para>
<para>A company named realtechVR started an open source project, DirectX Port, &lt;<ulink
url="http://www.v3x.net/directx"></ulink>&gt; 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
&lt;<ulink url="http://sourceforge.net/projects/dxglwrap"></ulink>&gt;.</para>
</sect2>
<sect2 id="clanlib"><title>Clanlib</title>
<para>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.</para>
</sect2>
</sect1>
<sect1><title>XFree86 and You</title>
<para>If you're going to game under X, it's crucial that you know a bit about X. The "X Window
User HOWTO", and especially "man XF86Config" are <emphasis>required</emphasis> reading. Don't
short change yourself; read them. They have an extremely high "information to space" ratio. Many
problems can be fixed easily if you know your way around <filename>XF86Config</filename> (or
<filename>XF86Config-4</filename>).</para>
<sect2><title>Getting information about your X system</title>
<para>Whether you're trying to diagnose an X problem or requesting help from a mailing list or
Usenet newsgroup, you'll want to have as much information available as possible. These are a
set of tools you can use to obtain that information.</para>
<sect3><title>Probeonly</title>
<para>One of the best diagnostic tools and sources of information about your X system is
<command>probeonly</command> output. To use it, kill X if it's already running and from a
console, type:</para>
<screen>
X -probeonly 2> X.out
</screen>
<para>Yes, that's a single dash; so much for standards. The output of X goes to stderr,
so we have to redirect stderr with "2>" to a file named <filename>X.out</filename>. This
file will have almost everything there is to know about your X system. It's crucial that
you know the difference between the various markers you'll see in probeonly output:</para>
<screen>
(--) probed (**) from config file (==) default setting
(++) from command line (!!) notice (II) informational
(WW) warning (EE) error (??) unknown.
</screen>
<para>Here's an example of some information I gleaned from my output:</para>
<para>I'm running at 16 bpp color:</para>
<screen>
(**) TDFX(0): Depth 16, (--) framebuffer bpp 16
</screen>
<para>X has detected what my videocard chipset and videoram are:</para>
<screen>
(--) Chipset 3dfx Voodoo5 found
(--) TDFX(0): VideoRAM: 32768 kByte Mapping 65536 kByte
</screen>
</sect3>
<!-- here -->
<sect3><title>Getting info about your setup: xvidtune</title>
<para><application>xvidtune</application> is your friend when your X screen is shifted a
little bit too far to the right, or if the vertical length is too small to fit on your
monitor. However, it's a great diagnostic tool also. It'll give you:</para>
<itemizedlist>
<listitem><para>the hsync/vsync range specified in your XF86Config file</para></listitem>
<listitem><para>the 4 horizontal and 4 vertical numbers which defines your videomode (the
1st horizontal/vertical numbers gives the screen resolution). These 8 numbers will tell you
which modeline your X uses. See the XFree86 Video Timings Howto for more information. Note
that explicit modelines are no longer necessary, since XFree 4.0.1 and up computes
modetimings automatically based on your monitor's and video card's capabilities. However,
there may be times when you'll want to play around with mode timings, like for weird
hardware or if want to tweak your display.</para></listitem>
<listitem><para>the "dot clock" your videocard is running at.</para></listitem>
</itemizedlist>
</sect3>
<sect3><title>Getting info about your setup: xwininfo</title>
<para><command>xwininfo</command> tells you all sorts of information about X windows. And
actually, your "background" or "root" window is considered a window too. So when xwininfo
asks you to click on the window you want the information on, click on your background.
It'll tell you things like screen and window resolution, color depth, window gravity state
(which gives a hint to the window manager about where to place new windows), backing store
usage and more.</para>
</sect3>
<sect3><title>Other sources of information</title>
<para><command>xdpyinfo</command> gives cool stuff, like X version and loaded extensions
(invaluable when trying to see what's missing, like GLX, DRI, XFree86-VidMode, etc.).</para>
</sect3>
<sect3><title>Getting information about your 3D system</title>
<para><command>glxinfo</command> gives lots of useful information about OpenGL like whether
direct rendering enabled, the currently installed versions of glx and mesa, vendor/renderer
strings, the GL library files being used and more.</para>
</sect3>
</sect2>
<sect2 id="nowm"><title>Playing Games In X Without a Window Manager</title>
<para>When playing a game under X, you should consider starting X without a window manager
(WM). Heavyweight WMs, like Enlightenment, or full-blown desktop environments like GNOME or
KDE, may produce a noticeable slow down. Even lightweight WMs, like twm, rob your CPU of
clock cycles (and in twm's case, even full screen games will have a frame around the window).
Running a game without a WM or DE depends on how you access X. If you usually log in to a
Virtual Console and start X with &quot;startx&quot; try the following: </para>
<para>Modify <filename>~/.xinitrc</filename>, which tells X what to run upon starting. Here
is what my .xinitrc looks like:</para>
<screen>
#quake3 +set r_gldriver libGR.so.1
#exec ut
#lsdldoom -server 2
#exec tribes2
exec /usr/bin/enlightenment
</screen>
<para>You'll usually see a window or desktop manager being executed from this file (GNOME or
KDE). Comment out the lines containing the WM or desktop manager with a pound sign (#) and
place your game on a new line with any command line arguments you want to pass. If the game
is not located in your $PATH, give its full path name.</para>
<para>If you log directly into X using gdm, then things are a little different. These
instructions are for gdm 2.4 or greater. They *may* work with kde, but I cannot say for
certain.</para>
<para>First, check your <filename>gdm.conf</filename> (usually in <filename
role="directory">/etc/X11/gdm</filename> or <filename role="directory">/etc/gdm</filename>)
file for a line that says begins "<literal>SessionDesktopDir=blah</literal>". One of the
directories listed as options should be "<filename
role="directory">/usr/share/xsessions</filename>", and is the directory which will be used in
this example. As root, change to the "<filename
role="directory">/usr/share/xsessions</filename>" directory and take a look at its contents.
It should contain some <filename>.desktop</filename> files, each corresponding to an entry
you'll see in gdm's Session menu, e.g <filename>gnome.desktop</filename>,
<filename>enlightenment.destop</filename>. This example will show you how to log in to Doom3.
Copy any of the desktop files to "<filename>doom3.desktop</filename>" and open the new file in
your favourite text editor. The file will be full of alternative languages, so cut out
everything you don't want and make the file look like this:</para>
<screen>
[Desktop Entry]
Encoding=UTF-8
Name=DOOM III
Comment=iD's Doom III
#if game is not in path, remember to put the full path here
Exec=/usr/games/doom3/doom3
# no icon yet, only the top three are currently used
Icon=
Type=Application
</screen>
<para>Save the file and log out of your window manager. At the gdm login screen, you should
now see "<literal>DOOM III</literal>" as an option in "Sessions". Naturally you can add a
.desktop file for each game you have installed</para>
<!--
Add some stuff about adding scripts to launch games so that you can change env vars, use
nVidia-settings, etc.
-->
</sect2>
</sect1>
<sect1><title>Various Topics</title>
<sect2 id="mtrr"><title>Memory Type Range Registers</title>
<para>Starting with Pentium class processors and including Athlon, K6-2 and other CPUs, there
are Memory Type Range Registers (MTRR) which control how the processor accesses ranges of memory
locations. Basically, it turns many smaller separate writes to the video card into a single
write (a burst). This increases efficiency in writing to the video card and can speed up your
graphics by 250% or more.</para>
<para>See <filename>/usr/src/linux/Documentation/mtrr.txt</filename> for details. Note that
since this file was written, XFree86 has been patched to automatically detect your video RAM
base address and size and set up the MTRRs.</para>
</sect2>
<sect2 id="milkingperformance"><title>Milking performance from your system for all it's worth</title>
<itemizedlist>
<listitem><para>If for some reason you're using X 3.3, follow the instructions given by
<filename>mtrr.txt</filename> (see <xref linkend="mtrr">) to set up your MTRRs. X 4.0 does this
automatically for you.</para></listitem>
<listitem><para>If you're playing a game under X, don't run a window manager, and
<emphasis>certainly</emphasis> don't run a desktop manager like GNOME or KDE. See <xref linkend="nowm"> for details.</para>
<para>Kill all non-essential processes (you'll have to do this as root) by using the startup
scripts on your system. On Debian, the startup scripts for run-level 2 are located in
/etc/rc2.d/. You can kill a service in an orderly manner by sending its startup script the
`stop' command:</para>
<screen>
# cd /etc/rc2.d
# ./ntpd stop
</screen>
<para>Another (radical) option is to simply put yourself in single-user mode with</para>
<screen>
# telinit 1
</screen>
<para>This will even get rid of getty; your system will only be running whatever is absolutely
crucial to its operation. You'll have something like 10 processes running. The downside is
that you'll have to play the game as root. But your process table will be a ghost town, and all
that extra CPU will go straight to your game.</para></listitem>
</itemizedlist>
</sect2>
<sect2><title>About libraries on Linux</title>
<para>A common problem you'll see in gaming is a library file not being found. They're kind of
mysterious and have funny names, so we'll go over libraries on Linux for a bit. There are two
types of libraries, static and dynamic. When you compile a program, by default,
<command>gcc</command> uses dynamic libraries, but you can make <command>gcc</command> use
static libraries instead by using the <option>-static</option> switch. Unless you plan on
compiling your games from source code, you'll mainly be interested in dynamic libraries.</para>
<sect3><title>Dynamic libraries</title>
<para>Dynamic libraries, also called a &ldquo;shared library&rdquo;, provide object code for
an application while it's running. That is, code gets linked into the executable at run time,
as opposed to compile time. They're analagous to the <literal>.dll</literal>'s used by
Windows. The program responsible for linking code &ldquo;on the fly&rdquo; is called
<command>/etc/ld.so</command>, and the dynamic libraries themselves usually end with
<literal>.so</literal> with a version number, like:</para>
<screen>
/usr/lib/libSDL.so
/lib/libm.so.3
</screen>
<para>When using <command>gcc</command>, you refer to these libraries by shaving off the
strings <literal>lib</literal>, <literal>.so</literal> and all version numbers. So to use
these two libraries, you would pass <command>gcc</command> the <literal>-lSDL -lm</literal>
options. <command>gcc</command> will then `place a memo inside the executable' that says to
look at the files <filename> /usr/lib/libSDL.so</filename> and
<filename>/lib/libm.so.3</filename> whenever an SDL or math function is used.</para>
</sect3>
<sect3><title>Static libraries</title>
<para>In contrast to dynamic libraries which provide code while the application runs, static
libraries contain code which gets linked (inserted) into the program while it's being
compiled. No code gets inserted at run time; the code is completely self-contained. Static
libraries usually end with <literal>.a</literal> followed by a version number, like:</para>
<screen>
/usr/lib/libSDL.a
/usr/lib/libm.a
</screen>
<para>The <literal>.a</literal> files are really an archive of a bunch of
<literal>.o</literal> (object) files archived together, similar to a tar file. You can use
the <command>nm</command> to see what functions a static library contains:</para>
<screen>
% nm /usr/lib/libm.a
...
e_atan2.o:
00000000 T __ieee754_atan2
e_atanh.o:
00000000 T __ieee754_atanh
00000000 r half
00000010 r limit
00000018 r ln2_2
...
</screen>
<para>When using <command>gcc</command>, you refer to these libraries by shaving off the
strings &ldquo;lib&rdquo;, &ldquo;.a&rdquo; and all version numbers. So to use these two
libraries, you would pass <command>gcc</command> the <literal>-lSDL -lm</literal> options.
<command>gcc</command> will then `bolt on' code from <filename
class="libraryfile">/usr/lib/SDL.a</filename> and <filename
class="libraryfile">/usr/lib/libm.a</filename> whenever it sees a math function during the
compilation process.</para>
</sect3>
<sect3><title>How are library files found</title>
<para>If you compile your own games, your biggest problem with libraries will either be that
<command>gcc</command> can't find a static library or perhaps the library doesn't exist on
your system. When playing games from binary, your library woes will be either be that
<command>ld.so</command> can't find the library or the library doesn't exist on your system.
So it makes some sense to talk about how <command>gcc</command> and <command>ld.so</command>
go about finding libraries in the first place.</para>
<para><command>gcc</command> looks for libraries in the ``standard system directories'' plus
any directories you specify with the <option>-L</option> option. You can find what these
standard system directories are with <command>gcc -print-search-dirs</command></para>
<para><command>ld.so</command> looks to a binary hash contained in a file named
<filename>/etc/ld.so.cache</filename> for a list of directories that contain available dynamic
libraries. Since it contains binary data, you cannot modify this file directly. However, the
file is generated from a text file <filename>/etc/ld.so.conf</filename> which you can edit.
This file contains a list of directories that you want <command>ld.so</command> to search for
dynamic libraries. If you want to start putting dynamic libraries in
<filename>/home/joecool/privatelibs</filename>, you'd add this directory to
<filename>/etc/ld.so.conf</filename>. Your change doesn't actually make it into
<filename>/etc/ld.so.cache</filename> until you run <command>ldconfig</command>; once it's
run, <command>ld.so</command> will begin to look for libraries in your private
directory.</para>
<para>Also, even if you just add extra libraries to your system, you must update
<filename>ld.so.cache</filename> to reflect the presence of the new libraries.</para>
</sect3>
<sect3><title>Finding Out What Libraries a Game Depends On</title>
<para>Most commercial Linux games will be dynamically linked against various LGPL libraries,
such as OpenAL or SDL. For these examples, Bioware's NeverWinter Nights &lt;<ulink
url="http://nwn.bioware.com"></ulink>&gt; will be used.</para>
<para>To find out what libraries a game uses, we can use the "<filename>ldd</filename>"
command. Cd to <filename role="directory">/usr/games/nwn</filename>, or wherever you
installed it and take a look at the files. You should see a file called
<filename>nwmain</filename>; this is the actual game binary. Type "<literal>ldd
nwmain</literal>" and you'll see:</para>
<screen>
$ ldd nwmain
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0x40027000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40049000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x4009b000)
libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x40103000)
libmss.so.6 => not found
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x40178000)
libc.so.6 => /lib/libc.so.6 (0x401ff000)
/lib/ld-linux.so.2 (0x40000000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40319000)
libnvidia-tls.so.1 => /usr/lib/libnvidia-tls.so.1 (0x409f1000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x409f3000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40a01000)
libdl.so.2 => /lib/libdl.so.2 (0x40acd000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40ad1000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x40b88000)
libasound.so.2 => /usr/lib/./libasound.so.2 (0x40b90000)
</screen>
<para>ldd shows all the libraries a dynamic executable relies on, and shows you where they
are. It also "pulls in" the dependencies of the dependencies. For instance, while NWN does
not itself depend on <filename role="library">libnvidia-tls.so</filename>, the Nvidia supplied
libGL on my system does.</para>
<para>Missing libraries?</para>
<para>In the example above, we can see that <filename>nwmain</filename> wants <filename
role="library">libmss.so.6</filename>, and the linker cannot find it. Usually, a missing
library is a crash waiting to happen. There is one other thing to consider though: The
majority of games are actually launched by a "wrapper", a shell script that performs some
magic prior to launching the game. In the case of NWN, the wrapper is called
<filename>nwn</filename>. Let's take a look at that now:</para>
<screen>
$ less nwn
#!/bin/sh
# This script runs Neverwinter Nights from the current directory
export SDL_MOUSE_RELATIVE=0
export SDL_VIDEO_X11_DGAMOUSE=0
# If you do not wish to use the SDL library included in the package, remove
# ./lib from LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH
./nwmain $@
</screen>
<para>This script sets up some environment variables, then launches the game binary with
whatever command line options we added. The relevant part here is the environment variable
called "LD_LIBRARY_PATH". This is a way of adding to the linkers search path. Try copying the
line to your shell and seeing what happens when you re-run ldd.</para>
<screen>
$ export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH
$ ldd nwmain
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0x40027000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40049000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x4009b000)
libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x40103000)
libmss.so.6 => ./miles/libmss.so.6 (0x40178000)
libSDL-1.2.so.0 => ./lib/libSDL-1.2.so.0 (0x401ec000)
libc.so.6 => /lib/libc.so.6 (0x4025e000)
/lib/ld-linux.so.2 (0x40000000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40378000)
libnvidia-tls.so.1 => /usr/lib/libnvidia-tls.so.1 (0x40a50000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40a52000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40a60000)
libdl.so.2 => /lib/libdl.so.2 (0x40b2c000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40b30000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x40be7000)
</screen>
<para>As you can see, this gives us slighly different results. The NWN library directories
have been prepended to the search path, so now the linker can find <filename
role="library">libmss.so.6</filename> in the "<filename role="directory">./miles</filename>"
directory, and also finds the local copy of libSDL first, no longer using the system
copy.</para>
<para>There's another benefit of these scripts: they are easily edited to allow you to provide
your own copy of a library. Any game-supplied copy of a library such as OpenAL or SDL is
likely to be compiled for the lowest common denominator, probably i486 or i686. If you have a
Pentium4 or an AthlonXP, you could compile you own version specifically for your processor.
The compiler will try to optimise the resulting binary, giving some increase in performance.
See the homepage for GCC for more information this at <ulink url="http://gcc.gnu.org"> the GCC
site.</ulink></para>
<para>Making NWN use your system copy is easy. It says so in the wrapper script! Remove
"./lib:" from the <literal>LD_LIBRARY_PATH</literal> line, and you're good to go.</para>
<para>Another nice little trick is for games that use OpenAL for their sound output (e.g.
Unreal based games: UT, Postal, Rune, etc.). Since the Open Sound System's (OSS) deprecation
in favour of ALSA, all Linux distributions I've seen now ship with ALSA support as default,
with OSS support actually being supplied via ALSA's compatability modules. The copies of
<filename role="library">openal.so</filename> distributed with games often do NOT support
ALSA, so making the game use a copy compiled yourself will allow you to use ALSA
natively.</para>
</sect3>
</sect2>
</sect1>
<sect1><title>When Bad Things Happen To Good People</title>
<para>Of course we can't cover every Bad Thing that happens, but I'll outline some items of common
sense.</para>
<para>There are two types of bad things: random and repeatable. It's very difficult to diagnose
or fix random problems that you don't have any control over when they happen or not. However, if
the problem is repeatable "it happens when I press the left arrow key twice", then you're in
business.</para>
<sect2><title>RTFM!</title>
<para>Read the friendly manual. The `manual' can take on a few forms. For open source games
there's the readme files that come with the game. Commercial games will have a printed manual
and maybe some readme files on the CD the game came on. Don't forget to browse the CD your
game came on for helpful tips and advice.</para>
<para>Don't forget the game's website. The game's author has probably seen people with your
exact same problem many times over and might put information specific to that game on the
website. A prime example of this is Loki Software's online FAQs located at <ulink
url="http://faqs.lokigames.com"></ulink>.</para>
</sect2>
<sect2><title>Look For Updates and Patches</title>
<para>If you're playing an open source game that you compiled, make sure you have the newest
version by checking the game's website. If your game came from a distro make sure there's not
an update rpm/deb for the game.</para>
<para>Commercial game companies like Loki release patches for their games. Often a game will
have MANY patches (Myth2) and some games are unplayable without them (Heretic2). Check the
game's website for patches whether you have a problem running the game or not; there may be an
update for a security problem that you may not even be aware of.</para>
<para>By the way, Loki now has a utility that searches for Loki Software on your hard drive
and automatically updates them. Check out <ulink
url="http://updates.lokigames.com"></ulink>.</para>
</sect2>
<sect2><title>Newsgroups</title>
<para>If you don't know what netnews (Usenet) is, then this is definitely worth 30 minutes of
your time to learn about. Install a newsreader. I prefer console tools more, so I use tin,
but slrn is also popular. Netscape has a nice graphical "point and click" newsreader
too.</para>
<para>For instance, I can browse Loki Software's news server with <command>tin -g
news.lokigames.com</command>. You can also specify which news server to use using the
<varname>$NNTP</varname> environment variable or with the file
<filename>/etc/nntpserver</filename>.</para>
</sect2>
<sect2><title>Google Group Search</title>
<para>Every post made to Usenet gets archived at Google's database at <ulink
url="http://groups.google.com"></ulink>. This archive used to be at <ulink
url="http://www.deja.com"></ulink>, but was bought by Google. Many people still know the
archive as "deja".</para>
<para>It's almost certain that whatever problem you have with Linux, gaming related or not,
has already been asked about and answered on Usenet. Not once, not twice, but many times
over. If you don't understand the first response you see (or if it doesn't work), then try
one of the other many replies. If the page is not in a language you can understand, there are
many translation sites which will convert the text into whatever language you like, including
<ulink url="http://www.freetranslation.com"></ulink> and <ulink
url="http://translation.lycos.com"></ulink>. My web browser of choice, Opera (available at
<ulink url="http://www.opera.com"></ulink>) allows you to use the right mouse button to select
a portion of text and left click the selection to translate it into another language. Very
useful when a Google group search yields a page in German which looks useful and my wife (who
reads German well) isn't around.</para>
<para>The Google group search has a basic and advanced search page. Don't bother with the
simple search. The advanced search is at <ulink
url="http://groups.google.com/advanced_group_search"></ulink>.</para>
<para>It's easy to use. For example, if my problem was that Quake III crashed everytime Lucy
jumps, I would enter "linux quake3 crash lucy jumps" in the "Find messages with all of the
words" textbox.</para>
<para>There are fields for which newsgroup you want to narrow your search to. Take the time
to read and understand what each field means. I promise you. You won't be disappointed with
this service. Use it, and you'll be a much happier person. Do note that they don't archive
private newsgroups, like Loki Software's news server. However, so many people use Usenet, it
almost doesn't matter.</para>
</sect2>
<sect2><title>Debugging: call traces and core files</title>
<para>This is generally not something you'll do for commercial games. For open source games,
you can help the author by giving a corefile or stack trace. Very quickly, a core file (aka
core dump) is a file that holds the "state" of the program at the moment it crashes. It holds
valuable clues for the programmer to the nature of the crash -- what caused it and what the
program was doing when it happened. If you want to learn more about core files, I have a
great gdb tutorial at <ulink url="http://www.dirac.org/linux"></ulink>.</para>
<para>At the *very* least, the author will be interested in the call stack when the game
crashed. Here is how you can get the call stack at barf-time:</para>
<para>Sometimes distros set up their OS so that core files (which are mainly useful to
programmers) aren't generated. The first step is to make your system allow unlimited
coresizes:</para>
<screen>
ulimit -c unlimited
</screen>
<para>You will now have to recompile the program and pass the -g option to gcc (explaining
this is beyond the scope of this document). Now, run the game and do whatever you did to
crash the program and dump a core again. Run the debugger with the core file as the 2nd
argument:</para>
<screen>
$ gdb CoolGameExecutable core
</screen>
<para>And at the (gdb) prompt, type "backtrace". You'll see something like:</para>
<screen>
#0 printf (format=0x80484a4 "z is %d.\n") at printf.c:30
#1 0x8048431 in display (z=5) at try1.c:11
#2 0x8048406 in main () at try1.c:6
</screen>
<para>It may be quite long, but use your mouse to cut and paste this information into a file.
Email the author and tell him:</para>
<orderedlist numeration="arabic">
<listitem><para>The game's name</para></listitem>
<listitem><para>Any error message that appears on the screen when the game
crashes.</para></listitem>
<listitem><para>What causes the crash and whether it's a repeatable crash or
not.</para></listitem>
<listitem><para>The call stack</para></listitem>
</orderedlist>
<para>If you have good bandwidth, ask the author if he would like the core file that his
program dumped. If he says yes, then send it. Remember to ask first, because core files can
get very, very big.</para>
</sect2>
<sect2 id="savedgames"><title>Saved Games</title>
<para>If your game allows for saved games, then sending the author a copy of the saved game is
useful because it helps the tech reproduce whatever is going wrong. For commercial games,
this option is more fruitful than sending a core file or call stack since commercial games
can't be recompiled to include debugging information. You should definitely ask before
sending a save game file because they tend to be long, but gaming companies usually have lots
of bandwidth. Mike Phillips (formerly of Loki Software) mentioned that sending in saved games
to Loki is definitely a good thing.</para>
<para>Needless to say, this only applies if your game crashes reproducably at a certain point.
If the game segfaults every time you run it, or is incredibly slow, a saved game file won't be
of much help.</para>
</sect2>
<sect2><title>What to do when a file or library isn't being found (better living through
strace)</title>
<para>Sometimes you'll see error messages that indicate a file wasn't found. The file could
be a library:</para>
<screen>
% ./exult
./exult: error while loading shared library: libSDL-1.2.so.0: cannot load shared object
file: No such file or directory
</screen>
<para>or it could be some kind of data file, like a <filename class="extension">wad</filename>
or <filename class="extension">map</filename> file:</para>
<screen>
% qf-client-sdl
IP address 192.168.0.2:27001 UDP Initialize Error: W_LoadWadFile: couldn't load gfx.wad
</screen>
<para>Suppose <filename>gfx.wad</filename> is already on my system, but couldn't be found
because it isn't in the right directory. Then where IS the right directory? Wouldn't it be
helpful to know where these programs looked for the missing files?</para>
<para>This is where strace shines. strace tells you what system calls are being made, with
what arguments, and what their return values are. In my `Kernel Module Programming Guide'
(due to be released to LDP soon), I outline everything you may want to know about strace. But
here's a brief outline using the canonical example of what strace looks like. Give the
command:</para>
<screen>
strace -o ./LS_LOG /bin/ls
</screen>
<para>The -o option sends strace's output to a file; here, LS_LOG. The last argument to
strace is the program we're inspecting, here, "ls". Look at the contents of LS_LOG. Pretty
impressive, eh? Here is a typical line:</para>
<screen>
open(".", O_RDONLY|O_NONBLOCK|0x18000) = 4
</screen>
<para>We used the <function>open()</function> system call to open "." with various arguments,
and the return value of the call is <returnvalue>4</returnvalue>. What does this have to do
with files not being found?</para>
<para>Suppose I want to watch the StateOfMind demo because I can't ever seem to get enough of
it. One day I try to run it and something bad happens:</para>
<screen>
% ./mind.i86_linux.glibc2.1
Loading & massaging...
Error:Can't open data file 'mind.dat'.
</screen>
<para>Let's use strace to find out where the program was looking for the data file.</para>
<screen>
strace ./mind.i86_linux.glibc2.1 2> ./StateOfMind_LOG
</screen>
<para>Pulling out vim and searching for all occurrences of <filename>mind.dat</filename>, I
find the following lines:</para>
<screen>
open("/usr/share/mind.dat",O_RDONLY) = -1 ENOENT (No such file)
write(2, "Error:", 6Error:) = 6
write(2, "Can\'t open data file \'mind.dat\'."..., ) = 33
</screen>
<para>It was looking for <filename>mind.dat</filename> in only one directory. Clearly,
<filename>mind.dat</filename> isn't in <filename class="directory">/usr/share</filename>.
Now we can try to locate <filename>mind.dat</filename> and move it into
<filename>/usr/share</filename>, or better, create a symbolic link.</para>
<para>This method works for libraries too. Suppose the library <filename
class="libraryfile">libmp3.so.2</filename> is in <filename
class="directory">/usr/local/include</filename> but your new game "Kill-Metallica" can't find
it. You can use strace to determine where Kill-Metallica was looking for the library and make
a symlink from <filename class="symlink">/usr/local/include/libmp3.so.2</filename> to wherever
Kill-Metallica was looking for the library file.</para>
<para>strace is a very powerful utility. When diagnosing why things aren't being found, it's
your best ally, and is even faster than looking at source code. As a last note, you can't
look up information in source code of commercial games from Lokisoft or Tribsoft. But you can
still use strace with them!</para>
</sect2>
<sect2 id="hosedconsoles"><title>Hosed consoles</title>
<para>Sometimes a game will exit abnormally and your console will get `hosed'. There are a
few definitions of a hosed console. The text characters could look like gibberish. Your
normally nice black screen could look like a quasi-graphics screen. When you press
<keycap>ENTER</keycap>, a newline doesn't get echo'ed to the screen. Sometimes, certain keys
of the keyboard won't respond. Logging out and back in don't always work, but there are a
few things that might:</para>
<itemizedlist>
<listitem><para>If you don't see any character on the screen as you type in, your terminal
settings may be wrong. Try "stty echo". This should let input characters echo
again.</para></listitem>
<listitem><para>At the prompt, type "reset". This should clear up many problems, including
consoles hosed by an SVGAlib or ncurses based game.</para></listitem>
<listitem><para>Try running the game again and normally. Once I had to kill Quake III in a
hurry, so I performed a <keysym>Ctl-Alt-Backspace</keysym>. The console was hosed with a
quasi-graphics screen. Running Quake III and quitting normally fixed the
problem.</para></listitem>
<listitem><para>The commands deallocvt and openvt will work for most of the other problems
you'll have. <command>deallocvt N</command> kills terminal <literal>N</literal> entirely, so
that <literal>Alt-FN</literal> doesn't even work anymore. <command>openvt -c N</command>
starts it back up.</para></listitem>
<listitem><para>If certain keys on your keyboard don't work, be creative. If you want to
reboot but the `o' key doesn't work, try using halt. One method I've come up with is typing a
command at the prompt and using characters on the screen with mouse cut/paste. For example,
you can type "ps ax", and you're sure to have an `h', `a', `l' and a `t' somewhere on the
screen. You can use the mouse to cut and paste the word "halt".</para></listitem>
<!-- if you type ps ax, you already have an 'a' ;) -->
<listitem><para>The most regrettable option is a reboot. If you can, an orderly shutdown is
preferable; use "halt" or "shutdown". If you can't, ssh in from a another machine. That
sometimes works when your console is very badly hosed. In the worst case scenario, hit the
reset or power switch.</para></listitem>
</itemizedlist>
<para>Note that if you use a journalling filesystem like ext3, reiserfs or xfs, hitting the
power switch isn't all that bad. You're still supposed to shutdown in an orderly manner, but
the filesystem integrity will be maintained. You won't normally see an fsck for the
partitions that use the journalling filesystem.</para>
</sect2>
<sect2><title>Locked System</title>
<para>When a computer "locks", also called "hung", the keyboard and mouse become completely
unresponsive. This is a direct consequence of a bug in the Linux kernel. While Linux is
known for stability, these things do happen, especiallly for gaming which entails highly
synchronized hardware events which occur very fast, even to a computer. When a computer
locks, it can be a "hard lock", meaning the kernel has completely stopped functioning. This
often indicates misbehaving or faulty hardware. There's no recovery from this kind of lock
other than pressing the reset or power button. The lock can also be a "soft lock", meaning
that the kernel is still functioning in some capacity. It's possible to recover from this
gracefully.</para>
<itemizedlist>
<listitem><para>The first thing you should try is to hit
<literal>control-alt-backspace</literal> which kills X. If you gain control of your system,
the kernel wasn't really locked in the first place. If this didn't work after a few seconds,
you'll definitely want to reboot the system using the following
instructions.</para></listitem>
<listitem><para>Use <literal>control-alt-delete</literal> to reboot the system. You'll know
this worked if you hear the computer beep after a few seconds (this is BIOS saying "I'm OK"
during a power on cycle).</para></listitem>
<listitem><para>Log into another system and ssh into the hung system. If you can ssh in,
reboot or halt the system.</para></listitem>
<listitem><para>If you can't ssh into the system, you'll need to use the "magic SysRq key"
which is documented in <filename>/usr/src/linux/Documentation/sysrq.txt</filename>. Here's a
summary for the x86 architecture (see the documentation for other architectures). Note if
your keyboard doesn't have a <keycap>SysRq</keycap> key, use the <keycap>PrintScreen</keycap>
key:
<orderedlist>
<listitem><para>Hit <literal>alt-SysRq-s</literal>. This will attempt to sync your mounted
filesystems so that changes to files get flushed to disk. You may hear disk activity. If
you're looking at a console, the system should print the devices which were
flushed.</para></listitem>
<listitem><para>A few seconds later, hit <literal>alt-SysRq-u</literal>. This will attempt
to remount all your mounted filesystems as read-only). You should hear disk activity. If
you're looking at a console, the system will print the devices which were
remounted.</para></listitem>
<listitem><para>A few seconds later, use <literal>alt-SysRq-b</literal> to reboot the
system.</para></listitem>
<listitem><para>You can hit <literal>alt-SysRq-h</literal> for a very terse help
screen.</para></listitem>
</orderedlist></para></listitem>
</itemizedlist>
<para>To use the magic SysRq key, your kernel needs to have been compiled with magic SysRq
support. You'll find this option under "<literal>Kernel Hacking | Kernel Debugging | Magic
SysRq key</literal>" in whatever kernel config menu you like to use. If the magic SysRq key
sequence doesn't shut your system down gracefully, your kernel has crashed hard and you'll
need to use the reset or power button to recover.</para>
</sect2>
</sect1>
<sect1><title>Video Cards</title>
<sect2><title>History</title>
<para>Once upon a time, a company in San Jose, California named 3dfx Interactive was king of
the gaming video card market. In October 1996 they released the Voodoo I, which was a
phenomenal success. It was the first hardware accelerated card, but only rendered 3D; it had
to be piggybacked with a 2D video card. The idea was that 2D rendering was handled by a high
quality 2D video card (Matrox was immensely popular at the time) but 3D information (see
Glide2, <xref linkend="glide2">) would be passed to the Voodoo I and rendered, using the
Voodoo's fast hardware to perform the necessary graphics calculations. They released the
Voodoo Rush in April 1996. It should've been a more powerful card, with a 50MHz GPU and 8MB
of RAM. Even better, it was their first combined 2D/3D card, meaning that it freed up a
valuable PCI slot (most PC's only had a couple of PCI slots back then) but the Rush wasn't as
popular. 3dfx removed the multi-texturing unit from the Rush, and it was outperformed by the
Voodoo I. At the time, ATI had their Rage series and nVidia had their Riva 128, but the
Voodoo I blew them all away.</para>
<para>This was a good time for Linux. id Software's open sourced the Doom codebase and ported
Quake I to Linux (December 1996). We were getting our first tastes of real commercial gaming.
Life was simple: you purchased a Voodoo. And it felt good, because 3dfx open sourced their
drivers. The king of video cards worked with Linux developers. Not only did we have the best
video cards, but the drivers were all open source.</para>
<para>In March 1998, 3dfx released their Voodoo II, with its 3.6GB/sec memory bandwith, 12MB
of video memory and 90MHz core. It supported resolutions up to 1024x768. This was 3dfx in
its heyday. Like the Voodoo I, the Voodoo II was a 3D only card, and piggy backed with a 2D
video card. The Voodoo Banshee was released in September 1998 as a combined 2D/3D card, like
the Rush. Despite the faster 100MHz core, the Banshee was outperformed by the Voodoo II
because its multi-texturing unit was removed, like with the Rush. And again like the Rush, it
wasn't popular. But 3dfx reigned supreme, and nobody could touch them.</para>
<para>In April 1999, the Voodoo III was released. There were a number of Voodoo III's,
ranging from a 143MHz core speed to 183MHz. There were TV-out versions. There were PCI and
AGP versions (it was the first AGP video card). It was another success, but 3dfx began to
lose ground to nVidia, which released their TNT 2. The TNT 2 outperformed the Voodoo II, and
accelerated 3D graphics at full 32 bit color, while the Voodoo's were stuck at 16 bit color.
But life was still good for Linux. We had a card that was almost neck-to-neck with nVidia,
our drivers were open source, and in December 1999, id Software gave us a huge gift: they open
sourced the Quake I codebase.</para>
<para>Then nVidia released the GeForce 256 in October 1999. 3dfx's Voodoo IV, its direct
competitor, was about a year late which is very bad when you're competing for a bleeding edge
market. While nVidia was putting real R&amp;D into their cards, 3dfx was simply adding more
and faster RAM. The Voodoo IV and V rendered in full 32bpp color, had great AA support (<xref
linkend="aa">), featured a 2nd GPU, more memory, and was arguably the king of video cards.
However, 3dfx's late release of the Voodoo IV and V coupled with the fact that the GeForce
could be had for half the price meant that 3dfx was sinking fast. For Linux, the newest
Voodoo's could only accelerate at 16 and 24 bit color. Worse still, the Voodoo V's 2nd GPU
was unused by the Linux driver (and to this day, the Voodoo V is functionally equivalent to
the single GPU Voodoo IV on Linux). Most Windows users were switching to nVidia, and despite
the fact that the nVidia drivers were proprietary, even Linux users began to jump onto the
nVidia bandwagon. VA Linux, the largest Linux server vendor, put nVidia into their
machines.</para>
<para>Then in April 2000, 3dfx was attacked on a different front: ATI started releasing their
first generation Radeons. Until this point, ATI had always been an innovative (they developed
their own 3D acceleration chips in 1996, about the same time as 3dfx), but sleepy graphics
chipset manufacturer. The Radeons were their first 3D accelerated card that gamers took any
real serious interest in. Their Radeons trounced both nVidia and 3dfx. They worked with
Linux developers, open sourced all their drivers and were hailed as the great hope for Linux
gaming. nVidia came back with fists swinging, and this was all too much for 3dfx. Between
losing the benchmark wars to the GeForce and Radeon, their lateness with new cards and high
prices, 3dfx lost its market share and didn't have the funds to stay into business. On April
18 2001, they sold most of their assets and technology to nVidia, and in October 2002, they
finally declared bankruptcy.</para>
<para>The demise of 3dfx was quite sudden and a slap in the face to the open source community.
I still remember my friend Gabe Rosa emailing me with just "<literal>Look at /.</literal>" and
seeing the news. It was the 2nd worst day for Linux gaming (the 1st being the demise of
Loki). And it was also a shame. 3dfx was getting ready to release a new Voodoo V featuring 4
GPU's which would've trounced the ATI and nVidia offerings, as well as a new card code named
"Rampage" which reportedly would've put them firmly back as the king of the hill. There are
reports that the Rampage's technology (which was sold to nVidia) went into the GeForce 5900.
Not too shabby for 3 year old technology!</para>
<para>At first, things were still simple. Linux gamers would either keep their open source
Voodoos, get an open source Radeon or a closed source GeForce. However, with bigger and
better games on the horizon, it was only a matter of time before the Voodoos would no longer
be a viable graphics card for modern gaming. People were still using Voodoo's, but they were
essentially out of the game at this point.</para>
<para>ATI started to release a tremendous number of versions of each video card, and keeping
up with them and their terminology started to become very difficult. ATI, together with
nVidia, played king of hill. Their products have been neck to neck ever since, with GeForce
taking the lead a bit more times than the Radeon. But the Radeon's drivers were open source,
so many Linux users stuck by them. Then things got even more complicated.</para>
<para>ATI started becoming more and more reluctant to open source drivers for their new
releases, and suddenly, it wasn't clear who the "good guy" was anymore. nVidia's party line
was they license some of their GL code from another company, and is thus non-releasable.
Presumably, ATI doesn't want to release drivers to keep their trade secrets, well, a secret.
And it gets worse. The ATI Linux drivers have been plagued by extremely poor performance.
Even when an ATI offering is better than the current GeForce offering for Windows, the card is
always trounced by GeForce on Linux. Because of the ATI Linux driver woes, Linux users cannot
use MS Windows based benchmarks or card stats. They simply don't apply to us. And that's
pretty much where we are right now.</para>
<para>As a last note, the only systematic Linux video card benchmarking effort I'm aware of
was done, unfortunately, in March 2001, between a Radeon 32 DDR and a GeForce 2. You can read
it for yourself at <ulink
url="http://www.linuxhardware.org/features/01/03/19/0357219.shtml"></ulink>, but conclusion is
that the GeForce 2 firmly and soundly trounced the Radeon 32 DDR.</para>
</sect2>
<sect2><title>Current Status (1 March 2004)</title>
<para>nVidia's latest offering is the GeForce 5900, based on the NV35 chipset. It's well
supported by Linux with high quality but proprietary drivers. nVidia uses a convenient
combined driver architecture; their driver will support the TNT 2 all the way up to the
GeForce 5900. Although their drivers are closed source, as a company, nVidia has been
supportive and good to Linux users.</para>
<para>ATI's has worked with Linux developers for their Radeons up to and including the Radeon
9200, which have 2D and 3D support in XFree86. I'm not entirely sure of the quality of these
open source drivers, however, Soldier of Fortune I and Heavy Metal still have opaque texture
problems under first generation Radeons. Beyond the 9200, you need to use ATI's binary only
proprietary drivers, available in rpm format from ATI's website. It's claimed that these
drivers are piss poor; a friend of mine claims his GeForce 4400 outperforms his Radeon 9700
pro. That's shameful.</para>
<para>On paper, and in the Windows benchmarks, the Radeon 9800 trounces the ill-conceived
GeForce 5800 and slightly edges out the GeForce 5900. On paper, it's simply the more
impressive card. But again, the driver issue makes this information unusable for us. If you
have your heart set to buy the best card for Linux, you'll want to go with the GeForce
5900.</para>
<sect3><title>SVGAlib Support</title>
<para>As of June 2002, SVGAlib support Radeon cards is shaky. Developers have reported
that SVGAlib works on the Radeon 7500, Radeon QD (64MB DDR model) but has problems on the
Radeon VE.</para>
<para>I have no information about SVGAlib and the GeForce cards.</para>
</sect3>
</sect2>
<sect2><title>Which Video Card Should I Buy? (1 March 2004)</title>
<para>The answer was very difficult last year, but here's my take on it these days:</para>
<orderedlist numeration="arabic">
<listitem><para>All GeForce cards require a proprietary driver which will "taint" your kernel.
However, all ATI cards beyond the Radeon 9200 also require a proprietary driver that will
"taint" your kernel as well.</para></listitem>
<listitem><para>nVidia has proven that they care enough about Linux to write and maintain
current and very high quality drivers for Linux. Even when ATI open sourced its video card
driver, they played the "we'll make Linux developers write our drivers for us" game. Their
current proprietary drivers are below par.</para></listitem>
<listitem><para>The current Radeon 9800 barely beats out the GeForce 5900 in benchmarks and
card specs, but Linux users won't benefit from this because of driver issues..</para></listitem>
<listitem><para>ATI has a very long history of dropping support for hardware as fast as they
can get away with it.</para></listitem>
<listitem><para>On MS Windows, when the GeForce beat out its main competing Radeon, the review
claimed that the Radeon generally had better visuals. I have no idea how this translates to
Linux.</para></listitem>
</orderedlist>
<para>Don't get the GeForce 5800. Card reviews claim that it has some serious <ulink
url="http://www.hardocp.com/article.html?art=NDIx">heat, noise, and dust</ulink> issues. It's
informally called the "dust buster" because of noise its fan makes.</para>
<para>If you absolutely only want open source drivers on your system, the Radeon 9200 is the
best card you can buy.</para>
<para>If you have a Linux/Windows dual boot, consider either the Radeon 9800 or the GeForce
5900. The Radeon will be slightly stronger on Windows. The GeForce will be stronger on
Linux.</para>
<para>If you have a Linux only system, the GeForce 5900 is your best bet. As of today, the
256MB version comes in at a whopping $350, however, the 128MB version is more
reasonable.</para>
</sect2>
<sect2><title>Definitions: Video Card and 3D Terminology</title>
<para>We'll cover video card and 3D graphics terminology. This material isn't crucial to
actually getting a game working, but may help in deciding what hardware and software options
are best for you.</para>
<sect3 id="textures"><title>Textures</title>
<para>A rendered scene is basically made up of polygons and lines. A texture is a 2D image
(usually a bitmap) covering the polygons of a 3D world. Think of it as a coat of paint for
the polygons.</para>
</sect3>
<sect3 id="tl"><title>T&amp;L: Transform and Lighting</title>
<para>The T&amp;L is the process of translating all the 3D world information (position,
distance, and light sources) into the 2D image that is actually displayed on screen.</para>
</sect3>
<sect3 id="aa"><title>AA: Anti Aliasing</title>
<para>Anti aliasing is the smoothing of jagged edges along a rendered curve or polygon.
Pixels are rectangular objects, so drawing an angled line or curve with them results in a
'stair step' effect, also called the 'jaggies'. This is when pixels make, what should be a
smooth curve or line, jagged. AA uses CPU intensive filtering to smooth out these jagged
edges. This improves a game's visuals, but can also dramatically degrade
performance.</para>
<para>AA is used in a number of situations. For instance, when you magnify a picture,
you'll notice lines that were once smooth become jagged (try it with The Gimp). Font
rendering is another big application for AA.</para>
<para>AA can be done either by the application itself (as with The Gimp or the XFree86 font
system) or by hardware, if your video card supports it. Since AA is CPU intensive, it's
more desirable to perform it in hardware, but if we're talking about semi-static
applications, like The Gimp, this really isn't an issue. For dynamic situations, like
games, doing AA in hardware can be crucial.</para>
</sect3>
<sect3 id="fsaa"><title>FSAA: Full Screen Anti-Aliasing</title>
<para>FSAA usually involves drawing a magnified version of the entire screen in a separate
framebuffer, performing AA on the entire image and rescaling it back to the normal
resolution. As you can imagine, this is extremely CPU intensive. You will never see non
hardware accelerated FSAA.</para>
</sect3>
<sect3 id="mipmapping"><title>Mip Mapping</title>
<para>Mip mapping is a technique where several scaled copies of the same texture are stored
in the video card memory to represent the texture at different distances. When the texture
is far away a smaller version of the texture (mip map) is used. When the texture is near, a
bigger one is used. Mip mapping can be used regardless of filtering method (<xref
linkend="texturefiltering">). Mip mapping reduces memory bandwidth requirements since the
images are in hardware, but it also offers better quality in the rendered image.</para>
</sect3>
<sect3 id="texturefiltering"><title>Texture Filtering</title>
<para>Texture filtering is the fundamental feature required to present sweet 3D graphics.
It's used for a number of purposes, like making adjacent textures blend smoothly and making
textures viewed from an angle (think of looking at a billboard from an extreme angle) look
realistic. There are several common texture filtering techniques including point-sampling,
bilinear, trilinear and anisotropic filtering.</para>
<para>When I talk about 'performance hits', keep in mind that the performance hit depends on
what resolution you're running at. For instance, at a low resolution you may get only a
very slight hit by using trilinear filtering instead of bilinear filtering. But at high
resolutions, the performance hit may be enormous. Also, I'm not aware of any card that uses
anisotropic texture filtering. TNT drivers claim they do, but I've read that these drivers
still use trilinear filtering when actually rendering an image to the screen.</para>
<sect4><title>Point Sampling Texture Filtering</title>
<para>Point sampling is rare these days, but if you run a game with 'software rendering'
(which you'd need to do if you run a 3D accelerated game without a 3D accelerated board)
you're likely to see it used.</para>
</sect4>
<sect4><title>Bilinear Texture Filtering</title>
<para>Bilinear filtering is a computationally cheap but low quality texture filtering.
It approximates the gaps between textures by sampling the color of the four closest
(above, below, left and right) texels. All modern 3D accelerated video cards can do
bilinear filtering in hardware with no performance hit.</para>
</sect4>
<sect4><title>Trilinear Texture Filtering</title>
<para>Trilinear filtering is a high quality bilinear filter which uses the four closest
pixels in the second most suitable mip map to produce smoother transitions between mip
map levels. Trilinear filtering samples eight pixels and interpolates them before
rendering. Trilinear filtering always uses mip mapping. Trilinear filtering eliminates
the banding effect that appears between adjacent mip map levels. Most modern 3D
accelerated video cards can do trilinear filtering in hardware with no performance
hit.</para>
</sect4>
<sect4><title>Anisotropic Texture Filtering</title>
<para>Anisotropic filtering is the best but most CPU intensive of the three common
texture filtering methods. Trilinear filtering is capable of producing fine visuals,
but it only samples from a square area which in some cases is not the ideal method.
Anisotropic (meaning 'from any direction') samples from more than 8 pixels. The number
of sampled pixels and which sampled pixels it uses depends on the viewing angle of the
surface relative to your screen. It shines when viewing alphanumeric characters at an
angle.</para>
</sect4>
</sect3>
<sect3><title>Z Buffering</title>
<para>A Z buffer is a portion of RAM which represents the distance between the viewer (you)
and each pixel of an object. Many modern 3D accelerated cards have a Z buffer in their
video RAM, which speeds things up considerably, but Z buffering can also be done by the
application's rendering engine. However, this sort of thing clearly should be done in
hardware wherever possible.</para>
<para>Every object has a stacking order, like a deck of cards. When objects are rendered
into a 2D frame buffer, the rendering engine removes hidden surfaces by using the Z buffer.
There are two approaches to this. Dumb engines draw far objects first and close objects
last, obscuring objects below them in the Z buffer. Smart engines calculate what portions
of objects will be obscured by objects above them and simply not render the portions that
you won't see anyhow. For complicated textures this is a huge savings in processor
work.</para>
</sect3>
</sect2>
</sect1>
<sect1><title>Sound</title>
<sect2><title>Which sound card is best?</title>
<para>By the word "best" I mean best for gaming. Gamers want high quality sound for our games
with the least amount of tinkering. On the other hand, a musician would have a very different
concept of what "best sound card" would mean. If you're a musician, you might want to check
out the <ulink url="http://www.linuxdj.com/audio/quality/">Linux Audio Quality
HOWTO</ulink>.</para>
<para>Now that Linux is beginning to mature, this question isn't as important as it used to
be. Once upon a time, soundcards without onboard MIDI chips (most PCI sound cards) didn't do
MIDI. This was mostly a problem for things like xdoom or lxdoom using musserv. These days we
have MIDI emulators like Timidity and libraries like SDL which don't require hardware MIDI
support. Frankly, I've had many cards and I can't tell the difference between any of them for
gaming. If you want to do things like convert a record LP to digital format, then your choice
of a soundcard with a professional grade A/D converter is absolutely crucial. For this HOWTO,
we'll assume that you're more of a gamer than a studio recording engineer.</para>
<para>Your decision should be based on what will be the easiest to configure. If you already
have a card and it works well, that's good enough. If you're in the market to buy a sound
card, get something that will take you a second to configure. PCI cards are much easier to
deal with than ISA since you don't need to tell their drivers about which system resources
(IRQ, DMA, I/O addresses) to use. Some ISA cards ARE plug-n-play, like the Creative AWE-64,
and the Linux kernel has come a long way in auto configuring them.</para>
<para>My personal recommendation is any card which has the es1370 or es1371 chip, which uses
the es1370 and es1371 sound drivers on Linux. These cards include the older Ensoniq es1370
and newer Creative PCI-128. These cards are extremely cheap and trivial to get working under
Linux.</para>
<para>I used to be a fan of the Creative Soundblaster AWE 32, AWE 64 and AWE 64 gold
soundcards. These ISA PnP cards are well supported by both OSS and Alsa. They all use the
same E-mu 8000 synthesis chip which enables them to play 32 voices simultaneously (they have
32 "channels"). A few notes: First, the Soundblaster AWE HOWTO is very out of date. Second,
the AWE 64 and AWE 64 gold can play 64 voices simultaneously, but this is done in software.
Creative never released a Linux driver for these cards (and they never released programming
information to Linux developers), so Linux users cannot use the extra 32 channels on the AWE
64 and AWE 64 gold. As far Linux users are concerned, all three cards are completely
identical (although the AWE 64 gold has gold plated connectors, which are better for sound
quality than the more common steel connectors).</para>
<para>The Creative Soundblaster Live! is an extremely popular PCI sound card these days. I've
never owned one, so I cannot comment here. However, there have been numerous reports about
serious problems with the Live! and AMD motherboards that use the 686b southbridge. A google
search should turn up alot of information on this problem.</para>
<para>A more relevent issue is speakers, but even here the difference isn't huge. I've had
expensive Altec Lansing speakers perform only slightly better than el-cheapo speakers. You
get what you pay for with speakers, but don't expect a huge difference. You'll want to get
something with a separate sub-woofer; this does make a difference at a cost of extra power and
connector wires.</para>
</sect2>
<sect2><title>Why isn't my sound working?</title>
<para>First of all, it's probably not the game, it's probably your setup. AFAIK, there are 3
options to getting a sound card configured under Linux: the free OSS sound drivers that come
with the Linux kernel, the Alsa drivers and the commercial OSS sound drivers. Personally, I
prefer the free OSS drivers, but many people swear by Alsa. The commercial OSS drivers are
good when you're having trouble getting your sound card to work by free methods. Don't
discount them; they're very cheap (like 10 or 20 bucks), support bleeding edge sound cards and
take a lot of guesswork out of the configuring process.</para>
<para>There are 5 things that can go wrong with your sound system:</para>
<orderedlist numeration="arabic">
<listitem><para>Shared interrupt</para></listitem>
<listitem><para>Misconfigured driver</para></listitem>
<listitem><para>Something's already accessing the sound card</para></listitem>
<listitem><para>You're using the wrong driver</para></listitem>
<listitem><para>A permissions problem</para></listitem>
</orderedlist>
<sect3><title>Shared interrupt</title>
<para>The first thing to do is to figure out if you have an IRQ conflict. ISA cards can't
share interrupts. PCI cards can share interrupts, but certain types of high bandwidth
cards simply don't like to share, including network and sound cards. To find out whether
you have a conflict, do a <userinput>cat /proc/interrupts</userinput>. Output on my
system is:</para>
<screen>
$ cat /proc/interrupts
CPU0 CPU1
0: 24185341 0 XT-PIC timer
1: 224714 0 XT-PIC keyboard
2: 0 0 XT-PIC cascade
5: 2478476 0 XT-PIC soundblaster
5: 325924 0 XT-PIC eth0
11: 131326 0 XT-PIC aic7xxx
12: 2457456 0 XT-PIC PS/2 Mouse
14: 556955 0 XT-PIC ide0
NMI: 0 0
LOC: 24186046 24186026
ERR: 1353
</screen>
<para>The second column is there because I have 2 CPU's in this machine; if you have one
CPU (called UP, or uniprocessor), you'll have only 1 CPU column. The numbers on the left
are the assigned IRQ's and the strings to the right indicate what device was assigned that
IRQ. You can see I have an IRQ conflict between the soundcard (soundblaster) and the
network card (eth0). They both share IRQ 5. Actually, I cooked this example up because I
wanted to show you what an IRQ conflict looks like. But if I did have this conflict,
neither my network nor my sound would work well (or at all!).</para>
<para>If my sound card is PCI, the preferred way of fixing this would be to simply move
one of the cards to a different slot and hope the BIOS sorts things out. A more advanced
way of fixing this would be to go into BIOS and assign IRQ's to specific slots. Modern
BIOS'es can do this.</para>
</sect3>
<sect3><title>Misconfigured driver</title>
<para>Sometimes, a card is hardwired to use a certain IRQ. You'll see this on ISA cards
only. Alternatively, some ISA cards can be set to use a specific IRQ using jumpers on the
card itself. With these types of cards, you need to pass the correct IRQ and memory
access, "I/O port", to the driver.</para>
<para>This is a sound card specific issue, and beyond the scope of this HOWTO.</para>
<!-- FIXME: I should write about how to pass info to the driver. -->
</sect3>
<sect3><title>Something is already accessing your sound card</title>
<para>Perhaps an application is already accessing your soundcard. For example, maybe you
have an MP3 player that's paused? If something is already accessing your card, other
applications won't be able to. Even though it was written to share the card between
applications, I've found that esd (the enlightenment sound daemon) sometimes doesn't work
correctly. The best tool to use here is lsof, which shows which processes are accessing a
file. Your sound card is represented by <filename class="devicefile">/dev/dsp</filename>.
Right now, I'm listening to an MP3 (not a Metallica MP3, of course...) with
mp3blaster.</para>
<screen>
# lsof /dev/dsp
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
mp3blaste 1108 p 6w CHR 14,3 662302 /dev/dsp
</screen>
<para><command>fuser</command> is similar; but it lets you send a signal to any process accessing the device
file.</para>
<screen>
# fuser -vk /dev/dsp
USER PID ACCESS COMMAND
/dev/dsp root 1225 f.... mp3blaster
root 1282 f.... mp3blaster
</screen>
<para>After issuing this command, mp3blaster was killed with SIGKILL. See the man pages
for lsof and fuser; they're very useful. Oh, you'll want to run them as root since you'll
be asking for information from processes that may be owned by root.</para>
</sect3>
<sect3><title>You're using the wrong driver (or no driver)</title>
<para>There are only two ways to configure your card:</para>
<orderedlist numeration="arabic">
<listitem><para>Support must be compiled directly into the kernel</para></listitem>
<listitem><para>You must have the correct driver loaded into memory</para></listitem>
</orderedlist>
<para>You can find out which driver your sound card is using by doing "lsmod" or looking
at the output of "dmesg". Since sound is crucial for me, I always compile sound into my
kernels. If you don't have a driver loaded, you need to figure out what's been compiled
into your kernel. That's not so straight forward. Your best bet is to compile your
kernel. BTW, let me say that compiling your own kernel is the first step towards
proficiency with Linux. It's painful the first time you do it, but once you do it
correctly, it becomes very easy down the right, especially if you keep all your old
.config files and make use of things like "make oldconfig". See the Kernel HOWTO for
details.</para>
<para>If you haven't compiled the kernel yourself, there is an overwhelmingly good chance
that your system is set up to load sound drivers as modules. That's the way distros do
things. Have everything under the sun compiled as a module and try to load them all. So
if you don't see your sound card's driver with lsmod, your card probably isn't configured
yet.</para>
</sect3>
<sect3><title>Permissions Problem</title>
<para>If the sound card works when you're root but not any other user, you probably have a
permissions problem. If this is the case, as root, look at the group owner of the sound
card using <userinput>ls -l /dev/dsp</userinput>; it'll probably be
<literal>audio</literal>. Then, as root, add your non-root user to the audio group in
<filename>/etc/group</filename>. For example, I added the users p and wellspring to group
audio on my system:</para>
<screen>
audio:x:29:p,wellspring
</screen>
<para>Don't forget to use <command>grpconv</command> if you use shadow passwords
(which should be the case on most recent distributions) in order to maintain a consistent group
configuration. Then log out and log back in as the non-root user. Your sound card should work.
Thanks to James Barton for reminding me to add this to the howto.</para>
</sect3>
</sect2>
</sect1>
<sect1><title>Miscellaneous Problems</title>
<sect2><title>Hardware Acceleration Problems</title>
<para>XFree86 4.x provides a more centralized and self-contained approach to video. Much of
the funkyness like kernel modules for non-root access of video boards is, thankfully,
gone.</para>
<sect3><title>Hardware acceleration isn't working at all</title>
<para>If you're getting like 1 fps, then your system isn't using hardware 3D acceleration.
There's one of two things that can be going on.</para>
<orderedlist numeration="arabic">
<listitem><para>Your 3D system is misconfigured (more likely)</para></listitem>
<listitem><para>Game X is misconfigured (less likely)</para></listitem>
</orderedlist>
<para>The first step is to figure out which one is happening.</para>
<orderedlist numeration="arabic">
<listitem><para>If you have X 4.0 (X 3.* users procede to step 2), look at the output of
<userinput>X -probeonly</userinput>. You'll see:</para>
<screen>(II) XXXXXX: direct rendering enabled</screen>
<para>or</para>
<screen>(II) XXXXXX: direct rendering disabled</screen>
<para>where XXXXXXX depends on which video card you have. If direct rendering is
disabled, then your X configuration is definitely faulty. Your game is not at fault.
You need to figure out why DRI is disabled. The most important tool for you to use at
this point is the `DRI Users Guide'. It is an excellently written document that gives
you step by step information on how to get DRI set up correctly on your machine. A copy
is kept at <ulink url="http://www.xfree86.org/4.0/DRI.html"></ulink>.</para>
<para>Note that if you pass this test, your system is CAPABLE of direct rendering. Your
libraries can still be wrong. So procede to step 2.</para></listitem>
<listitem><para>There is a program called glxgears which comes with the "mesademos"
package. You can get mesademos with Debian (<command> apt-get install
mesademos</command>) or you can hunt for the rpm on <ulink
url="http://www.rpmfind.net"></ulink>. You can also download and compile the source
yourself from the mesa homepage.</para>
<para>Running glxgears will show some gears turning. The xterm from which you run
glxgears will display "X frames in Y seconds = X/Y FPS". You can compare your system to
the list of benchmarks below.</para>
<screen>
CPU TYPE VIDEO CARD X VERSION AVERAGE FPS
</screen>
<para>Compiling Mesa and DRI modules yourself can increase your FPS by 15 FPS; quite a
performance boost! So if your number is, say, about 20 FPS slower than a comparable
machine, chances are that glxgears is falling back on software rendering. In other
words, your graphics card isn't 3D accelerating graphics.</para>
<para>More important than FPS is having a constant FPS for small and large windows. If
hardware acceleration is working, the FPS for glxgears should be nearly independent of
window size. If it's not, then you're not getting hardware
acceleration.</para></listitem>
</orderedlist>
</sect3>
</sect2>
<sect2><title>Hardware acceleration works only for the root user</title>
<sect3><title>XFree86 4.x</title>
<para>If the following lines aren't present in your XF86Config-4 file, put them in:</para>
<screen>
Section "DRI"
Mode 0666
EndSection
</screen>
<para>This allows all non-root users to use DRI. For the paranoid, it's possible to
restrict DRI to only a few non-root users. See the DRI User Guide.</para>
</sect3>
<sect3><title>XFree86 3.x</title>
<sect4><title>Voodoo cards</title>
<para>Voodoo card hardware acceleration only takes place ONLY at 16bpp color and
fails silently when starting X in another color depth.</para>
<para>Also, Voodoo cards need the <filename>3dfx.o</filename> kernel module and a
<filename class="devicefile">/dev/3dfx</filename> device file (major 107, minor 0)
for non-root hardware acceleration. Neither the module nor the device file are used
under XFree86 4.x.</para>
</sect4>
</sect3>
</sect2>
</sect1>
<sect1><title>Emulation and Virtual Machines</title>
<para>Linux gets ragged on a lot because we don't have the wealth of games that other platforms
have. Frankly, there's enough games for me, although it would be really nice to have some of the
bleeding edge games and classics like Half-life and Carmageddon. Fortunately, we have more
emulators than you can shake a stick at. Although playing an emulated game is sometimes not quite
as fun as playing it on the native machine, and getting some of the emulators to work well can be
a difficult task, they're here, and there's alot of them!</para>
<sect2><title>What is a virtual machine?</title>
<para><anchor id="vm">A "real computer" provides an operating system many things, including a
CPU, I/O channels, memory, a BIOS to provide low level access to motherboard and I/O
resources, etc. When an operating system wants to write to a hard drive, it communicates
through a device driver that interfaces directly with the hardware device memory.</para>
<para>However, it's possible to give a program all the hardware resources it needs. When it
wants to access a hard drive, give it some memory to write to. When it wants to set an IRQ,
give it some bogus instructions that lets it think it set an IRQ. If you do this correctly,
then in principle, there's no way for the poor application to know whether it's really
accessing hardware or tricked by being given resources which simulate hardware. A virtual
machine is the environment which tricks applications into believing they're running on a real
computer. It provides all the services that a real computer would provide.</para>
<para>VM's were used initially in the 1960's to emulate time shared operating systems, but
these days we use them to run software which was written for foreign operating systems, or
more commonly, an entire operating system. Because of the nature of the VM, the foreign OS
can't tell the difference between operating in a VM or in a "real" machine.</para>
</sect2>
<sect2><title>Apple 8-bit</title>
<para>All the 8-bit Apple ][ emulators require a copy of the original ROM, for whichever
system you want to emulate, in a file. If you search hard enough, you can find file copies of
the ROMs for the Apple ][, ][+, ][e, ][c and //gs. They are still copyrighted by Apple, and
you can only use them legally if you actually own one of these computers.</para>
<sect3><title>KEGS</title>
<para>KEGS is an Apple II emulator written by Kent Dickey <email>kentd(at)cup(dot)hp(dot)com</email>
which was originally written for HP-UX, but improved and customized for Linux. It runs
under X at any color depth, and supports changeable memory sizes, joysticks, and sound.
KEGS boots all Apple II variants, and supports all of the Apple ]['s graphics modes. I
can't find a working homepage for this application.</para>
</sect3>
<sect3><title>apple2 and xapple2</title>
<para>The SVGAlib based <filename>apple2</filename> and X based <filename>xapple2</filename>
can emulate any Apple ][ variant except for the //gs. The interface is a bit funky, but
usable. Configuration is also a bit funky; this emulator would benefit from an SVGA or X
based configuration tool. It supports the undocumented portion of the 6502 instruction set
which some games rely on. <filename>apple2</filename> is currently being maintained by
Michael Deutschmann <email>michael(at)talamasca(dot)ocis(dot)net</email> and seems to be
developed at a slow but constant pace. I don't think this application has a
homepage.</para>
</sect3>
</sect2>
<sect2><title>DOS</title>
<sect3 id="dosemu"><title><application>dosemu</application></title>
<para>dosemu &lt;<ulink url="http://www.dosemu.org"></ulink>&gt; is the canonical DOS
emulator on Linux. When you think of DOS, don't think of things like PROCOM PLUS OR OTHER
PROGRA~1 WHICH HAVE SHORT NAMES AND ARE IN ALL CAPS. There are some real classics that were
written for DOS like Carmageddon, Redneck Rampage and Tomb Raider. dosemu can run these.
Unfortunately, it can take alot of effort to get dosemu to work, and of Jan 2002, the sound
code is somewhat broken. Not a big deal when you're trying to run Wordperfect or an old
database application. It's an absolute show stopper for gaming. Getting dosemu to work
well is not easy, but unfortunately, for DOS games it's the best avenue. Good luck. If you
have success using dosemu, I would like to hear from you. </para>
</sect3>
</sect2>
<sect2><title>Win16</title>
<sect3><title>Wabi</title>
<para><application>Wabi</application> is a commercial Win16 emulator. That is, it'll run
Windows 16-bit applications from a Windows 3.1, Windows 3.11 or Windows for Workgroups
3.11 environment. <application>Wabi</application> was originally created by SCO Unix a
long time ago and then was purchased by Caldera sometime in mid year 2001.</para>
<para>Wabi is fast and does a good job for what it does, although I've heard it said that
wabi for Solaris is more stable than Linux. It might be useful for playing older Win16
games, but there are three problems:</para>
<itemizedlist>
<listitem><para>You must have a licensed copy of Windows 3.1/3.11 or WfW
3.11.</para></listitem>
<listitem><para>Wabi is awfully expensive for what it does.</para></listitem>
<listitem><para>Wabi doesn't work under 32bpp or 24bpp color.</para></listitem>
</itemizedlist>
<para>Wabi does NOT do DOS itself, but it looks like it can use a DOS emulator as a
backend for running DOS programs. There was talk about Wabi 3.0 which would've done
Win32 emulation, but AFAIK, this project was shelved indefinitely. I think Wabi will run
under Linux on all architectures (can someone verify this?)</para>
</sect3>
</sect2>
<sect2 id="win32"><title>Win32</title>
<sect3 id="wine"><title><application>wine</application></title>
<para>Wine &lt;<ulink url="http://www.winehq.com"></ulink>&gt;, which bears the GNUish
acronym "Wine Is Not An Emulator" is a non-commercial implementation of the Win32 API.
The reason why it's not an emulator is subtle and not of much interest to most non
computer scientists, so we'll call it an emulator here (it really does run-time
translation of calls to the Win32 API to POSIX/X11 calls). Wine has come a long way, and
is capable of emulating many important programs, which is great news for Linux users who
want this sort of stuff.</para>
<para>Wine does <literal remap="bf">not</literal> provide the DOS API, so you can't use it
to run DOS applications. For that, you should look at dosemu (<xref linkend="dosemu">).
Wine has never been too good at implementing DirectX, although a number of games are known
to work under wine. For gaming you might want to look at winex (<xref
linkend="winex">).</para>
<para>In addition to run-time translation of the Win32 API to POSIX/X11 (it runs Windows
applications on Linux), wine also does compile-time tranlation of the Win32 API to
POSIX/X11 (it compiles Windows application source code on Linux). In this sense, wine is
a Windows-to-Linux porting utility. The x86 architecture isn't required, but is
recommended since it allows actual x86 binary execution as well as direct DLL
usage).</para>
<para>You can use wine `with Windows', which means that wine uses libraries that actually
come with Microsoft Windows itself. This is legal only if you own a copy of Windows which
isn't currently being used on a computer. It's said that wine has the best success when
run with Windows. You can also run wine without Windows. The people at <ulink
url="http://www.winehq.com">winehq</ulink> are writing their own set of libraries called
<literal>libwine</literal> which implements the Win32 API with no Microsoft code at
all.</para>
<para><anchor id="winelicense">Wine was originally licenced under the MIT/X11 license, so
it could be used for both commercial and non-commercial purposes. In mid 2002, parts of
wine were re-licensed under the LGPL so that it could only be used for non-commercial
puposes. This presents a problem for companies like Transgaming (<xref linkend="winex">)
and prompted a fork of wine called ReWind (<xref linkend="rewind">).</para>
</sect3>
<sect3 id="rewind"><title><application>rewind</application></title>
<para>Rewind &lt;<ulink url="http://rewind.sourceforge.net/"></ulink>&gt; was started by
Eric Pouech (a wine developer) and Ove K<>ven (a winex developer) in response to <link
linkend="winelicense">wine's license change</link>). It started out life as a snapshot of
the last version of wine which was completely licensed under the MIT/X11 license. The aim
is to keep rewind MIT/X11 based so that companies like Transgaming can offer wine based
products.</para>
</sect3>
<sect3 id="winex"><title><application>winex</application></title>
<para>Winex is released by a company called Transgaming &lt;<ulink
url="http://www.transgaming.com"></ulink>&gt;. The developers take wine (see <xref
linkend="wine">) and add DirectX / DirectDraw support. Although winex is commercial, they
have an interesting business model.</para>
<para>The end user (you) can download the source code for free. However, for 5 US dollars
per month, you can become a subscriber of Transgaming. Being a subscriber of Transgaming
gives three major benefits:</para>
<itemizedlist>
<listitem><para>Subscribers can download convenient packaged versions of winex in deb, rpm
or tar.gz format whenever they want, including updates. They have also more functionality
than the publicly available tarball: the latter is an older version which lacks some of
the newest features, like support for copy protected programs.</para></listitem>
<listitem><para>There are monthly polls where subscribed users can take votes on what they
want winex developers to work on. For instance, they can vote for things like "Improve
support for copy protected programs", "Better Installshield support" or "Improve DirectX
8.0 support". As far as I can see, the developers really do listen to the subscriber
polls.</para></listitem>
<listitem><para>The Transgaming website has a few user support forums. On one hand, they
use the most godawful, horrible, confusing, wasteful, moronic format I've ever seen and I
hope to god I never see a forum with a format as bad as Transgaming's. On the other hand,
you can ask for help and the developers are VERY good about getting around to your answer;
their vigilance is quite impressive. Non-subscribers can browse the forums, but only
subscribers can post (and therefore, ask for support).</para></listitem>
</itemizedlist>
<para>The developers of winex were going to release their Installshield, DirectX and
DirectDraw enhancements to wine "every so often". In return, as wine maturation improved,
the winex developers were going to take the new versions of wine and use them for winex.
However, since the birth of Transgaming, parts of wine have been re-licensed under the
more restrictive GNU LGPL license (<xref linkend="wine">). This basically means that
versions of wine that are released past the date of the re-licensing can no longer be used
by winex. Therefore, winex will now be based on rewind (<xref linkend="rewind">).</para>
</sect3>
<sect3 id="win4lin"><title>Win4Lin</title>
<para>Win4Lin &lt;<ulink url="http://www.netraverse.com"></ulink>&gt; is a commercial
product by Netraverse. Like vmware (<xref linkend="vmware">) it uses the virtual machine
approach to running Windows applications, so you'll get a big window from which you can
boot Windows and run all kinds of Windows applications. Unlike vmware, Win4Lin only does
Windows 95/98/ME, but this turns out to be better for gamers. Because Win4Lin
concentrates on these operating systems, reports say that it's faster and does a better
job at running games under these operating system than vmware. It's also much cheaper
than vmware. The most recent version of Win4Lin as of June 2003 is 5.0. It suffers
nevertheless from some limitations:</para>
<itemizedlist>
<listitem><para>It does not support DirectX or DirectDraw, while vmware has "limited"
support for DirectX.</para></listitem>
<listitem><para>It only supports serial and parallel devices. This is important for
people who use USB joysticks. Note that vmware supports up to 2 USB devices.</para>
</listitem>
<listitem><para>As of June 2003, expect to pay $89.99 without printed docs and $99.99 with
printed docs. In addition, there isn't an evaluation copy available, although you get a
30 day money back guarantee. However, since it's commercial you do get tech support.
vmware is considerably more expensive.</para></listitem>
<listitem><para>Like vmware, you're required to have a licensed copy of Win95 or Win98.
Win4Lin cannot use an existing Windows installation the way wine can.</para></listitem>
<listitem><para>It only runs on x86 architectures.</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="vmware"><title>VMWare</title>
<para><ulink url="http://www.vmware.com"><application>VMWare</application></ulink> is a
virtual machine that runs multiple operating systems simultaneously on a standard PC:
supported OSes include Microsoft ones, Linux, Novell Netware and FreeBSD. You can among
others use it to run a MS Windows OS and launch your favourite game there. You can even
run another Linux under Linux; useful is you want to test another distro for instance.
Amazing! Now for the bad sides. You should definitely have a good configuration in order
to run it; they claim the minimum is a 500MHz x86 CPU with 128MB RAM, but a faster
processor and at least 256MB RAM seem to be the bare minimum if you want reasonable
performance. Not all Linux distributions are supported: newest RedHat's, Mandrake's and
Suse's are, but you're out of luck if you have an other version and/or distribution (like
Debian). Moreover, <application>vmware</application> has only limited support for DirectX,
and you might not be able to play recent games.</para>
<para>See <ulink url="http://www.vmware.com"></ulink> for more information. It's not very
cheap (about 300$ for the Workstation version), but you can get a 30 day evaluation
copy.</para>
</sect3>
<sect3><title>What should I choose?</title>
<para>First of all, you should try an emulator. Although some games may work with <link
linkend="wine">wine</link>, you'll probably get the most success with <link
linkend="winex">winex</link>: its DirectX support is constantly improving. As of version
3.1, the DirectX 8 support is nearly complete, but this may not be the case with older
DirectX versions (are consequently older games).</para>
<para>You might also try a virtual machine like <link linkend="win4lin">Win4Lin</link> or
<link linkend="vmware">VMWare</link> instead of an emulator. If your goal is to run
Win95/98/ME applications on Linux, without USB and on the x86 architecture, Win4Lin's cost
and focus on Win95 type OS's make it a better choice than vmware. However, if you must
have USB support or run Linux on a platform other than x86, vmware is your only
option.</para>
<para>Now if your goal is to run Win95 type OS games under Linux, Win4Lin almost seems
better than vmware. The show-stopper is the fact that vmware has limited DirectX support
while Win4Lin has none. This fact alone makes both Win4Lin and vmware unsuitable for most
hardcore gaming purposes. But if you're going to give it a try, you're more likely to
have success with vmware.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="interpreters"><title>Interpreters</title>
<sect2><title>SCUMM Engine (LucasArts)</title>
<para>Lucasarts wrote an engine for point and click adventures named SCUMM (Script Creation
Utility for Maniac Mansion). They wrote many graphical adventures using SCUMM, like their
famous Monkey Island series (all three). Ludvig Strigeus
<email>strigeus(at)users(dot)sourceforge(dot)net</email> was able to reverse engineer the
SCUMM format
and write an interpreter for SCUMM based games that compiles under Linux and Win32 named
scummvm &lt;<ulink url="http://scummvm.sourceforge.net/"></ulink>&gt;. Their website is very
good, and chock full of any kind of information about SCUMM and playing these games under
scummvm.</para>
<para>A compatibility page is maintained at the scummvm website. FWIW, I've been able to
finish many of the games that are listed as 90% done with no problems. scummvm is rock solid,
and allows you to purchase SCUMM based Lucas Arts games, copy the data files to your hard
drive and play them under Linux. As of February 2002, I've been following their cvs, and
this project is undergoing constant development. Kudos to the scummvm team.</para>
</sect2>
<sect2><title>AGI: Adventure Gaming Interface (Sierra)</title>
<para>The older Sierra DOS graphical adventure games used a scripting language named AGI
(Adventure Gaming Interface). Some examples of games written in AGI would be Leisure Suit
Larry I (EGA), Space Quest I and II, King's Quest II, Mixed-Up Mother Goose and others. These
games can be played using <application>sarien</application>on> &lt;<ulink
url="http://sarien.sourceforge.net"></ulink>&gt;, an open source interpreter for AGI
games.</para>
<para>Sarien was written in SDL, so it should run on any platform that can compile SDL
programs. In addition, there are versions for DOS, Strong-Arm based pda's, QNS (holy cow!
embedded gaming!), MIPS based systems and SH3/4 based Pocket PC's. The developers are clearly
out of their minds (in a good way!). Sarien also has numerous enhancements not found in the
original games, like a Quake style pull-down console, picture and dictionary viewer, enhanced
sound and support for AGDS, a Russian AGI clone. Sarien is under development and the
developers have been very good about documenting the Sarien internals if anyone wants to get
involved in hacking it.</para>
</sect2>
<sect2><title>SCI: SCript Interpreter or Sierra Creative Interpreter (Sierra)</title>
<para>The newer Sierra graphical adventure games (we're talking about the late 80's here) used
an interpreter named SCI. There were many versions of SCI since Sierra was constantly
improving its engine. The original SCI games were DOS based, but Sierra eventually started
releasing Win32 SCI based games. Some examples of games written with SCI are Leisure Suit
Larry 1 (VGA), Leisure Suit Larry 2-7, Space Quest 3-6, King's Quest 4-6, Quest For Glory 1-4
and many others. Compared with AGI games, SCI adventures have better music support, a more
complex engine and loads of bells and whistles.</para>
<para>Many SCI based games (games written in SCI0) can be played using
<application>freesci</application>, available at <ulink
url="http://freesci.linuxgames.com"></ulink>. Like Sarien, FreeSCI has many graphics targets
including SDL, xlib and GGI, so this program can compile and run under an incredible number
of platforms. The developers have done a fantastic job of documenting and FAQing their
application.</para>
</sect2>
<sect2 id="infocom"><title>Infocom Adventures (Infocom, Activision)</title>
<para>The Z-machine is a well documented &lt;<ulink
url="http://www.gnelson.demon.co.uk/zspec/index.html"></ulink>&gt; virtual machine designed by
Infocom to run their interactive fiction games. This allowed them to write game data files in
a cross platform manner, since only the engine itself, the Z-machine, would be platform
dependent. Z-machine went through a number of revisions during the lifetime of Infocom, and
two further revisions (V7 and V8 created by Graham Nelson) after the Infocom's demise. The
later versions even supported limited sound and graphics!</para>
<para>One of the most popular Z-machine interpreters is Frotz &lt;<ulink
url="http://www.cs.csubak.edu/~dgriffi/proj/frotz/"></ulink>&gt;. This excellently done page
has many nice links for interactive fiction fans. Frotz is GPL, runs all versions of
Z-machine and will compile on most versions of Unix. Frotz has spawned many forks, like a
version for PalmOS and Linux based PDA's.</para>
<para>jzip &lt;<ulink url="http://jzip.sourceforge.net/"></ulink>&gt; is another very popular
Z-machine interpreter that will run V1-V5 and V8 Z-machine data files. jzip is very portable;
it compiles on all Unices, OS/2, Atari ST and DOS.</para>
<para>There are actually many other Z-machine interpreters like nitfol and rezrov (written in
Perl!). Each interpreter has its own set of strengths, and you can find links to them on the
home pages for Frotz and jzip.</para>
</sect2>
<sect2 id="scottadams"><title>Scott Adams Adventures (Adventure International)</title>
<para>Scott Adams is, arguably, the father of interactive fiction. Although he himself was
inspired by the first piece of interactive fiction, Adventure, Scott brought adventuring to
the masses. His games were available for Atari, Apple 2, Commodore, Sorcerer, TI, and CPM.
His company, Adventure International, released a number of much loved games between 1978 and
1984 before folding. He recently released a new game (a Linux version is not available) but
since the decline of adventuring, he has pretty much kept out of the gaming industry.</para>
<para>Alan Cox wrote scottfree, a Scott Adams adventure game file interpreter for Unix. Using
scottfree and any of the Scott Adams data files which can be downloaded from Scott's website
&lt;<ulink url="http://www.msadams.com/"></ulink>&gt; you can enjoy these classics.</para>
</sect2>
<sect2><title>Ultima Underworld: The Stygian Abyss (Origin, Blue Sky Productions)</title>
<para>The Underworld Adventures project &lt;<ulink
url="http://uwadv.sourceforge.net/"></ulink>&gt; is an effort to port the 1992 classic, Ultima
Underworld: The Stygian Abyss, to modern operating systems like Linux, MacOS X, and Windows.
It uses OpenGL for 3D graphics, SDL for platform specific tasks and is released under the GNU
GPL. Underworld Adventures provides an impressive graphics system which uses the original
game files, so you'll need the original game disk to play.</para>
<para>Underworld Adventures also provides a bunch of tools for you to display the level maps,
tools for examining uw1 conversation scripts and more.</para>
</sect2>
<sect2 id="exult"><title>Ultima 7 (Origin, Electronic Arts)</title>
<para>Ultima 7 is actually 2 games: part I (The Black Gate) and part II (Serpent Island) which
uses a slightly enhanced version of The Black Gate's engine. In addition, an addon disk was
released to both part I (The Forge Of Virtue) and part II (The Silver Seed).</para>
<para>A team of people developed <application>Exult</application> &lt;<ulink
url="http://exult.sourceforge.net/"></ulink>&gt; which is an open source interpreter that will
run both parts of Ultima 7 and their addon disks. Exult is written in C++ using SDL, so it
will compile on any platform that can compile SDL programs. It also features some
enhancements over the original versions of the Ultima VII engine. You'll need to purchase a
copy of Ultima 7 to play. The developers have no plans on extending Exult to interpret the
other Ultimas since the engines changed so radically between releases.</para>
<para>The Exult team has also been hard at work creating a map editor, Exult Studio, and a
script compiler that will let users create their own RPG in the Ultima style.</para>
</sect2>
<sect2><title>System Shock (Electronic Arts, Origin)</title>
<para>System Shock is a classic first person shooter/adventure from 1994, which puts it as a
contemporary of Doom. However, its engine is much more feature rich than the original Doom:
for example, System Shock had 3D sprites, free look and a facility to have objects on top of
each other, giving the illusion of a full 3D map, like Quake. Game reviewers agree that this
game has the features of Quake with a story-line more compelling than Half-life. The System
Shock engine was optimized for sophistication, while Doom's engine was optimized for throwing
lots of monsters at you; a completely different appoach. Quite impressive for such an old
game!</para>
<para>The System Shock Hack Project &lt;<ulink
url="http://madeira.physiol.ucl.ac.uk/tsshp/sshock.html"></ulink>&gt; is an attempt to update
the game for modern operating systems. The project uses SDL and is released under the
modified BSD license. While you need the original game files to play SSHP, it should work
with the System Shock demo, which is freely available.</para>
</sect2>
</sect1>
<sect1><title>Websites And Resources</title>
<sect2><title>Meta gaming websites</title>
<para>These are some resources for Linux gamers no matter what kind of game you enjoy to
play.</para>
<variablelist>
<varlistentry><term>The Linux Game Tome: <ulink
url="http://www.happypenguin.org"></ulink></term> <listitem><para> About the games
themselves.</para></listitem></varlistentry>
<varlistentry><term><ulink url="http://www.linuxgames.com">Linuxgames</ulink></term>
<listitem><para> Linux gaming news</para></listitem></varlistentry>
<varlistentry><term><ulink url="http://www.holarse.net"></ulink></term> <listitem><para>Linux
meta gaming site for German speaking folk.</para></listitem></varlistentry>
<varlistentry><term><ulink url="http://www.mobygames.com">Mobygames</ulink></term>
<listitem><para>A database of all known computer games. It's very complete and is one of my
favorite sites.</para></listitem></varlistentry>
</variablelist>
</sect2>
<sect2><title>Commercial Linux Game Resources</title>
<sect3><title>Where to buy commercial games</title>
<para>ebgames &lt;<ulink url="http://www.ebgames.com"></ulink>&gt; no longer officially
sells Linux software. They stopped selling Linux games and distributions at around the
same time Loki Software declared bankruptcy, which is a shame because they had the lowest
prices on Linux games I've ever seen. However, occasionally, they'll have things like
Code Warrior or Redhat Linux on sale.</para>
<variablelist>
<varlistentry><term>Tux Games: <ulink
url="http://www.tuxgames.com"></ulink></term><listitem><para> Your one stop shop for
buying any commercial Linux game (software vendors like Tribsoft and Loki have online
shops at their websites too).</para></listitem></varlistentry>
</variablelist>
</sect3>
<sect3><title>Who Used To Release Games For Linux</title>
<para>These are companies that used to release games for Linux but for whatever reasons
aren't actively involved in Linux games anymore.</para>
<variablelist>
<varlistentry><term>Loki Software: <ulink url="http://www.lokigames.com"></ulink></term>
<listitem><para>As the company that brought CTP and Quake3 to Linux, Loki was the father
of Linux gaming. They were one of the first and had, by far, the most titles (I own ALL
of them). Loki ported games to Linux, mostly using the SDL library. Loki's death in
January 2002 was the biggest setback Linux has ever had in its attempt to capture the
general desktop market. Linuxgames.com has a nice Loki timeline at <ulink
url="http://www.linuxgames.com/articles/lokitimeline"></ulink></para></listitem></varlistentry>
<varlistentry><term>Tribsoft: <ulink url="http://www.tribsoft.com"></ulink></term>
<listitem><para>Tribsoft released Jagged Alliance 2, an excellent rpg/strat which claimed
2+ weeks of my life. There were slated to release Europai Universalis, Majesty and
Unfinished Business. However, as of 3Jan01, Mathieu Pinard of Tribsoft said that he was
taking a break and Tribsoft would no longer release games for awhile. He'll still support
JA2 but don't expect patches or updates.</para></listitem></varlistentry>
<varlistentry><term>MP Entertainment: <ulink
url="http://www.hopkinsfbi.com"></ulink></term> <listitem><para>MP Entertainment released
Hopkins FBI, my favorite game ever released for Linux. More violent than Quake. More
nudity than Hustler. More camp than <ulink
url="http://www.flatwaremedia.com/liberace/gallery.cfm">Liberace</ulink>. It's a comic
book on your monitor. They were slated to release Hopkins FBI II and a few other titles,
but it's been a few years since the announcements with no sign that the games are coming.
They've ignored all my attempts at finding out more information, so I have to conclude
that MP Entertainment is in the same status as Tribsoft. You can still purchase or
download a demo of Hopkins FBI from their website. If anyone has more information on this
company or the author of Hopkins FBI, please contact me.</para></listitem></varlistentry>
<varlistentry><term>Phantom EFX: <ulink url="http://www.phantomefx.com"></ulink></term>
<listitem><para>They offer Reel Deal Slots, which is very nicely done! I'm not much for
card/gambling games, but this game is impressive! Because their Linux guy quit the
company, Reel Deal Slots is their first, and so far, last release for
Linux.</para></listitem></varlistentry>
</variablelist>
</sect3>
</sect2>
<sect2><title>Other Resources</title>
<para>This section has URL's that should be mentioned but didn't have a separate section
within the howto, so I list them here as a kind of appendix.</para>
<variablelist>
<varlistentry><term>Linux Game Publishing: <ulink
url="http://www.linuxgamepublishing.com"></ulink></term> <listitem><para>Linux Publishing
doesn't sell directly to the public, but provides professional game publishing to authors of
publishing. I think this means disk copying, packaging and selling to
retailers.</para></listitem></varlistentry>
<varlistentry><term>XFree86 Homesite: <ulink url="http://www.xfree86.org"></ulink></term>
<listitem><para>XFree86 home page</para></listitem></varlistentry>
<varlistentry><term>Linux Game Development Center: <ulink
url="http://lgdc.sunsite.dk/index.html"></ulink></term> <listitem><para>This is the
canonical website for people who want to program games under Linux. It's a clearing house
of information that contains well written articles on all aspects of game programming (not
necessarily Linux specific), links to important game programming resources, interviews,
reviews, polls and lots of other stuff. It's hard to imagine a better website on the
subject.</para></listitem></varlistentry>
<varlistentry><term>Linux Gamers' FAQ: <ulink
url="http://www.icculus.org/lgfaq/"></ulink></term> <listitem><para>Despite the astounding
fact that the Linux Gamers' FAQ doesn't mention the Linux Gamers' HOWTO as a resource
anywhere in their text, I regard the FAQ as a good companion to this HOWTO. I've tried to
keep game specific information in this HOWTO at a minimum. The FAQ takes the opposite
approach; they mainly focus on the games themselves, including game specific problems and
where to get Linux games in the first place. The FAQ and HOWTO are complementary in this
regard, and I've tried to not reproduce their content. Despite the authors being a bit
surly, their effort with the FAQ is very good. If you want a general source of information
on game specific questions, the FAQ is a fantastic place to start with. In addition, the
FAQ keeps a fairly large database of Linux Games.</para></listitem></varlistentry>
<varlistentry><term>Linux Audio Quality HOWTO: <ulink
url="http://www.linuxdj.com/audio/quality/"></ulink></term> <listitem><para>This HOWTO is
mainly of interest to musicians who want professional or semi professional sound cards for
the recording and making of music on a computer. The information is very detailed, and
perhaps overkill for gamers.</para></listitem></varlistentry>
</variablelist>
</sect2>
</sect1>
</article>
<!--
vim:set textwidth=100:
-->
View Git Blame Copy Permalink