LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2002-01-28 20:15:13 +00:00
parent f5309a145e
commit 4782172536
1 changed files with 198 additions and 229 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

427
LDP/howto/docbook/Linux-Gamers-HOWTO.sgml
View File

@ -26,7 +26,7 @@
</affiliation>
</author>
<pubdate>v0.9.8, 2002-01-22</pubdate>
<pubdate>v.0.9.8, 2002-01-28</pubdate>
<copyright>
<year>2001</year>
@ -67,16 +67,16 @@
<sect1 id="administrata"><title>Administra</title>
<para> If you have ideas, corrections or questions relating to this HOWTO, please email me. By
<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
like I'm doing something useful. In turn, it motivates me to write more and add to this
document. You can reach me at <email>p@dirac.org</email>. My web page is <systemitem
role="url">www.dirac.org/p</systemitem> and my Linux pages are at <systemitem
role="url">www.dirac.org/linux</systemitem>. Please do send comments and suggestions for this
howto. Even if I don't take your suggestions, your input is graciously received. </para>
<para> I assume a working knowledge of Linux, so I use some topics like runlevels and modules
without defining them. If there are enough questions (or even protests!) I'll add more basic
without defining them. If there are enough questions (or even protests!) I'll add more basic
information to this document. </para>
@ -118,7 +118,7 @@
role="url">www.dirac.org/linux/writing</systemitem>. </para>
<para> Dmitry Samoyloff, <email>dsamoyloff@mail.ru</email>, is the maintainer of the
Russian translation of this HOWTO. The most recent version can be found at <systemitem
Russian translation of this HOWTO. The most recent version can be found at <systemitem
role="url">linuxgames.hut.ru/data/docs/HOWTO/LG-HOWTO-ru.html</systemitem>. </para>
</sect2>
@ -170,17 +170,17 @@
<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'. They were self contained
adventures were the game of choice of `intelligent folk'. They were self contained
executables on disks (even casettes). These days we're a bit more sophisticated than
that. Now there's usually a data file and an interpreter. The interpreter reads data
files and provides the gaming interface. The data file is the actual game, and is often
files and provides the gaming interface. The data file is the actual game, and is often
implemented by a scripting language. So for example, you you could have the two Scott
Adams datafiles &ldquo;The Count.dat&rdquo; and &ldquo;Voodoo Castle.dat&rdquo;. To
Adams datafiles &ldquo;The Count.dat&rdquo; and &ldquo;Voodoo Castle.dat&rdquo;. To
actually play the games, you'd invoke the scottfree interpreter with the name of the
datafile you wish to play. </para>
<para> The first adventure game was Adventure (actually &ldquo;ADVENT&rdquo;,
written on a PDP-1 in 1972). You can play adventure yourself (actually, a
written on a PDP-1 in 1972). You can play adventure yourself (actually, a
descendent); it comes with &ldquo;bsd games&rdquo; on most Linux distros. </para>
<para> They became popularized by Scott Adams, who is widely considered to be the father
@ -189,13 +189,13 @@
the old data files, which are now shareware and can be download from Scott Adams' website.
</para>
<para> Text adventures climaxed in the 80's with Infocom. There are many Infocom
<para> Text adventures climaxed in the 80's with Infocom. There are many Infocom
interpreters available for Linux; the most popular one being
<application>frotz</application>. You still need the data files, and these are all still
owned and considered commercial property by Activision. </para>
<para> As computer graphics became easier and more powerful, text adventures gave
rise to graphic adventures. The death of interactive fiction more or less coincided
rise to graphic adventures. The death of interactive fiction more or less coincided
with the bankruptcy of Infocom. </para>
</sect2>
@ -257,10 +257,10 @@
<sect2><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 or
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 or
illegal drug selling operation (SimCity or DrugWars). The scenario can also be
total all-out war strategy game like Myth II. The types of games usually take a long
total 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.
@ -286,14 +286,14 @@
great under <application>winex</application>!) 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, look
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. Some are set in fantasy (Hexen), others are
<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, look
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. Some are set in fantasy (Hexen), others are
science fiction (Quake II), and some are set in the present day `real world' (Soldier Of
Fortune). </para>
<para> Just like text adventures, FPS fit the engine/datafile format. The engine refers to
<para> Just like text adventures, FPS fit the engine/datafile format. The engine refers to
the actual game itself (Doom, Quake, Heretic2) and plays out the maps and bad guys
outlined by the datafile (doom2.wad, pak0.pak, etc). Many FPS games allow people to write
their own non-commercial datafile. There are hundreds, even thousands of non-commercial
@ -322,7 +322,7 @@
<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
style back flips and side rolls. The canonical example would be Tomb Raider. On the
Linux platform, we have Heretic 2 and Heavy Metal FAKK. </para>
</sect2>
@ -336,13 +336,13 @@
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
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
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> The canonical RPG on Linux is Rogue (the ncurses library can be traced back to the
@ -398,7 +398,7 @@
<sect2><title>What is Glide3?</title>
<para> Glide3 is not a direct API used to program a game with, unlike Glide2. It exists
only to support DRI on Voodoo III, IV and V boards under XFree86 4.*. None of the games
only to support DRI on Voodoo III, IV and V boards under XFree86 4.*. None of the games
which use Glide2 will work with Glide3. This shouldn't be a surprise since Glide2 and Glide
3 support different video boards and different versions of XFree86. The only video card
that can use both Glide2 (under XFree86 3.*) and Glide3 (under XFree86 4.*) is the Voodoo
@ -418,7 +418,7 @@
<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 is defined and
maintained by the Architectural Revision Board (ARB), an organization whose include SGI,
IBM, DEC, and Microsoft. OpenGL provides a powerful, complete and generic feature set for
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>
@ -436,7 +436,7 @@
<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
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.
@ -471,40 +471,34 @@
</sect2>
<!-- here -->
<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 with X 4.* with Direct Rendering Infrastructure (DRI).
The direct rendering infrastructure allows X clients to write 3D
rendering information directly to the video card in a safe and
cooperative manner. </para>
<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 with X 4.* with Direct Rendering
Infrastructure (DRI). The direct rendering infrastructure 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>
<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 doesn't have to be sent over a socket to
the X server.</para></listitem>
<listitem><para>On single processor machines the CPU doesn't have to
change context between X and its client to render the graphics.</para>
<listitem><para> Vertex data doesn't have to be encoded/decoded via GLX. </para>
</listitem>
<listitem><para> Graphics data doesn't have to be sent over a socket to the X server.
</para> </listitem>
<listitem><para> On single processor machines the CPU doesn't have to change context
between X and its client to render the graphics. </para> </listitem>
</itemizedlist>
</sect2>
@ -512,8 +506,8 @@
<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>
<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>
@ -521,21 +515,19 @@
<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. (For instance, it relies on root privileges rather than
creating the kernel infrastructure necessary for secure access). It
provides support for (at this time) a couple cards which are not
well-supported in DRI. Particularly, 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
<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. (For instance, it
relies on root privileges rather than creating the kernel infrastructure necessary for
secure access). It provides support for (at this time) a couple cards which are not
well-supported in DRI. Particularly, 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>
<para> As a side note, until the G400 stuff is *really* fixed in DRI,
it's also the better G400 support&mdash;but hopefully that will not be an
issue by the time this HOWTO is published. </para>
<para> As a side note, until the G400 stuff is *really* fixed in DRI, it's also the better
G400 support&mdash;but hopefully that will not be an issue by the time this HOWTO is
published. </para>
</sect2>
@ -543,112 +535,103 @@
<sect2><title>What is xlib?</title>
<para> Every once in awhile you'll see some sicko (said with respect)
write a game in xlib, otherwise I wouldn't even mention xlib here. xlib
is a set of C libraries which comprise of the lowest level of programming
for XFree86. Any graphics programming in X ultimately makes use of the
xlib library. </para>
<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 arcane and
complicated. I'd say it's the most difficult and time consuming
programming endeavor there is. A program that simply connects to an X
server, puts up a window and does absolutely nothing else could be a 40
line program with arcane and very long-named functions. Because of this,
there are lots of libraries which hide the details of xlib programming.
Some of these libraries focus on drawing in windows (like SDL). Other
libraries are more concerned with widgets within windows (eg pulldown
menus, radio buttons and text boxes); these types of libraries are
appropriately named widget sets. Gtk is the canonical widget set on
Linux, but there are many others like fltk (a small widget set for use
with C++), Xaw and Qt (the widget set of KDE). You might have heard of
Motif; that's what Netscape uses. Motif used to be king of the unix
world, but was VERY expensive to license. The Open Group opened up
Motif's license, but it was too little too late. Lesstif (a Motif
clone), Gtk and Qt were the supreme widget sets. </para>
<para> It's not an understatement to say that xlib is arcane and complicated. A program
that simply connects to an X server, puts up a window and does nothing else could be a
complicated 40 line program with arcane and very long named functions. Because of this,
there are lots of libraries which hide the details of xlib programming. Some of these
libraries focus on drawing in windows (like SDL). Other libraries are more concerned with
widgets within windows (eg pulldown menus, radio buttons and text boxes); these types of
libraries are called widget sets. 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 king of the Unix world, but was very
expensive to license. The Open Group opened up Motif's license for non-commercial use, but
it was too little too late. People now use Lesstif, a Motif clone. </para>
</sect2>
<sect2><title>What is SDL?</title>
<para> SDL (Simple DirectMedia Layer) is a library by Loki Software's 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.
The 40 line arcane program I mentioned in the xlib section can easily be
written in 6 lines of straightforward code using SDL. </para>
<para> SDL (Simple DirectMedia Layer) is a library by Loki Software's 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. The 40 line arcane program I mentioned in the xlib section can easily be written in 6
lines of straightforward code using SDL. </para>
<para> The most striking part of SDL is that it's a cross platform
library. Except for a few details about header files and compiling, a
program written in SDL will compile under Linux, *BSD, Windows*, MacOS
and BeOS. There are SDL extentions written by various people to do
things like handle any graphics format you care to mention, play mpeg
movies, display truetype fonts, sprite handling and just about everything
under the sun. Clearly, SDL is an example of what all graphics libraries
should strive for. The one deficiency is a lack of documentation (sigh),
but I understand an SDL book is on its way. If you're a game programmer,
do the rest of the world a favor and use SDL. </para>
<para> The most striking part of SDL is that it's a cross platform library. Except for a
few details about header files and compiling, a program written in SDL will compile under
Linux, MS Windows, BeOS, MacOS, MacOS X, Solaris, IRIX, FreeBSD, QNX and OSF. There are SDL
extentions written by various people to do things like handle any graphics format you care
to mention, play mpegs, display truetype fonts, sprite handling and just about everything
under the sun. SDL is an example of what all graphics libraries should strive for.
</para>
<para> Sam had an ulterior motive for writing such a cool library. He's
the lead programmer for Loki Software, which has used SDL in all of its
games except for Quake3. </para>
<para> Sam had an ulterior motive for writing such a cool library. He's was the lead
programmer for Loki Software, which used SDL in all of its games except for Quake3. </para>
</sect2>
<sect2><title>What is GGI?</title>
<para> GGI is seemingly now-defucnt project which headed for implementing
graphics abstraction layer uniformly to lower code duplication, ease
graphics hardware support in one place and bring higher stability and
portability, also replacing svgalib, fb, and X servers dealing directly
with hardware. </para>
<para> GGI is seemingly now-defunct project which aimed to implement the graphics
abstraction layer in lower level code, putting graphics hardware support in one place,
bringing higher stability and portability to graphics applications and replacing SVGAlib,
fb, and X servers dealing directly with hardware. </para>
<para> GGI was supposed to have a kernel module inserted into the Linux
source code but Linus thought their code wasn't ready for production
kernels. There was brief talk about making *BSD their main platform.
It's been ages since I've heard anything about GGI. </para>
<para> GGI was supposed to have a kernel module inserted into the Linux source code but
Linus thought their code wasn't ready for production kernels. There was brief talk about
making *BSD their main platform. It's been ages since I've heard anything about GGI.
</para>
</sect2>
<sect2><title>What is SVGAlib? Frame buffer? Console?</title>
<para> In case nobody told you, the console is the dark non-graphical
screen you look at when your computer first boots up (and you don't have
have xdm or gdm 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 &ldquo;no graphics&rdquo;. There are
certainly graphics on the console&mdash;they are extremely fullscreen,
extremely fast, and extremely compelling. </para>
<para> The console is the dark non-graphical screen you look at when your computer first
boots up (and you don't have have <application>xdm</application> or
<application>gdm</application> running). This is opposed to the X environment which has all
sorts of GUI things like xterms. It's a common misconception that X means graphics and
console means no graphics. There are certainly graphics on the console&mdash;we will
discuss the two most common ways to achieve this. </para>
<para> SVGAlib is a graphics library that lets you draw graphics on the
the console. There are many games that use SVGAlib, and I happen to be a
big fan of this library and of graphical console games in general.
SVGAlib gets a small rap on the knuckes because executables need to be
run by root or be setuid, but the library only needs to run as root when
the application first starts. It releases rootly status immediately.
</para>
<para> SVGAlib is a graphics library that lets you draw graphics on the the console. There
are many graphical applications and games that use SVGAlib like
<application>zgv</application> (a console graphical image viewer),
<application>prboom</application> and <application>hhexen</application>. I happen to be a
fan of this library and of graphical console games in general; they are extremely fast,
fullscreen and compelling. There are three downsides to SVGAlib. First, SVGAlib
executables need to be run by root or be setuid root, however, the library releases root
status immediately after the executable begins to run. Secondly, SVGAlib is video card
dependent&ndash;if your video card isn't supported by SVGAlib, you're out of luck. Third,
SVGAlib is Linux only. Games written in SVGAlib will only work on Linux. </para>
<para> Frame buffers are like the console, but they're implemented as a
graphics mode rather than a text mode. Why would you want to simulate
text mode from a graphical environment? This allows us to run graphical
things, like postscript viewers from the console environment. It also
allows us to pick and choose not only what font size we want our console
to be, but what font we want console text to be! Imagine having a
console font of Comic Sans MS? There is a good Frame Buffer howto
available from LDP. </para>
<para> Frame buffers are consoles implemented by a graphics mode rather than a BIOS text
mode. Why would you want to simulate text mode from a graphical environment? This allows
us to run graphical things in console, like allowing us to choose what font we want the
console to display (which is normally determined by BIOS). Imagine having a console font of
Comic Sans MS? There's a good Frame Buffer howto available from LDP. </para>
</sect2>
<sect2><title>What is OpenAL?</title>
<para> OpenAL aims to be for sound what OpenGL is for graphics. Jointly
developed by Loki Software and Creative Labs, it sets out to be a vendor
neutral and cross platform API for audio. It is licensed LGPL and the specs
can be had for free from the OpenAL website. </para>
<para> OpenAL aims to be for sound what OpenGL is for graphics. Jointly developed by Loki
Software and Creative Labs, it sets out to be a vendor neutral and cross platform API for
audio. It is licensed LGPL and the specs can be had for free from the OpenAL website.
OpenAL is fully functional, but now that Loki Software is no more its future development is
questionable. </para>
</sect2>
@ -659,18 +642,17 @@
<sect1><title>Definitions: Video Card and 3D Terminology</title>
<para>We'll cover terminology that you'll see when reading about video cards
and games. This stuff isn't crucial to actually getting a game working, but
will help when deciding what hardware and software options are best for
you.</para>
<para> We'll cover videocard and 3D graphics terminology. This stuff isn't crucial to actually
getting a game working, but may help in deciding what hardware and software options are best for
you. </para>
<sect2><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>
<para> A rendered scene is basically made up of polygons and lines. A texture is a 2D image
(usually a bitmap) covering the polygons of a 3D world. Think of it as a coat of paint for
the polygons. </para>
</sect2>
@ -678,9 +660,8 @@ you.</para>
<sect2><title>T&amp;L: Transform and Lighting</title>
<para> The T&amp;L is the process of translating all the 3D world
information (position, distance, and light sources) into the 2D image that
is actually displayed on screen. </para>
<para> The T&amp;L is the process of translating all the 3D world information (position,
distance, and light sources) into the 2D image that is actually displayed on screen. </para>
</sect2>
@ -688,26 +669,22 @@ you.</para>
<sect2><title>AA: Anti Aliasing</title>
<para> Anti aliasing is the smoothing of jagged edges along a rendered
curve or polygon. Individual pixels are square objects, and drawing an
angled line or curve with them will result in a &ldquo;stair-step&rdquo;
effect, also known as the &ldquo;jaggies&rdquo;. This is when pixels
make, what should be a smooth curve or line, jagged. AA uses
computationally expensive filtering techniques to smooth out these jagged
edges. This can improve a game's visuals, but can also dramatically
degrade performance. </para>
<para> Anti aliasing is the smoothing of jagged edges along a rendered curve or polygon.
Pixels are square 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 actually used in a number of situations, For instance, when
you magnify a picture, you'll notice lines that were once smooth are now
jagged (try it with The Gimp!). Font rendering is another big
application for AA techniques. </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 are now 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>
<para> AA can be done either by the application itself (as with The Gimp or the XFree86 font
system) or by hardware, if your video card supports it. Since AA is CPU intensive, it's
more desirable to perform it in hardware, but if we're talking about semi-static
applications, like The Gimp, this really isn't an issue. For dynamic situations, like
games, doing AA in hardware can be crucial. </para>
</sect2>
@ -715,15 +692,15 @@ you.</para>
<sect2><title>FSAA: Full Screen Anti-Aliasing</title>
<para> FSAA is &ldquo;Full Screen Anti-Aliasing&rdquo;. It 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>
<para> FSAA usually involves drawing a magnified version of the entire screen in a separate
framebuffer, performing AA on the entire image and rescaling it back to the normal
resolution. As you can imagine, this is extremely CPU intensive. You will never see non
hardware accelerated FSAA. </para>
</sect2>
<!-- here -->
<sect2><title>Mip Mapping</title>
@ -738,23 +715,23 @@ you.</para>
</sect2>
<sect2><title>Texture Filtering</title>
<para> Texture filtering is the fundamental feature required to present
the 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> 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> One thing to keep in mind is that when I talk about `performance
hits', 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>
<para> One thing to keep in mind is that when I talk about `performance hits', 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>
</sect2>
@ -762,9 +739,9 @@ you.</para>
<sect2><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>
<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>
</sect2>
@ -772,11 +749,10 @@ you.</para>
<sect2><title>Bilinear Texture Filtering</title>
<para> Bilinear filtering is a computationally inexpensive 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>
<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>
</sect2>
@ -784,15 +760,13 @@ you.</para>
<sect2><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 these before rendering, twice as much as
bi-linear does. Trilinear filtering always uses mip mapping. Trilinear
filtering helps eliminate the banding effect that appears between adjacent
MIP map levels. Most modern 3D accelerated video cards can perform
trilinear filtering in hardware with little or no performance hit.
</para>
<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 these before rendering,
twice as much as bi-linear does. 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>
</sect2>
@ -800,14 +774,12 @@ you.</para>
<sect2><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 way. 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>
<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 way. 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>
</sect2>
@ -815,20 +787,18 @@ you.</para>
<sect2><title>Z Buffering</title>
<para> A Z buffer is a portion of RAM which represents the distance
between the viewer (you) and each pixel of an object. Many modern 3D
accelerated cards have a Z buffer in their video RAM, which speeds things
up considerably, but Z buffering can also be done by the application's
rendering engine. </para>
<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. </para>
<para> Every object or pixel 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 simply draw far objects first and close objects
last, obscuring objects below them in the Z buffer. Smart engines will
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>
<para> Every object has a stacking order, like a deck of cards. When objects are rendered
into a 2D frame buffer, the rendering engine removes hidden surfaces by using the Z buffer.
There are two approaches to this. Dumb engines draw far objects first and close objects
last, obscuring objects below them in the Z buffer. Smart engines calculate what portions
of objects will be obscured by objects above them and simply not render the portions that
you won't see anyhow. For complicated textures this is a huge savings in processor work.
</para>
</sect2>
@ -838,7 +808,6 @@ you.</para>
<sect1><title>XFree86 and You</title>
<para> If you're going to game under X, it's crucial that you know a bit
@ -2403,6 +2372,6 @@ you.</para>
<!--
vim:textwidth=96
vim:textwidth=96:
-->