718 lines
16 KiB
HTML
718 lines
16 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Various Topics</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Linux Gamers' HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="XFree86 and You"
|
|
HREF="x276.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="When Bad Things Happen To Good People"
|
|
HREF="x457.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Linux Gamers' HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x276.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x457.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN343"
|
|
></A
|
|
>5. Various Topics</H1
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="MTRR"
|
|
></A
|
|
>5.1. Memory Type Range Registers</H2
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>See <TT
|
|
CLASS="FILENAME"
|
|
>/usr/src/linux/Documentation/mtrr.txt</TT
|
|
> 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.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="MILKINGPERFORMANCE"
|
|
></A
|
|
>5.2. Milking performance from your system for all it's worth</H2
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>If for some reason you're using X 3.3, follow the instructions given by
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>mtrr.txt</TT
|
|
> (see <A
|
|
HREF="x343.html#MTRR"
|
|
>Section 5.1</A
|
|
>) to set up your MTRRs. X 4.0 does this
|
|
automatically for you.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>If you're playing a game under X, don't run a window manager, and
|
|
<EM
|
|
>certainly</EM
|
|
> don't run a desktop manager like GNOME or KDE. See <A
|
|
HREF="x276.html#NOWM"
|
|
>Section 4.2</A
|
|
> for details.</P
|
|
><P
|
|
>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:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="90%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> # cd /etc/rc2.d
|
|
# ./ntpd stop
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>Another (radical) option is to simply put yourself in single-user mode with</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="90%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> # telinit 1
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>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.</P
|
|
></LI
|
|
></UL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN366"
|
|
></A
|
|
>5.3. About libraries on Linux</H2
|
|
><P
|
|
>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,
|
|
<B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> uses dynamic libraries, but you can make <B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> use
|
|
static libraries instead by using the <TT
|
|
CLASS="OPTION"
|
|
>-static</TT
|
|
> switch. Unless you plan on
|
|
compiling your games from source code, you'll mainly be interested in dynamic libraries.</P
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN372"
|
|
></A
|
|
>5.3.1. Dynamic libraries</H3
|
|
><P
|
|
>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 <TT
|
|
CLASS="LITERAL"
|
|
>.dll</TT
|
|
>'s used by
|
|
Windows. The program responsible for linking code “on the fly” is called
|
|
<B
|
|
CLASS="COMMAND"
|
|
>/etc/ld.so</B
|
|
>, and the dynamic libraries themselves usually end with
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>.so</TT
|
|
> with a version number, like:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> /usr/lib/libSDL.so
|
|
/lib/libm.so.3
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>When using <B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
>, you refer to these libraries by shaving off the
|
|
strings <TT
|
|
CLASS="LITERAL"
|
|
>lib</TT
|
|
>, <TT
|
|
CLASS="LITERAL"
|
|
>.so</TT
|
|
> and all version numbers. So to use
|
|
these two libraries, you would pass <B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> the <TT
|
|
CLASS="LITERAL"
|
|
>-lSDL -lm</TT
|
|
>
|
|
options. <B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> will then `place a memo inside the executable' that says to
|
|
look at the files <TT
|
|
CLASS="FILENAME"
|
|
> /usr/lib/libSDL.so</TT
|
|
> and
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/lib/libm.so.3</TT
|
|
> whenever an SDL or math function is used.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN388"
|
|
></A
|
|
>5.3.2. Static libraries</H3
|
|
><P
|
|
>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 <TT
|
|
CLASS="LITERAL"
|
|
>.a</TT
|
|
> followed by a version number, like:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
> /usr/lib/libSDL.a
|
|
/usr/lib/libm.a
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>The <TT
|
|
CLASS="LITERAL"
|
|
>.a</TT
|
|
> files are really an archive of a bunch of
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>.o</TT
|
|
> (object) files archived together, similar to a tar file. You can use
|
|
the <B
|
|
CLASS="COMMAND"
|
|
>nm</B
|
|
> to see what functions a static library contains:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="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
|
|
...
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>When using <B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
>, 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 <B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> the <TT
|
|
CLASS="LITERAL"
|
|
>-lSDL -lm</TT
|
|
> options.
|
|
<B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> will then `bolt on' code from <TT
|
|
CLASS="FILENAME"
|
|
>/usr/lib/SDL.a</TT
|
|
> and <TT
|
|
CLASS="FILENAME"
|
|
>/usr/lib/libm.a</TT
|
|
> whenever it sees a math function during the
|
|
compilation process.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN405"
|
|
></A
|
|
>5.3.3. How are library files found</H3
|
|
><P
|
|
>If you compile your own games, your biggest problem with libraries will either be that
|
|
<B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> 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
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ld.so</B
|
|
> can't find the library or the library doesn't exist on your system.
|
|
So it makes some sense to talk about how <B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>ld.so</B
|
|
>
|
|
go about finding libraries in the first place.</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>gcc</B
|
|
> looks for libraries in the ``standard system directories'' plus
|
|
any directories you specify with the <TT
|
|
CLASS="OPTION"
|
|
>-L</TT
|
|
> option. You can find what these
|
|
standard system directories are with <B
|
|
CLASS="COMMAND"
|
|
>gcc -print-search-dirs</B
|
|
></P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>ld.so</B
|
|
> looks to a binary hash contained in a file named
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/ld.so.cache</TT
|
|
> 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 <TT
|
|
CLASS="FILENAME"
|
|
>/etc/ld.so.conf</TT
|
|
> which you can edit.
|
|
This file contains a list of directories that you want <B
|
|
CLASS="COMMAND"
|
|
>ld.so</B
|
|
> to search for
|
|
dynamic libraries. If you want to start putting dynamic libraries in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/home/joecool/privatelibs</TT
|
|
>, you'd add this directory to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/ld.so.conf</TT
|
|
>. Your change doesn't actually make it into
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/ld.so.cache</TT
|
|
> until you run <B
|
|
CLASS="COMMAND"
|
|
>ldconfig</B
|
|
>; once it's
|
|
run, <B
|
|
CLASS="COMMAND"
|
|
>ld.so</B
|
|
> will begin to look for libraries in your private
|
|
directory.</P
|
|
><P
|
|
>Also, even if you just add extra libraries to your system, you must update
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>ld.so.cache</TT
|
|
> to reflect the presence of the new libraries.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN428"
|
|
></A
|
|
>5.3.4. Finding Out What Libraries a Game Depends On</H3
|
|
><P
|
|
>Most commercial Linux games will be dynamically linked against various LGPL libraries,
|
|
such as OpenAL or SDL. For these examples, Bioware's NeverWinter Nights <<A
|
|
HREF="http://nwn.bioware.com"
|
|
TARGET="_top"
|
|
>http://nwn.bioware.com</A
|
|
>> will be used.</P
|
|
><P
|
|
>To find out what libraries a game uses, we can use the "<TT
|
|
CLASS="FILENAME"
|
|
>ldd</TT
|
|
>"
|
|
command. Cd to <TT
|
|
CLASS="FILENAME"
|
|
>/usr/games/nwn</TT
|
|
>, or wherever you
|
|
installed it and take a look at the files. You should see a file called
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>nwmain</TT
|
|
>; this is the actual game binary. Type "<TT
|
|
CLASS="LITERAL"
|
|
>ldd
|
|
nwmain</TT
|
|
>" and you'll see:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="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)
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>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 <TT
|
|
CLASS="FILENAME"
|
|
>libnvidia-tls.so</TT
|
|
>, the Nvidia supplied
|
|
libGL on my system does.</P
|
|
><P
|
|
>Missing libraries?</P
|
|
><P
|
|
>In the example above, we can see that <TT
|
|
CLASS="FILENAME"
|
|
>nwmain</TT
|
|
> wants <TT
|
|
CLASS="FILENAME"
|
|
>libmss.so.6</TT
|
|
>, 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
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>nwn</TT
|
|
>. Let's take a look at that now:</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="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 $@
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>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.</P
|
|
><TABLE
|
|
BORDER="1"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="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)
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>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 <TT
|
|
CLASS="FILENAME"
|
|
>libmss.so.6</TT
|
|
> in the "<TT
|
|
CLASS="FILENAME"
|
|
>./miles</TT
|
|
>"
|
|
directory, and also finds the local copy of libSDL first, no longer using the system
|
|
copy.</P
|
|
><P
|
|
>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 <A
|
|
HREF="http://gcc.gnu.org"
|
|
TARGET="_top"
|
|
> the GCC
|
|
site.</A
|
|
></P
|
|
><P
|
|
>Making NWN use your system copy is easy. It says so in the wrapper script! Remove
|
|
"./lib:" from the <TT
|
|
CLASS="LITERAL"
|
|
>LD_LIBRARY_PATH</TT
|
|
> line, and you're good to go.</P
|
|
><P
|
|
>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
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>openal.so</TT
|
|
> distributed with games often do NOT support
|
|
ALSA, so making the game use a copy compiled yourself will allow you to use ALSA
|
|
natively.</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x276.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x457.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>XFree86 and You</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>When Bad Things Happen To Good People</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |