mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
f5309a145e
commit
4782172536
|
@ -26,7 +26,7 @@
|
||||||
</affiliation>
|
</affiliation>
|
||||||
</author>
|
</author>
|
||||||
|
|
||||||
<pubdate>v0.9.8, 2002-01-22</pubdate>
|
<pubdate>v.0.9.8, 2002-01-28</pubdate>
|
||||||
|
|
||||||
<copyright>
|
<copyright>
|
||||||
<year>2001</year>
|
<year>2001</year>
|
||||||
|
@ -471,40 +471,34 @@
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
||||||
<!-- here -->
|
|
||||||
|
|
||||||
|
|
||||||
<sect2><title>What is DRI?</title>
|
<sect2><title>What is DRI?</title>
|
||||||
|
|
||||||
<para> Graphics rendering has 3 players: the client application (like
|
<para> Graphics rendering has 3 players: the client application (like Quake 3), the X server
|
||||||
Quake 3), the X server and the hardware (the graphics card). Previously,
|
and the hardware (the graphics card). Previously, client applications were prohibited from
|
||||||
client applications were prohibited from writing directly to hardware,
|
writing directly to hardware, and there was a good reason for this. A program that is
|
||||||
and there was a good reason for this. A program that is allowed to
|
allowed to directly write to hardware can crash the system in any number of ways. Rather
|
||||||
directly write to hardware can crash the system in any number of ways.
|
than trusting programmers to write totally bug free, cooperative programs that access
|
||||||
Rather than trusting programmers to write totally bug free, cooperative
|
hardware, Linux simply disallowed it. However, that changed with X 4.* with Direct Rendering
|
||||||
programs that access hardware, Linux simply disallowed it. However, that
|
Infrastructure (DRI). The direct rendering infrastructure allows X clients to write 3D
|
||||||
changed with X 4.* with Direct Rendering Infrastructure (DRI).
|
rendering information directly to the video card in a safe and cooperative manner. </para>
|
||||||
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
|
<para> DRI gets the X server out of the way so the 3D driver (Mesa or OpenGL) can talk
|
||||||
OpenGL) can talk directly to the hardware. This speeds things up. The
|
directly to the hardware. This speeds things up. The 3D rendering information doesn't even
|
||||||
3D rendering information doesn't even have to be hardware accelerated.
|
have to be hardware accelerated. On a technical note, this has a number of virtues.
|
||||||
On a technical note, this has a number of virtues. </para>
|
</para>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
|
|
||||||
<listitem><para>Vertex data doesn't have to be encoded/decoded via GLX.
|
<listitem><para> Vertex data doesn't have to be encoded/decoded via GLX. </para>
|
||||||
</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>
|
</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>
|
</itemizedlist>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
@ -512,8 +506,8 @@
|
||||||
|
|
||||||
<sect2><title>What is GLX?</title>
|
<sect2><title>What is GLX?</title>
|
||||||
|
|
||||||
<para> GLX is the X extension used by OpenGL programs, it is the glue
|
<para> GLX is the X extension used by OpenGL programs, it is the glue between the platform
|
||||||
between the platform independent OpenGL and platform dependent X. </para>
|
independent OpenGL and platform dependent X. </para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -521,21 +515,19 @@
|
||||||
|
|
||||||
<sect2><title>What is Utah GLX?</title>
|
<sect2><title>What is Utah GLX?</title>
|
||||||
|
|
||||||
<para> Utah-GLX is the precursor to DRI. It makes some different design
|
<para> Utah-GLX is the precursor to DRI. It makes some different design decisions,
|
||||||
decisions, regarding separation of data and methods of accessing the
|
regarding separation of data and methods of accessing the video card. (For instance, it
|
||||||
video card. (For instance, it relies on root privileges rather than
|
relies on root privileges rather than creating the kernel infrastructure necessary for
|
||||||
creating the kernel infrastructure necessary for secure access). It
|
secure access). It provides support for (at this time) a couple cards which are not
|
||||||
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
|
||||||
well-supported in DRI. Particularly, the ATI Rage Pro family, S3 Virge
|
using this for gaming is, well, nuts), and an open source TNT/TNT2 driver (which is very
|
||||||
(although anyone using this for gaming is, well, nuts), and an open
|
incomplete). The TNT/TNT2 driver is based on reverse-engineering of the obfuscated source
|
||||||
source TNT/TNT2 driver (which is very incomplete). The TNT/TNT2 driver
|
code release of the X 3.3 drivers by nVidia. However, they're really incomplete, and
|
||||||
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>
|
effectively, unusable. </para>
|
||||||
|
|
||||||
<para> As a side note, until the G400 stuff is *really* fixed in DRI,
|
<para> As a side note, until the G400 stuff is *really* fixed in DRI, it's also the better
|
||||||
it's also the better G400 support—but hopefully that will not be an
|
G400 support—but hopefully that will not be an issue by the time this HOWTO is
|
||||||
issue by the time this HOWTO is published. </para>
|
published. </para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -543,112 +535,103 @@
|
||||||
|
|
||||||
<sect2><title>What is xlib?</title>
|
<sect2><title>What is xlib?</title>
|
||||||
|
|
||||||
<para> Every once in awhile you'll see some sicko (said with respect)
|
<para> Every once in awhile you'll see some sicko (said with respect) write a game in xlib.
|
||||||
write a game in xlib, otherwise I wouldn't even mention xlib here. xlib
|
It is a set of C libraries which comprise the lowest level programming interface for
|
||||||
is a set of C libraries which comprise of the lowest level of programming
|
XFree86. Any graphics programming in X ultimately makes use of the xlib library. </para>
|
||||||
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
|
<para> It's not an understatement to say that xlib is arcane and complicated. A program
|
||||||
complicated. I'd say it's the most difficult and time consuming
|
that simply connects to an X server, puts up a window and does nothing else could be a
|
||||||
programming endeavor there is. A program that simply connects to an X
|
complicated 40 line program with arcane and very long named functions. Because of this,
|
||||||
server, puts up a window and does absolutely nothing else could be a 40
|
there are lots of libraries which hide the details of xlib programming. Some of these
|
||||||
line program with arcane and very long-named functions. Because of this,
|
libraries focus on drawing in windows (like SDL). Other libraries are more concerned with
|
||||||
there are lots of libraries which hide the details of xlib programming.
|
widgets within windows (eg pulldown menus, radio buttons and text boxes); these types of
|
||||||
Some of these libraries focus on drawing in windows (like SDL). Other
|
libraries are called widget sets. Gtk is the canonical widget set on Linux, but there are
|
||||||
libraries are more concerned with widgets within windows (eg pulldown
|
many others like fltk (a small C++ widget set), Xaw, Qt (the widget set of KDE), and Motif
|
||||||
menus, radio buttons and text boxes); these types of libraries are
|
(the widget set used by Netscape). Motif used to be king of the Unix world, but was very
|
||||||
appropriately named widget sets. Gtk is the canonical widget set on
|
expensive to license. The Open Group opened up Motif's license for non-commercial use, but
|
||||||
Linux, but there are many others like fltk (a small widget set for use
|
it was too little too late. People now use Lesstif, a Motif clone. </para>
|
||||||
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>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<sect2><title>What is SDL?</title>
|
<sect2><title>What is SDL?</title>
|
||||||
|
|
||||||
<para> SDL (Simple DirectMedia Layer) is a library by Loki Software's Sam
|
<para> SDL (Simple DirectMedia Layer) is a library by Loki Software's Sam Lantiga (graduate
|
||||||
Lantiga (graduate of UCD, yeah!!). It's actually a meta-library, meaning
|
of UCD, yeah!). It's actually a meta-library, meaning that not only is it a graphics
|
||||||
that not only is it a graphics library which hides the details of xlib
|
library which hides the details of xlib programming, it provides an easy interface for
|
||||||
programming, it provides an easy interface for sound, music and event
|
sound, music and event handling. It's LGPL'd and provides joystick and OpenGL support as
|
||||||
handling. It's LGPL'd and provides joystick and OpenGL support as well.
|
well. The 40 line arcane program I mentioned in the xlib section can easily be written in 6
|
||||||
The 40 line arcane program I mentioned in the xlib section can easily be
|
lines of straightforward code using SDL. </para>
|
||||||
written in 6 lines of straightforward code using SDL. </para>
|
|
||||||
|
|
||||||
<para> The most striking part of SDL is that it's a cross platform
|
<para> The most striking part of SDL is that it's a cross platform library. Except for a
|
||||||
library. Except for a few details about header files and compiling, a
|
few details about header files and compiling, a program written in SDL will compile under
|
||||||
program written in SDL will compile under Linux, *BSD, Windows*, MacOS
|
Linux, MS Windows, BeOS, MacOS, MacOS X, Solaris, IRIX, FreeBSD, QNX and OSF. There are SDL
|
||||||
and BeOS. There are SDL extentions written by various people to do
|
extentions written by various people to do things like handle any graphics format you care
|
||||||
things like handle any graphics format you care to mention, play mpeg
|
to mention, play mpegs, display truetype fonts, sprite handling and just about everything
|
||||||
movies, display truetype fonts, sprite handling and just about everything
|
under the sun. SDL is an example of what all graphics libraries should strive for.
|
||||||
under the sun. Clearly, SDL is an example of what all graphics libraries
|
</para>
|
||||||
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> Sam had an ulterior motive for writing such a cool library. He's
|
<para> Sam had an ulterior motive for writing such a cool library. He's was the lead
|
||||||
the lead programmer for Loki Software, which has used SDL in all of its
|
programmer for Loki Software, which used SDL in all of its games except for Quake3. </para>
|
||||||
games except for Quake3. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<sect2><title>What is GGI?</title>
|
<sect2><title>What is GGI?</title>
|
||||||
|
|
||||||
<para> GGI is seemingly now-defucnt project which headed for implementing
|
<para> GGI is seemingly now-defunct project which aimed to implement the graphics
|
||||||
graphics abstraction layer uniformly to lower code duplication, ease
|
abstraction layer in lower level code, putting graphics hardware support in one place,
|
||||||
graphics hardware support in one place and bring higher stability and
|
bringing higher stability and portability to graphics applications and replacing SVGAlib,
|
||||||
portability, also replacing svgalib, fb, and X servers dealing directly
|
fb, and X servers dealing directly with hardware. </para>
|
||||||
with hardware. </para>
|
|
||||||
|
|
||||||
<para> GGI was supposed to have a kernel module inserted into the Linux
|
<para> GGI was supposed to have a kernel module inserted into the Linux source code but
|
||||||
source code but Linus thought their code wasn't ready for production
|
Linus thought their code wasn't ready for production kernels. There was brief talk about
|
||||||
kernels. There was brief talk about making *BSD their main platform.
|
making *BSD their main platform. It's been ages since I've heard anything about GGI.
|
||||||
It's been ages since I've heard anything about GGI. </para>
|
</para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<sect2><title>What is SVGAlib? Frame buffer? Console?</title>
|
<sect2><title>What is SVGAlib? Frame buffer? Console?</title>
|
||||||
|
|
||||||
<para> In case nobody told you, the console is the dark non-graphical
|
<para> The console is the dark non-graphical screen you look at when your computer first
|
||||||
screen you look at when your computer first boots up (and you don't have
|
boots up (and you don't have have <application>xdm</application> or
|
||||||
have xdm or gdm running). This is opposed to the X environment which has
|
<application>gdm</application> running). This is opposed to the X environment which has all
|
||||||
all sorts of GUI things like xterms. It's a common misconception that X
|
sorts of GUI things like xterms. It's a common misconception that X means graphics and
|
||||||
means graphics and console means “no graphics”. There are
|
console means no graphics. There are certainly graphics on the console—we will
|
||||||
certainly graphics on the console—they are extremely fullscreen,
|
discuss the two most common ways to achieve this. </para>
|
||||||
extremely fast, and extremely compelling. </para>
|
|
||||||
|
|
||||||
<para> SVGAlib is a graphics library that lets you draw graphics on the
|
<para> SVGAlib is a graphics library that lets you draw graphics on the the console. There
|
||||||
the console. There are many games that use SVGAlib, and I happen to be a
|
are many graphical applications and games that use SVGAlib like
|
||||||
big fan of this library and of graphical console games in general.
|
<application>zgv</application> (a console graphical image viewer),
|
||||||
SVGAlib gets a small rap on the knuckes because executables need to be
|
<application>prboom</application> and <application>hhexen</application>. I happen to be a
|
||||||
run by root or be setuid, but the library only needs to run as root when
|
fan of this library and of graphical console games in general; they are extremely fast,
|
||||||
the application first starts. It releases rootly status immediately.
|
fullscreen and compelling. There are three downsides to SVGAlib. First, SVGAlib
|
||||||
</para>
|
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 like the console, but they're implemented as a
|
<para> Frame buffers are consoles implemented by a graphics mode rather than a BIOS text
|
||||||
graphics mode rather than a text mode. Why would you want to simulate
|
mode. Why would you want to simulate text mode from a graphical environment? This allows
|
||||||
text mode from a graphical environment? This allows us to run graphical
|
us to run graphical things in console, like allowing us to choose what font we want the
|
||||||
things, like postscript viewers from the console environment. It also
|
console to display (which is normally determined by BIOS). Imagine having a console font of
|
||||||
allows us to pick and choose not only what font size we want our console
|
Comic Sans MS? There's a good Frame Buffer howto available from LDP. </para>
|
||||||
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>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<sect2><title>What is OpenAL?</title>
|
<sect2><title>What is OpenAL?</title>
|
||||||
|
|
||||||
<para> OpenAL aims to be for sound what OpenGL is for graphics. Jointly
|
<para> OpenAL aims to be for sound what OpenGL is for graphics. Jointly developed by Loki
|
||||||
developed by Loki Software and Creative Labs, it sets out to be a vendor
|
Software and Creative Labs, it sets out to be a vendor neutral and cross platform API for
|
||||||
neutral and cross platform API for audio. It is licensed LGPL and the specs
|
audio. It is licensed LGPL and the specs can be had for free from the OpenAL website.
|
||||||
can be had for free from the OpenAL website. </para>
|
OpenAL is fully functional, but now that Loki Software is no more its future development is
|
||||||
|
questionable. </para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -659,18 +642,17 @@
|
||||||
|
|
||||||
<sect1><title>Definitions: Video Card and 3D Terminology</title>
|
<sect1><title>Definitions: Video Card and 3D Terminology</title>
|
||||||
|
|
||||||
<para>We'll cover terminology that you'll see when reading about video cards
|
<para> We'll cover videocard and 3D graphics terminology. This stuff isn't crucial to actually
|
||||||
and games. This stuff isn't crucial to actually getting a game working, but
|
getting a game working, but may help in deciding what hardware and software options are best for
|
||||||
will help when deciding what hardware and software options are best for
|
you. </para>
|
||||||
you.</para>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<sect2><title>Textures</title>
|
<sect2><title>Textures</title>
|
||||||
|
|
||||||
<para> A rendered scene is basically made up of polygons and lines. A
|
<para> A rendered scene is basically made up of polygons and lines. A texture is a 2D image
|
||||||
texture is a 2D image (usually a bitmap) covering the polygons of a 3D
|
(usually a bitmap) covering the polygons of a 3D world. Think of it as a coat of paint for
|
||||||
world. Think of it as a coat of paint for the polygons. </para>
|
the polygons. </para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -678,9 +660,8 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>T&L: Transform and Lighting</title>
|
<sect2><title>T&L: Transform and Lighting</title>
|
||||||
|
|
||||||
<para> The T&L is the process of translating all the 3D world
|
<para> The T&L is the process of translating all the 3D world information (position,
|
||||||
information (position, distance, and light sources) into the 2D image that
|
distance, and light sources) into the 2D image that is actually displayed on screen. </para>
|
||||||
is actually displayed on screen. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -688,26 +669,22 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>AA: Anti Aliasing</title>
|
<sect2><title>AA: Anti Aliasing</title>
|
||||||
|
|
||||||
<para> Anti aliasing is the smoothing of jagged edges along a rendered
|
<para> Anti aliasing is the smoothing of jagged edges along a rendered curve or polygon.
|
||||||
curve or polygon. Individual pixels are square objects, and drawing an
|
Pixels are square objects, so drawing an angled line or curve with them results in a `stair
|
||||||
angled line or curve with them will result in a “stair-step”
|
step' effect, also called the jaggies. This is when pixels make, what should be a smooth
|
||||||
effect, also known as the “jaggies”. This is when pixels
|
curve or line, jagged. AA uses CPU intensive filtering to smooth out these
|
||||||
make, what should be a smooth curve or line, jagged. AA uses
|
jagged edges. This improves a game's visuals, but can also dramatically degrade
|
||||||
computationally expensive filtering techniques to smooth out these jagged
|
performance. </para>
|
||||||
edges. This can improve a game's visuals, but can also dramatically
|
|
||||||
degrade performance. </para>
|
|
||||||
|
|
||||||
<para> AA is actually used in a number of situations, For instance, when
|
<para> AA is used in a number of situations. For instance, when you magnify a picture,
|
||||||
you magnify a picture, you'll notice lines that were once smooth are now
|
you'll notice lines that were once smooth are now jagged (try it with The Gimp). Font
|
||||||
jagged (try it with The Gimp!). Font rendering is another big
|
rendering is another big application for AA. </para>
|
||||||
application for AA techniques. </para>
|
|
||||||
|
|
||||||
<para> AA can be done either by the application itself (as with The Gimp
|
<para> AA can be done either by the application itself (as with The Gimp or the XFree86 font
|
||||||
or the XFree86 font system) or by hardware, if your video card supports
|
system) or by hardware, if your video card supports it. Since AA is CPU intensive, it's
|
||||||
it. Since AA is CPU intensive, it's more desirable to perform it in
|
more desirable to perform it in hardware, but if we're talking about semi-static
|
||||||
hardware, but if we're talking about semi-static applications, like The
|
applications, like The Gimp, this really isn't an issue. For dynamic situations, like
|
||||||
Gimp, this really isn't an issue. For dynamic situations, like games,
|
games, doing AA in hardware can be crucial. </para>
|
||||||
doing AA in hardware can be crucial. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -715,15 +692,15 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>FSAA: Full Screen Anti-Aliasing</title>
|
<sect2><title>FSAA: Full Screen Anti-Aliasing</title>
|
||||||
|
|
||||||
<para> FSAA is “Full Screen Anti-Aliasing”. It usually
|
<para> FSAA usually involves drawing a magnified version of the entire screen in a separate
|
||||||
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
|
||||||
framebuffer, performing AA on the entire image and rescaling it back to
|
resolution. As you can imagine, this is extremely CPU intensive. You will never see non
|
||||||
the normal resolution. As you can imagine, this is extremely CPU
|
hardware accelerated FSAA. </para>
|
||||||
intensive. You will never see non hardware accelerated FSAA. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
||||||
|
<!-- here -->
|
||||||
|
|
||||||
<sect2><title>Mip Mapping</title>
|
<sect2><title>Mip Mapping</title>
|
||||||
|
|
||||||
|
@ -738,23 +715,23 @@ you.</para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<sect2><title>Texture Filtering</title>
|
<sect2><title>Texture Filtering</title>
|
||||||
|
|
||||||
<para> Texture filtering is the fundamental feature required to present
|
<para> Texture filtering is the fundamental feature required to present sweet 3D graphics.
|
||||||
the sweet 3D graphics. It's used for a number of purposes, like making
|
It's used for a number of purposes, like making adjacent textures blend smoothly and making
|
||||||
adjacent textures blend smoothly and making textures viewed from an angle
|
textures viewed from an angle (think of looking at a billboard from an extreme angle) look
|
||||||
(think of looking at a billboard from an extreme angle) look realistic.
|
realistic. There are several common texture filtering techniques including point-sampling,
|
||||||
There are several common texture filtering techniques including
|
bilinear, trilinear and anisotropic filtering. </para>
|
||||||
point-sampling, bilinear, trilinear and anisotropic filtering. </para>
|
|
||||||
|
|
||||||
<para> One thing to keep in mind is that when I talk about `performance
|
<para> One thing to keep in mind is that when I talk about `performance hits', the
|
||||||
hits', the performance hit depends on what resolution you're running at.
|
performance hit depends on what resolution you're running at. For instance, at a low
|
||||||
For instance, at a low resolution you may get only a very slight hit by
|
resolution you may get only a very slight hit by using trilinear filtering instead of
|
||||||
using trilinear filtering instead of bilinear filtering. But at high
|
bilinear filtering. But at high resolutions, the performance hit may be enormous. Also,
|
||||||
resolutions, the performance hit may be enormous. Also, I'm not aware of
|
I'm not aware of any card that uses anisotropic texture filtering. TNT drivers claim they
|
||||||
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
|
||||||
do, but I've read that these drivers still use trilinear filtering when
|
an image to the screen. </para>
|
||||||
actually rendering an image to the screen. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -762,9 +739,9 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>Point Sampling Texture Filtering</title>
|
<sect2><title>Point Sampling Texture Filtering</title>
|
||||||
|
|
||||||
<para> Point sampling is rare these days, but if you run a game with
|
<para> Point sampling is rare these days, but if you run a game with `software rendering'
|
||||||
`software rendering' (which you'd need to do if you run a 3D accelerated
|
(which you'd need to do if you run a 3D accelerated game without a 3D accelerated board)
|
||||||
game without a 3D accelerated board) you're likely to see it used. </para>
|
you're likely to see it used. </para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -772,11 +749,10 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>Bilinear Texture Filtering</title>
|
<sect2><title>Bilinear Texture Filtering</title>
|
||||||
|
|
||||||
<para> Bilinear filtering is a computationally inexpensive but low
|
<para> Bilinear filtering is a computationally cheap but low quality texture filtering. It
|
||||||
quality texture filtering. It approximates the gaps between textures by
|
approximates the gaps between textures by sampling the color of the four closest (above,
|
||||||
sampling the color of the four closest (above, below, left and right)
|
below, left and right) texels. All modern 3D accelerated video cards can do bilinear
|
||||||
texels. All modern 3D accelerated video cards can do bilinear filtering
|
filtering in hardware with no performance hit. </para>
|
||||||
in hardware with no performance hit. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -784,15 +760,13 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>Trilinear Texture Filtering</title>
|
<sect2><title>Trilinear Texture Filtering</title>
|
||||||
|
|
||||||
<para> Trilinear filtering is a high quality bilinear filter which uses
|
<para> Trilinear filtering is a high quality bilinear filter which uses the four closest
|
||||||
the four closest pixels in the second most suitable mip map to produce
|
pixels in the second most suitable mip map to produce smoother transitions between mip map
|
||||||
smoother transitions between mip map levels. Trilinear filtering samples
|
levels. Trilinear filtering samples eight pixels and interpolates these before rendering,
|
||||||
eight pixels and interpolates these before rendering, twice as much as
|
twice as much as bi-linear does. Trilinear filtering always uses mip mapping. Trilinear
|
||||||
bi-linear does. Trilinear filtering always uses mip mapping. Trilinear
|
filtering eliminates the banding effect that appears between adjacent MIP map levels. Most
|
||||||
filtering helps eliminate the banding effect that appears between adjacent
|
modern 3D accelerated video cards can do trilinear filtering in hardware with no performance
|
||||||
MIP map levels. Most modern 3D accelerated video cards can perform
|
hit. </para>
|
||||||
trilinear filtering in hardware with little or no performance hit.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -800,14 +774,12 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>Anisotropic Texture Filtering</title>
|
<sect2><title>Anisotropic Texture Filtering</title>
|
||||||
|
|
||||||
<para> Anisotropic filtering is the best but most CPU intensive of the
|
<para> Anisotropic filtering is the best but most CPU intensive of the three common texture
|
||||||
three common texture filtering methods. Trilinear filtering is capable of
|
filtering methods. Trilinear filtering is capable of producing fine visuals, but it only
|
||||||
producing fine visuals, but it only samples from a square area which in
|
samples from a square area which in some cases is not the ideal way. Anisotropic (meaning
|
||||||
some cases is not the ideal way. Anisotropic (meaning `from any
|
`from any direction') samples from more than 8 pixels. The number of sampled pixels and
|
||||||
direction') samples from more than 8 pixels. The number of sampled pixels
|
which sampled pixels it uses depends on the viewing angle of the surface relative to your
|
||||||
and which sampled pixels it uses depends on the viewing angle of the
|
screen. It shines when viewing alphanumeric characters at an angle. </para>
|
||||||
surface relative to your screen. It shines when viewing alphanumeric
|
|
||||||
characters at an angle. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -815,20 +787,18 @@ you.</para>
|
||||||
|
|
||||||
<sect2><title>Z Buffering</title>
|
<sect2><title>Z Buffering</title>
|
||||||
|
|
||||||
<para> A Z buffer is a portion of RAM which represents the distance
|
<para> A Z buffer is a portion of RAM which represents the distance between the viewer (you)
|
||||||
between the viewer (you) and each pixel of an object. Many modern 3D
|
and each pixel of an object. Many modern 3D accelerated cards have a Z buffer in their
|
||||||
accelerated cards have a Z buffer in their video RAM, which speeds things
|
video RAM, which speeds things up considerably, but Z buffering can also be done by the
|
||||||
up considerably, but Z buffering can also be done by the application's
|
application's rendering engine. </para>
|
||||||
rendering engine. </para>
|
|
||||||
|
|
||||||
<para> Every object or pixel has a stacking order, like a deck of cards.
|
<para> Every object has a stacking order, like a deck of cards. When objects are rendered
|
||||||
When objects are rendered into a 2D frame buffer, the rendering engine
|
into a 2D frame buffer, the rendering engine removes hidden surfaces by using the Z buffer.
|
||||||
removes hidden surfaces by using the Z buffer. There are two approaches
|
There are two approaches to this. Dumb engines draw far objects first and close objects
|
||||||
to this. Dumb engines simply draw far objects first and close objects
|
last, obscuring objects below them in the Z buffer. Smart engines calculate what portions
|
||||||
last, obscuring objects below them in the Z buffer. Smart engines will
|
of objects will be obscured by objects above them and simply not render the portions that
|
||||||
calculate what portions of objects will be obscured by objects above them
|
you won't see anyhow. For complicated textures this is a huge savings in processor work.
|
||||||
and simply not render the portions that you won't see anyhow. For
|
</para>
|
||||||
complicated textures this is a huge savings in processor work. </para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -838,7 +808,6 @@ you.</para>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<sect1><title>XFree86 and You</title>
|
<sect1><title>XFree86 and You</title>
|
||||||
|
|
||||||
<para> If you're going to game under X, it's crucial that you know a bit
|
<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:
|
||||||
-->
|
-->
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue