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

2500 lines
115 KiB
Plaintext
Raw Blame History

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<!-- Conventions:
2 spaces per indent level
4 spaces from left edge for <screen> environment
Problems:
&ldquo; and &rdquo; aren't yielding `` and ''.
-->
<article>
<artheader>
<title>The Linux Gamers' HOWTO</title>
<titleabbrev>LG-HOWTO</titleabbrev>
<author>
<firstname>Peter</firstname>
<othername role='middle'>Jay</othername>
<surname>Salzman</surname>
<affiliation>
<address>
<email>p@dirac.org</email>
</address>
</affiliation>
</author>
<pubdate>2002-07-06 v.0.9.16</pubdate>
<copyright>
<year>2001</year>
<holder>Peter Jay Salzman</holder>
</copyright>
<legalnotice>
<para>
<email>p@dirac.org</email> /
<systemitem role="url">www.dirac.org/p</systemitem>.
</para>
<para>
Distributed subject to the GNU General Public License, version 2.
</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>
</artheader>
<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@dirac.org</email>. My web page is <systemitem role="url">www.dirac.org/p</systemitem> and my Linux
pages are at <systemitem role="url">www.dirac.org/linux</systemitem>. 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 Peter Jay Salzman, <email>p@dirac.org</email>. Permission is
granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation
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 GNU FDL at <systemitem
role="url">www.gnu.org/copyleft/fdl.html</systemitem>.</para>
<para>If you want to create a derivative work or publish this HOWTO for commercial purposes, 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 to Mike Phillips who commented extensively on the howto. Thanks to Dmitry Samoyloff,
<email>dsamoyloff@yandex.ru</email>, for translating this document into Russian. It blew my mind when
he told me that he was translating my words to Russian.</para>
</sect2>
<sect2 id="version"><title>Latest Version and Translations</title>
<para>The latest version can be found at <systemitem
role="url">cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lgh/LG-HOWTO</systemitem>, but this is my own
personal working copy. You can get the most recent polished version (whatever that means) from
<systemitem role="url">www.linuxdoc.org</systemitem> and <systemitem
role="url">www.dirac.org/linux/writing</systemitem>.</para>
<para>Dmitry Samoyloff, <email>dsamoyloff@mail.ru</email>, is the maintainer of the Russian translation
of this HOWTO. The most recent version can be found at <systemitem
role="url">linuxgames.hut.ru/data/docs/HOWTO/LG-HOWTO-ru.html</systemitem>.</para>
</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 clove of 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 wad 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 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), 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 (doom2.wad,
pak0.pak, 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 so 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 FAKK.</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: System independent window event handling (mouse events, keyboard
events, etc.).</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;<systemitem role="url">www.mesa3d.org</systemitem>&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;<systemitem
role="url">www.dri.sourceforge.net</systemitem>&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 single processor machines the CPU doesn't have to change context between X 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;<systemitem role="url">www.libsdl.org</systemitem>&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 extentions 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 -->
<sect2 id="ggi"><title>What is GGI?</title>
<para>GGI &lt;<systemitem role="url">www.ggi-project.org</systemitem>&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 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 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 Frame Buffer 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;<systemitem role="url">www.openal.org</systemitem>&gt; aims to be for sound what OpenGL
is for graphics. Jointly developed by Loki Software and Creative Labs, it sets out to be a vendor
neutral and cross platform API for audio. It is licensed LGPL and the specs can be had for free from
the OpenAL website. OpenAL is fully functional, but now that Loki Software is no more its future
development is questionable.</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 Feb 2002, the most recent version of DirectX is 8.1. 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>DirectXAudio</term>
<listitem><para> Direct Audio 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>DirectX is "kind of" supported by winex (<xref linkend="winex">), 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<systemitem
role="url">http://www.v3x.net/directx</systemitem>&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;<systemitem
role="url">http://sourceforge.net/projects/dxglwrap</systemitem>&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, threadding 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>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>
<sect2 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>
</sect2>
<sect2 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>
</sect2>
<sect2 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>
</sect2>
<sect2 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>
</sect2>
<sect2 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>
</sect2>
<sect2 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>
<sect3><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>
</sect3>
<sect3><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>
</sect3>
<sect3><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>
</sect3>
<sect3><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>
</sect3>
</sect2>
<sect2><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>
</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>
<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 X.out. 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 Modetiming Howto for more information.</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:</para>
<segmentedlist>
<seglistitem><seg>Screen resolution</seg><seg>Width and Height</seg></seglistitem>
<seglistitem><seg>color bpp </seg><seg>Depth </seg></seglistitem>
</segmentedlist>
<para>and a few other things which are interesting but not immediately relevent to our subject, like
"Window Gravity State" which tells where new windows tend to be placed by the window manager.</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 (whether direct rendering
is being used or not, the currently installed versions of glx and mesa), vendor/renderer strings, the GL
library files being used and more.</para>
</sect3>
</sect2>
</sect1>
<sect1><title>Various Topics</title>
<sect2><title>Memory Type Register Ranges</title>
<para>Starting with Pentium class processors and including Athlon, K6-2 and other CPUs, there are Memory
Type Register Ranges (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><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 mtrr.txt (see
section 5.1) to set up your MTRRs. X 4.0 does this automatically for you.</para></listitem>
<listitem><para>Don't run a window manager (wm). Some wm's like twm don't take up much CPU cycles, but
still rob you of performance. Some window managers like enlightenment will definitely produce a
noticeable slow down. To run a game without a wm, you modify .xinitrc in your home directory. Here is
what my .xinitrc looks like:</para>
<screen>
#quake3 +set r_gldriver libGR.so.1
#/usr/local/games/SinDemo/Sin
#exec ut
#lsdldoom -server 2
#exec tribes2
exec /usr/bin/enlightenment
</screen>
<para>This file tells X what client to run upon starting. Usually this is your wm, and/or a desktop
manager (GNOME or KDE). Comment out the lines containing a wm and 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. Note that this is for people who use `startx' to start
X.</para>
<para>I never use things like gdm or run-level 5 (so I'm not positive here), but I suspect that if you do,
you'll need to do things a bit differently. My best guess is to go to single user mode (run-level 1)
by:</para>
<screen>
# telinit 1
</screen>
<para>then edit .xinitrc, then go back to run-level 5 by</para>
<screen>
# telinit 5
</screen>
<para>Then when you stop playing, go to run-level 1, modify .xinitrc then go back to run-level 5. I don't
use this stuff, so I'm not sure, but you may need to kill gdm. I'd appreciate some feedback on
this.</para>
<para>Kill all not-essential processes. Of course you'll have to do this as root. A better way to do
this than typing "ps ax", getting ntpd's pid, and sending it a SIGKILL (with kill -9) is to make use of
pidof:</para>
<screen>
# kill -9 `pidof ntpd`
</screen>
<para>However, an even better alternative is to use 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 scrip 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 be running nothing which 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
<literal>-static</literal> 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> /usr/lib/SDL.a</filename> and <filename>/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 <literal>-L</literal> 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 presense of the new libraries.</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 <systemitem
role="url">faqs.lokigames.com</systemitem>.</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 <systemitem role="url">updates.lokigames.com</systemitem>.</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 <systemitem
role="url">groups.google.com</systemitem>. This archive used to be at <systemitem
role="url">www.deja.com</systemitem>, 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 <systemitem
role="url">www.freetranslation.com</systemitem> and <systemitem
role="url">translation.lycos.com</systemitem>. My web browser of choice, Opera (available at
<systemitem role="url">www.opera.com </systemitem> 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 girlfriend (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 <systemitem
role="url">groups.google.com/advanced_group_search</systemitem></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 <systemitem
role="url">www.dirac.org/linux</systemitem>.</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
get long, but a company like Loki Software has 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 libraries: 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 wad or map file:</para>
<screen>
% qf-client-sdl
IP address 192.168.0.2:27001 UDP Initialized Error: W_LoadWadFile: couldn't load gfx.wad
</screen>
<para>Suppose gfx.wad 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 "4" is
the return value of the call. 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 occurances of "mind.dat", 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, mind.dat isn't
in <filename>/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 libmp3.so.2 is in /usr/local/include 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 of /usr/local/include/libmp3.so.2 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
<keysym>ENTER</keysym>, a newline doesn't get echo'ed to the screen. Sometimes, certain
keys of the keyboard won't respond. Logging out and back in won't work, but there are a
few things that will: </para>
<itemizedlist>
<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 gave it the 3 fingered salute. 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>
<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
fasion, but the filesystem integrity will be maintained. You won't see an fsck for the
partitions that use the journalling filesystem. </para>
</sect2>
</sect1>
<sect1><title>Hardware</title>
<para> I'm no Tom's Hardware or Anandtech, and don't have access to all the
wealth of hardware that's out there. Contributions and information to fill
out this section would is welcome. This stuff changes very often, and
peoples' experience with hardware would be useful. </para>
<sect2><title>Which video card is the best?</title>
<para> If you're using Linux, you must be smart enough to know that
there isn't a plain answer to this question. There seem to be 3
choices for hardware accelerated 3D these days: </para>
<orderedlist numeration="arabic">
<listitem><para>3dfx: Voodoo cards</para></listitem>
<listitem><para>Nvidia: GeForce</para></listitem>
<listitem><para>ATI: Radeon</para></listitem>
</orderedlist>
<para> According to Tom's Hardware and Anadtech, the Radeon is king
when playing at very high resolution (as in 1600x1200), at 32bpp, in
Windows. Otherwise the GeForce is king. There are two problems with
this. We don't normally play at 1600x1200/32bb, and we don't play on
Windows (at least I don't). </para>
<para> There aren't many recent video card benchmarks out for Linux. The most recent one
I've seen is from March 2001 at <systemitem
role="url">www.linuxhardware.org/features/01/03/19/0357219.shtml</systemitem>.
Considering the dearth of benchmarks out there, this needs to be taken as a canonical
benchmark, so I simply quote their conclusion: </para>
<blockquote><para> At this point the performance numbers tell a pretty simple story, if
it's raw speed you are looking for, the GeForce 2 is your choice. There is very little
performance drawback to running your favorite games in Linux instead of Windows with this
card. It provides a truly impressive performace across the board. The Radeon's performance
will almost definitely improve as the DRI drivers mature, but for now, especially for the
impatient, it is simply not a good choice for the hard core 3d gamer. </para>
<para> If, however, you are a graphics designer, and want a card with
impeccable 2d image quality, with 3d graphics only a secondary
priority, the Radeon is your best bet. The DRI drivers, even in their
current state, are quite usable. For 2d only users, XFree86 4.0.2
provides production quality 2d drivers. The GeForce thoroughly trounced
the Radeon in the Xmark performance test, so if you aren't running at a
ultra high resolution, or aren't that picky, the GeForce is once again
a better pick. </para> </blockquote>
<para>Now for my own input. The Radeon is a pretty amazing card. It's what I use, and I have yet to
see a game that needs more power than the Radeon is able to provide. However, the OpenGL renderer for
the Radeon is buggy, although the only games I've seen that suffer greatly are Loki Software's Heavy
Metal and Soldier Of Fortune. Hopefully the people doing Mesa for the Radeon will fix this very soon
since the Radeon is the best option for people who don't want to rely on the closed source, proprietary
GeForce. As of June 2002, SVGAlib support Radeon cards is shaky. Developers have reported that SVGAlib
works on the Radeon 7500, Radeon QD (ddr 64MB model) but has problems on the Radeon VE.</para>
<para>Now about the Voodoo cards. Unfortunately, 3dfx was bought out by nVidia, so these cards are a
dead end market. If you're out to play the bleeding edge games like Rune or Tribes2, you'll want the
Voodoo 3, 4 or 5. Preferably the 4 or 5. I think the Voodoo 5 is basically a Voodoo 4 with a second
processer. However, this processor is not utilized by the Linux driver, and rumor says that the Linux
3dfx driver will never support it. So as far as Linux is concerned, the Voodoo 4 and 5 are the same
card. All the drivers, Glide2 library and OpenGL renderers for the Voodoo cards were open sourced by
3dfx before they when under. It is an embarrasment to the Linux and open source community in general
that this company failed. SVGAlib officially supports only the Voodoo Banshee and the Voodoo III, but
from first hand experience, I've seen SVGAlib programs run on all the Voodoo cards.</para>
</sect2>
<sect2><title>Which sound card is best?</title>
<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 quite a big fan of the Creative Soundblaster AWE 32, AWE 64 and AWE 64
gold soundcards. They are ISA, but are plug-n-play. A couple of issues to note. First,
the Creative AWE HOWTO is very out of date. Second, AFAIK, Creative never released a
Linux driver that uses the AWE 64's extra 32 voices (and they never released programming
information for it either). So to a Linux users, the AWE 64 and 32 are nearly identical
sound cards. If anyone has more information about the differences that a Linux user would
see between the AWE 64 and 32, I'd like to hear from you. </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>
</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 the output of <command>X -probeonly</command>. 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
<systemitem role="url">www.xfree86.org/4.0/DRI.html</systemitem>. </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 gears 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
rpmfind.net. You can also download and compile the source yourself from
the mesa homepage. </para>
<para> Running gears will show some gears turning. The xterm from
which you run gears will read "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 gears 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 gears
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 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><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>/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>
<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 problems </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 "cat /proc/interrupts". 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. (I should write about how to pass info to the driver). </para>
</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
/dev/dsp. 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> fuser 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 prolly have a
permissions problem. If this is the case, as root, look at the group owner of the sound card
using <literal>ls -l /dev/dsp</literal>; it'll prolly 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>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>Emulation and Virtual Machines</title>
<para> Linux gets ragged on alot 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 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 virual machine?</title>
<para> 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><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@cup.hp.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, too; 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@talamasca.ocis.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;<systemitem role="url">www.dosemu.org</systemitem>&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><para> Wabi is awfully expensive for what it does. </para>
<listitem><para> Wabi doesn't work under 32bpp or 24bpp color. </para>
</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;<systemitem role="url">www.winehq.com</systemitem>&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 execuation 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 winehq are
writing their own set of libraries called libwine which implements the Win32 API with no
Microsoft code at all. </para>
<para> 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;<systemitem role="url">http://rewind.sourceforge.net/</systemitem>&gt;
was started by Eric Pouech (a wine developer) and Ove K<>ven (a winex developer) in
response to wine's license change (<xref linkend="wine">). 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;<systemitem
role="url">http://www.transgaming.com</systemitem>&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.</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).
</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 matured 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;<systemitem
role="url">www.netraverse.com/products/win4lin30/</systemitem>&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 May 2002 is 4.0. </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 January 2002, expect to pay $80 without printed docs and $90 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>
<para> 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 you're 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>
<sect3 id="vmware"><title>VMWare</title>
<para></para>
</sect3>
</sect2>
</sect1>
<sect1><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@users.sourceforge.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;<systemitem role="url">http://scummvm.sourceforge.net/</systemitem>&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> &lt;<systemitem
role="url">sarien.sourceforge.net</systemitem>&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 <systemitem
role="url">freesci.linuxgames.com</systemitem>. Like Sarien, FreeSCI has many graphics
targets including SDL, xlib and GGI, so this game 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;<systemitem
role="url">http://www.gnelson.demon.co.uk/zspec/index.html</systemitem>&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;<systemitem
role="url">http://www.cs.csubak.edu/~dgriffi/proj/frotz/</systemitem>&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;<systemitem role="url">http://jzip.sourceforge.net/</systemitem>&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> 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;<systemitem role="url">http://www.msadams.com/</systemitem>&gt; you can enjoy these
classics. </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;<systemitem
role="url">http://exult.sourceforge.net/</systemitem>&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>
</sect1>
<sect1><title>Websites And Resources</title>
<sect2><title>Meta gaming websites</title>
<variablelist>
<varlistentry><term>The Linux Game Tome:
<systemitem role="url">www.happypenguin.org</systemitem></term>
<listitem><para> About the games themselves. </para></listitem>
</varlistentry>
<varlistentry><term>linuxgames:
<systemitem role="url">www.linuxgames.com</systemitem></term>
<listitem><para> Linux gaming news </para></listitem>
</varlistentry>
<varlistentry><term>
<systemitem role="url">www.holarse.net</systemitem></term>
<listitem><para>Linux meta gaming site for German speaking folk.</para></listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2><title>Commercial Linux Game Resources</title>
<sect3><title>Where to buy commercial games</title>
<para> ebgames &lt;<systemitem role="url">www.tuxgames.com</systemitem>&gt; no longer
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. </para>
<variablelist>
<varlistentry><term>Tux Games:
<systemitem role="url">www.tuxgames.com</systemitem></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: <systemitem
role="url">www.lokigames.com</systemitem></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
<systemitem role="url">http://www.linuxgames.com/articles/lokitimeline/</systemitem>
</para> </listitem> </varlistentry>
<varlistentry><term>Tribsoft: <systemitem
role="url">www.tribsoft.com</systemitem></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: <systemitem
role="url">www.hopkinsfbi.com</systemitem></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
Liberacce. 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,
please contact me. </para></listitem> </varlistentry>
<varlistentry><term>Phantom EFX: <systemitem
role="url">www.phantomefx.com</systemitem></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:
<systemitem role="url">www.linuxgamepublishing.com</systemitem></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:
<systemitem role="url">www.xfree86.org</systemitem></term>
<listitem><para>XFree86 home page</para></listitem></varlistentry>
<varlistentry><term>Linux Game Development Center:
<systemitem role="url">http://lgdc.sunsite.dk/index.html</systemitem></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
<systemitem role="url">http://www.icculus.org/lgfaq/</systemitem></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 informatin 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.</listitem></varlistentry>
</variablelist>
</sect2>
</sect1>
</article>
<!--
vim:textwidth=110:
-->
View Git Blame Copy Permalink