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