<!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
>
