<?xml version="1.0"?>
<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 format="linespecific">				<email>p@dirac.org</email>
			</address></affiliation></author><pubdate>v0.9.17, 2002-09-03</pubdate><copyright><year>2001</year><holder>Peter Jay Salzman</holder></copyright><legalnotice><para>			<email>p@dirac.org</email> / 
			<systemitem moreinfo="none" 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 moreinfo="none" role="url">www.dirac.org/p</systemitem> and my Linux
	pages are at <systemitem moreinfo="none" 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 moreinfo="none" 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 moreinfo="none" 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 moreinfo="none" role="url">www.linuxdoc.org</systemitem> and <systemitem moreinfo="none" 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 moreinfo="none" 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 format="linespecific"> You are in a room.  It is pitch dark and you're likely to be eaten by a grue.
ent 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.
ent Open the oven.
In the oven you see a brown paper bag.
ent 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"></xref>) and wad files.</para><para>The first adventure game was Adventure (actually entADVENTent, written on a PDP-1 in
			1972).  You can play Adventure yourself (actually, a descendent); it comes with entbsd gamesent
			on most Linux distros.  Text adventures became popularized by Scott Adams (<xref linkend="scottadams"></xref>)
			and reached their height of popularity in the late 80's with Infocom (<xref linkend="infocom"></xref>) 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"></xref>).  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 moreinfo="none">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 moreinfo="none">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 ent 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"></xref>).</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 moreinfo="none">/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"></xref>) 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"></xref>).  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 ent<systemitem moreinfo="none" role="url">www.mesa3d.org</systemitem>ent 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 ent<systemitem moreinfo="none" role="url">www.dri.sourceforge.net</systemitem>ent.  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"></xref>) for 2D graphics, OpenGL (<xref linkend="opengl"></xref>) for 3D graphics and widget sets (<xref linkend="widgetset"></xref>) 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 ent<systemitem moreinfo="none" role="url">www.libsdl.org</systemitem>ent 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"></xref>), 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><sect2 id="ggi"><title>What is GGI?</title><para>GGI ent<systemitem moreinfo="none" role="url">www.ggi-project.org</systemitem>ent 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"></xref>) using LibGGI.  SDL (<xref linkend="sdl"></xref>) and
			clanlib (<xref linkend="clanlib"></xref>) 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><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 moreinfo="none">xdm</application> or <application moreinfo="none">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
			consoleentwe 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 moreinfo="none">zgv</application> (a console
			graphical image viewer), <application moreinfo="none">prboom</application> and <application moreinfo="none">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 dependententif 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 ent<systemitem moreinfo="none" role="url">www.openal.org</systemitem>ent 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"></xref>), poorly supported by wine (<xref linkend="wine"></xref>), barely supported by vmware (<xref linkend="vmware"></xref>) and unsupported by Win4Lin (<xref linkend="win4lin"></xref>).</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, ent<systemitem moreinfo="none" role="url">http://www.v3x.net/directx</systemitem>ent 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 ent<systemitem moreinfo="none" role="url">http://sourceforge.net/projects/dxglwrap</systemitem>ent.</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>TentL: Transform and Lighting</title><para>The TentL 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"></xref>).  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 moreinfo="none">XF86Config</filename> (or <filename moreinfo="none">XF86Config-4</filename>).</para><sect2><title>Getting information about your X system</title><para>Whether you're trying to diagnose an X problem or requesting help from a mailing list or Usenet newsgroup, you'll
			want to have as much information available as possible.  These are a set of tools you can use to obtain that
			information.</para><sect3><title>Probeonly</title><para>One of the best diagnostic tools and sources of information about your X system is <command moreinfo="none">probeonly</command>
					output.  To use it, kill X if it's already running and from a console, type:</para><screen format="linespecific">    X -probeonly 2ent 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 "2ent" 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 format="linespecific">    (--) 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 format="linespecific">    (**) TDFX(0): Depth 16, (--) framebuffer bpp 16
					</screen><para>X has detected what my videocard chipset and videoram are:</para><screen format="linespecific">    (--) Chipset 3dfx Voodoo5 found
    (--) TDFX(0): VideoRAM: 32768 kByte Mapping 65536 kByte
					</screen></sect3><sect3><title>Getting info about your setup: xvidtune</title><para><application moreinfo="none">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 moreinfo="none">xwininfo</command> tells you all sorts of information about X windows.  And actually, your "background"
				or "root" window is considered a window too.  So when xwininfo asks you to click on the window you want the information
				on, click on your background.  It'll tell you things like screen and window resolution, color depth, window gravity
				state (which gives a hint to the window manager about where to place new windows), backing store usage and more.</para></sect3><sect3><title>Other sources of information</title><para><command moreinfo="none">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 moreinfo="none">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><sect2><title>Playing Games In X Without a Window Manager</title><para></para></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 moreinfo="none">/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 format="linespecific">    #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 format="linespecific">    # telinit 1
		</screen><para>then edit .xinitrc, then go back to run-level 5 by</para><screen format="linespecific">    # 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 format="linespecific">    # 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 format="linespecific">    # cd /etc/rc2.d
    # ./ntpd stop
		</screen><para>Another (radical) option is to simply put yourself in single-user mode with</para><screen format="linespecific">    # 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 moreinfo="none">gcc</command> uses dynamic
		libraries, but you can make <command moreinfo="none">gcc</command> use static libraries instead by using the
		<literal moreinfo="none">-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 entshared libraryent, 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 moreinfo="none">.dll</literal>'s used by Windows.  The program
			responsible for linking code enton the flyent is called <command moreinfo="none">/etc/ld.so</command>, and the
			dynamic libraries themselves usually end with <literal moreinfo="none">.so</literal> with a version number, like:</para><screen format="linespecific">    /usr/lib/libSDL.so
    /lib/libm.so.3
			</screen><para>When using <command moreinfo="none">gcc</command>, you refer to these libraries by shaving off the strings
			<literal moreinfo="none">lib</literal>, <literal moreinfo="none">.so</literal> and all version numbers.  So to use these two libraries,
			you would pass <command moreinfo="none">gcc</command> the <literal moreinfo="none">-lSDL -lm</literal> options.  <command moreinfo="none">gcc</command>
			will then `place a memo inside the executable' that says to look at the files <filename moreinfo="none">			/usr/lib/libSDL.so</filename> and <filename moreinfo="none">/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 moreinfo="none">.a</literal> followed by a version number, like:</para><screen format="linespecific">    /usr/lib/libSDL.a
    /usr/lib/libm.a
			</screen><para>The <literal moreinfo="none">.a</literal> files are really an archive of a bunch of <literal moreinfo="none">.o</literal> (object)
			files archived together, similar to a tar file.  You can use the <command moreinfo="none">nm</command> to see what
			functions a static library contains:</para><screen format="linespecific">    % 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 moreinfo="none">gcc</command>, you refer to these libraries by shaving off the strings
			entlibent, ent.aent and all version numbers.  So to use these two libraries, you would
			pass <command moreinfo="none">gcc</command> the <literal moreinfo="none">-lSDL -lm</literal> options.  <command moreinfo="none">gcc</command> will then
			`bolt on' code from <filename moreinfo="none"> /usr/lib/SDL.a</filename> and <filename moreinfo="none">/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 moreinfo="none">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 moreinfo="none">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 moreinfo="none">gcc</command> and <command moreinfo="none">ld.so</command> go about finding libraries in the first
			place.</para><para><command moreinfo="none">gcc</command> looks for libraries in the ``standard system directories'' plus any
			directories you specify with the <literal moreinfo="none">-L</literal> option.  You can find what these standard system
			directories are with <command moreinfo="none">gcc -print-search-dirs</command></para><para><command moreinfo="none">ld.so</command> looks to a binary hash contained in a file named
			<filename moreinfo="none">/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 moreinfo="none">/etc/ld.so.conf</filename> which you can edit.  This file contains
			a list of directories that you want <command moreinfo="none">ld.so</command> to search for dynamic libraries.  If you
			want to start putting dynamic libraries in <filename moreinfo="none">/home/joecool/privatelibs</filename>, you'd add
			this directory to <filename moreinfo="none">/etc/ld.so.conf</filename>.  Your change doesn't actually make it into
			<filename moreinfo="none">/etc/ld.so.cache</filename> until you run <command moreinfo="none">ldconfig</command>; once it's run,
			<command moreinfo="none">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 moreinfo="none">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 moreinfo="none" 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 moreinfo="none" 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 moreinfo="none">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 moreinfo="none">/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 moreinfo="none" role="url">groups.google.com</systemitem>.  This archive used to be at <systemitem moreinfo="none" 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 moreinfo="none" role="url">www.freetranslation.com</systemitem> and <systemitem moreinfo="none" role="url">translation.lycos.com</systemitem>.  My web browser of choice, Opera (available at
			<systemitem moreinfo="none" 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 moreinfo="none" 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 moreinfo="none" 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 format="linespecific">    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 format="linespecific">    $ gdb CoolGameExecutable core
			</screen><para> And at the (gdb) prompt, type "backtrace".  You'll see something like: </para><screen format="linespecific">    #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" inheritnum="ignore" continuation="restarts"><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 format="linespecific">    % ./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 format="linespecific">    % 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 format="linespecific">    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: /paraent


			<screen format="linespecific">    open(".", O_RDONLY|O_NONBLOCK|0x18000)  = 4
			</screen>

			</para><para>We used the <function moreinfo="none">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 format="linespecific">    % ./mind.i86_linux.glibc2.1 
    Loading ent 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 format="linespecific">    strace ./mind.i86_linux.glibc2.1 2ent ./StateOfMind_LOG
			</screen><para>Pulling out vim and searching for all occurances of "mind.dat", I find the following lines:</para><screen format="linespecific">    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 moreinfo="none">mind.dat</filename> in only one directory.  Clearly, mind.dat isn't
			in <filename moreinfo="none">/usr/share</filename>.   Now we can try to locate <filename moreinfo="none">mind.dat</filename> and move it
			into <filename moreinfo="none">/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 moreinfo="none">deallocvt N</command> kills terminal
				<literal moreinfo="none">N</literal> entirely, so that <literal moreinfo="none">Alt-FN</literal> doesn't even work
				anymore.  <command moreinfo="none">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" inheritnum="ignore" continuation="restarts"><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 moreinfo="none" 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" inheritnum="ignore" continuation="restarts"><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" inheritnum="ignore" continuation="restarts"><listitem><para>If you have X 4.0 (X 3.* users procede to step 2), look at
		the the output of <command moreinfo="none">X -probeonly</command>.  You'll see: </para><screen format="linespecific"> (II) XXXXXX: direct rendering enabled </screen><para> or </para><screen format="linespecific"> (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 moreinfo="none" 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 moreinfo="none">			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 format="linespecific">      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 format="linespecific">		     Section "DRI"
		             Mode 0666
		     EndSection
			</screen><para> This allows all non-root users to use DRI.  For the paranoid,
			it's possible to restrict DRI to only a few non-root users.  See the
			DRI User Guide.  </para></sect3><sect3><title>XFree86 3.x</title><sect4><title>Voodoo cards</title><para>Voodoo card hardware acceleration only takes place ONLY at
				16bpp color and fails silently when starting X in another color depth.
				</para><para> Also, Voodoo cards need the <filename moreinfo="none">3dfx.o</filename> kernel
				module and a <filename moreinfo="none">/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" inheritnum="ignore" continuation="restarts"><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 format="linespecific">    # 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 format="linespecific">    # 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 format="linespecific">    # 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" inheritnum="ignore" continuation="restarts"><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 moreinfo="none">ls -l /dev/dsp</literal>; it'll prolly be <literal moreinfo="none">audio</literal>.  Then, as
		root, add your non-root user to the audio group in <filename moreinfo="none">/etc/group</filename>.  For
		example, I added the users p and wellspring to group audio on my system:</para><screen format="linespecific">    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>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 moreinfo="none">apple2</filename> and X based
				<filename moreinfo="none">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 moreinfo="none">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 moreinfo="none">dosemu</application></title><para>dosemu ent<systemitem moreinfo="none" role="url">www.dosemu.org</systemitem>ent 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 moreinfo="none">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 moreinfo="none">Wabi</application> was originally created
					by SCO Unix a long time ago and then was purchased by Caldera sometime in mid year
					2001. </para><para> Wabi is fast and does a good job for what it does, although I've heard it said that
					wabi for Solaris is more stable than Linux.  It might be useful for playing older Win16
					games, but there are three problems: </para><itemizedlist><listitem><para> You must have a licensed copy of Windows 3.1/3.11 or WfW 3.11. </para></listitem><listitem><para> Wabi is awfully expensive for what it does. </para></listitem><listitem><para> Wabi doesn't work under 32bpp or 24bpp color. </para></listitem></itemizedlist><para> Wabi does NOT do DOS itself, but it looks like it can use a DOS emulator as a
					 backend for running DOS programs.  There was talk about Wabi 3.0 which would've done
					 Win32 emulation, but AFAIK, this project was shelved indefinitely.  I think Wabi
					 will run under Linux on all architectures (can someone verify this?)</para></sect3></sect2><sect2 id="win32"><title>Win32</title><sect3 id="wine"><title><application moreinfo="none">wine</application></title><para> Wine ent<systemitem moreinfo="none" role="url">www.winehq.com</systemitem>ent, 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 moreinfo="none" 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"></xref>).  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"></xref>). </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"></xref>) and prompted a fork of
					wine called ReWind (<xref linkend="rewind"></xref>).  </para></sect3><sect3 id="rewind"><title><application moreinfo="none">rewind</application></title><para> Rewind ent<systemitem moreinfo="none" role="url">http://rewind.sourceforge.net/</systemitem>ent
					was started by Eric Pouech (a wine developer) and Ove Keven (a winex developer) in
					response to wine's license change (<xref linkend="wine"></xref>).  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 moreinfo="none">winex</application></title><para> Winex is released by a company called Transgaming ent<systemitem moreinfo="none" role="url">http://www.transgaming.com</systemitem>ent.  The developers take wine (see <xref linkend="wine"></xref>) 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).

					</para></listitem></itemizedlist><para> The developers of winex were going to release their Installshield, DirectX and
					DirectDraw enhancements to wine "every so often".  In return, as wine 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"></xref>).  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"></xref>).
					</para></sect3><sect3 id="win4lin"><title>Win4Lin</title><para> Win4Lin ent<systemitem moreinfo="none" role="url">www.netraverse.com/products/win4lin30/</systemitem>ent is a commercial product
					by Netraverse.  Like vmware (<xref linkend="vmware"></xref>) 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 id="interpreters"><title>Interpreters</title><sect2><title>SCUMM Engine (LucasArts)</title><para> Lucasarts wrote an engine for point and click adventures named SCUMM (Script
			Creation Utility for Maniac Mansion).  They wrote many graphical adventures using SCUMM,
			like their famous Monkey Island series (all three).  Ludvig Strigeus
			<email>strigeus@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 ent<systemitem moreinfo="none" role="url">http://scummvm.sourceforge.net/</systemitem>ent.
			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 moreinfo="none">sarien</application> ent<systemitem moreinfo="none" role="url">sarien.sourceforge.net</systemitem>ent, 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 moreinfo="none">freesci</application>, available at <systemitem moreinfo="none" 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 ent<systemitem moreinfo="none" role="url">http://www.gnelson.demon.co.uk/zspec/index.html</systemitem>ent 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 ent<systemitem moreinfo="none" role="url">http://www.cs.csubak.edu/~dgriffi/proj/frotz/</systemitem>ent.  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 ent<systemitem moreinfo="none" role="url">http://jzip.sourceforge.net/</systemitem>ent is
			another very popular Z-machine interpreter that will run V1-V5 and V8 Z-machine data files.
			jzip is very portable; it compiles on all Unices, OS/2, Atari ST and DOS.

			</para><para> There are actually many other Z-machine interpreters like nitfol and rezrov (written in
			Perl!).  Each interpreter has its own set of strengths, and you can find links to them on the
			home pages for Frotz and jzip. </para></sect2><sect2 id="scottadams"><title>Scott Adams Adventures (Adventure International)</title><para> Scott Adams is, arguably, the father of interactive fiction.  Although he himself was
			inspired by the first piece of interactive fiction, Adventure, Scott brought adventuring to
			the masses.  His games were available for Atari, Apple 2, Commodore, Sorcerer, TI, and CPM.
			His company, Adventure International, released a number of much loved games between 1978 and
			1984 before folding.   He recently released a new game (a Linux version is not available) but
			since the decline of adventuring, he has pretty much kept out of the gaming industry. </para><para> Alan Cox wrote scottfree, a Scott Adams adventure game file interpreter for Unix.
			Using scottfree and any of the Scott Adams data files which can be downloaded from Scott's
			website ent<systemitem moreinfo="none" role="url">http://www.msadams.com/</systemitem>ent you can enjoy these
			classics. </para></sect2><sect2><title>Ultima Underworld: The Stygian Abyss (Origin, Blue Sky Productions)

			</title><para>The Underworld Adventures project ent<ulink url="http://uwadv.sourceforge.net/">uwadv.sourceforge.netent</ulink>
			is an effort to port the 1992 classic, Ultima Underworld: The Stygian Abyss, to modern operating systems like Linux, MacOS
			X, and Windows.  It uses OpenGL for 3D graphics, SDL for platform specific tasks and is released under the GNU GPL.
			Underworld Adventures provides an impressive graphics system which uses the original game files, so you'll need the
			original game disk to play.</para><para>Underworld Adventures also provides a bunch of tools for you to create your own maps, including a level map display
			program, a uw1 conversation script debugger and a tool to convert the xmi midi files to ordinary midis.</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 moreinfo="none">Exult</application> ent<systemitem moreinfo="none" role="url">http://exult.sourceforge.net/</systemitem>ent which is an open source interpreter that will run both parts of
			Ultima 7 and their addon disks.  Exult is written in C++ using SDL, so it will compile on any platform that can compile
			SDL programs.  It also features some enhancements over the original versions of the Ultima VII engine.  You'll need to
			purchase a copy of Ultima 7 to play.  The developers have no plans on extending Exult to interpret the other Ultimas since
			the engines changed so radically between releases. </para><para> The Exult team has also been hard at work creating a map editor, Exult Studio, and a script compiler that will let
			users create their own RPG in the Ultima style. </para></sect2><sect2><title>System Shock (Electronic Arts, Origin)</title><para>Although I've never played System Shock, it appears to be a classic first person shooter/adventure from 1994.  The
			game reviews I've read talk very highly about this game: apparently, its engine blows Doom out of the water and its plot
			kicks Half-life in the 'nads, which is impressive since it predates both games.</para><para>The System Shock Project Hack Project <ulink url="http://madeira.physiol.ucl.ac.uk/tsshp/sshock.html">entmadeira.physiol.ucl.ac.uk/tsshp/sshock.htmlent</ulink> is an attempt to update the game to modern operating systems.
			They use SDL, so it's available for Linux, Windows, FreeBSD and possibly other platforms that support SDL.  They use some
			open license since they're using sourceforge, but I don't see a license announcement on the website.  I think (but am not
			sure) that they use the original game files, so you'll need the original game disk to play.</para></sect2></sect1><sect1><title>Websites And Resources</title><sect2><title>Meta gaming websites</title><variablelist><varlistentry><term>The Linux Game Tome:
				<systemitem moreinfo="none" role="url">www.happypenguin.org</systemitem></term><listitem><para> About the games themselves. </para></listitem></varlistentry><varlistentry><term>linuxgames:
				<systemitem moreinfo="none" role="url">www.linuxgames.com</systemitem></term><listitem><para> Linux gaming news </para></listitem></varlistentry><varlistentry><term>				<systemitem moreinfo="none" 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 ent<systemitem moreinfo="none" role="url">www.tuxgames.com</systemitem>ent 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 moreinfo="none" 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 moreinfo="none" 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 moreinfo="none" role="url">http://www.linuxgames.com/articles/lokitimeline/</systemitem>
					</para></listitem></varlistentry><varlistentry><term>Tribsoft: <systemitem moreinfo="none" 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 moreinfo="none" 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 moreinfo="none" 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 moreinfo="none" 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 moreinfo="none" role="url">www.xfree86.org</systemitem></term><listitem><para>XFree86 home page</para></listitem></varlistentry><varlistentry><term>Linux Game Development Center: 
					<systemitem moreinfo="none" 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 moreinfo="none" 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.</para></listitem></varlistentry></variablelist></sect2></sect1></article>

