This is my page for those gamers making the move to Linux, who, while they may know Dos/Win9x very well (ie config.sys/autoexec.bat does not scare you), are new to Linux's way of doing things. This guide isn't comprehensive, but it should prove useful in getting things up and running.

My getting started section is still up, but it contains several mistakes, and is rather dated. If you've already gotten over the newbie-blues, then here's some more high-level topics:

• Process layout of Linux & Windows95
• CPU Scheduling & Memory protection
• X-Windows & Window managers
• DRI (Direct Rendering Interface)
• Setting up XFree86 v4.1.0 (for an nVidia card)
• Sorting out the mouse (and DGA)
• Mesa and OpenGL (outdated)
• Setting up a VooDoo2 (outdated)
• nVidia & OpenGL programming
• Tarballs (.tar.gz, .tar.bz, .Z, etc) and Unix compression

Note: Linux allows either a text-based login (in which you have to manually start the GUI using 'startx'), or a completely graphical based login. I assume your using text-based login.

Process layout of Linux & Windows95

Firstly, you'll probably be familiar with Windows95/98, which has a layout much like the one below (WinME is probably the same minus the 16-bit TSRs). I don't know for certain how thing divide up, but outwardly, to me it looks like (I have no real idea how WinNT and Win2000 structure things):
 

Basically you've got Dos with an overgrown graphical shell sitting on top of it that tries to act as a kernel on top of a kernel (one of the reasons it is easy to crash). Linux, however, looks more like (and unlike Win9x, it was easier for me to find out information on the structure):
 

As you can see, Linux is more modular. Linux supports at the console prompt things like full network and sound support that Win95 only support once you've gone into the GUI. More importantly, there is a clear separation of responsibilities, the most notable one being the separation of graphics routines (X-Windows) and the GUI look/feel (the Window manager). Should the graphics routines go bang (one of the things most likely to), you end up at the login shell. With Win9x, the graphics code going bang means reboot time.

Also, there is the ability to easily replace (and even knock out completely) some programs you don't need. Do you really need file sharing and a pretty desktop when you are only playing online Quake? Nope. Kill the redundant processes off then. And you don't even need to reboot.

Note: it is possible to change the priorities programs have when it comes to dishing out processor time (aka renicing), but dispite what I have read elsewhere, i'm yet to be convinced that tinkering with it gives much (if any) game performance increase.
 

CPU Scheduling & Memory protection

Talking a rather simplistic view, just about all the OSs in common use today do some form of multitasking. We also know that the CPU can only execute one instruction at a time. With several processes (programs) running, the OS needs to allocate CPU cycles to them all. This is often known as processor time sharing, where each program gets a certain amount of time to run before another program gets its turn.

Win9x simply allows the foreground process (usually the one that owns the window you've currently got selected) to grab as much of the CPU time as its wants, and tends to let the other processes starve. This doesn't cause problems much of the time, but running a QuakeWorld server, and connecting a QuakeWorld client running on the same box to it shows up the problem very well: The nasty lag is a result of the QW server getting starved of CPU time, because the OS gives most of it to the QW client.

Most other OSs (including Win2000 and Linux) don't suffer from this problem, as they have a mechanism that shared processor time more fairly (if needed). I suspect Win9x's approach allows for the fastest possible execution of the foreground program (the only thing most gamer's care about), but the advantage is negligible on today's systems.
 

Another issue is how well the memory of one program is protected from other programs. Win9x, unlike most other OSs, has poor memory protection. This is the main reason why Win9x is easy to destabilize: When a program goes bang, memory that does not belong to the program can easily get smashed. This has nasty side-effects if the memory getting smashed happens to contain a part of the OS. Its not uncommon for a program to go bang, and being unable to properly restart unless the system is rebooted.

The ability of a program to take the entire system down with it bites seriously if you ever run multiple programs. Last time i programmed under Win95, a bug that crashed the program also caused me to lose 45mins of IRC logs. Even if your only running a game, its a lot nicer to just be dumped out of the program rather than having to do a full reboot.
 

X-Windows & Window Managers

Under Unix/Linux, the graphical interface is separate from the core operating system. The core part of X-Windows is the X-server. The X-server (usually XFree86) basically deals with all hardware handling. One thing to note is that the X-server is separate from the GUI. The GUI (window border appearances, window movement, etc) is what the Window Manager deals with. It is actually possible to run X-Windows without a Window Manager. For instance, to run Quake3 directly you can run:

    xinit /usr/local/bin/quake3

The X-server loads and immediately loads Quake3. When Quake3 exits, the X-server also terminates. The startx command you use to start X-Windows is really just a wrapper around xinit that also starts up a window manager. There's nothing stopping you starting the X-server with a different window manager such as TWM (Tab Window Manager):

    xinit /usr/X11R6/twm

Note: You can change the window manager that startx loads on a user-by-user basis by creating a shell-script called ~/.xinitrc that starts the wanted window manager.

Window managers are often down to personal taste. The most notable ones are KDE and Gnome, which are sometimes called Desktop Managers because they also provide things such as file management, but for some people, these are a bit bloatish. (KDE want to access the disk every now and again, although i doubt that it affects game performance). I personally use KDE and TWM. My .twmrc file is available (all i've done is taken the default system one and add a few programs and a submenu) for those who want it. If you really want to, you can have an xterm window as your window manager.

If you want to temporarily change the screen depth,  append the -- -depth <number> to the end of the command. You might want to do this because, once the X-server is started, programs (such as Quake3) cannot change the depth. Here's a few example usages..
    startx -- -depth 16
    xinit /usr/X11R6/twm -- -depth 24
    xinit /usr/local/bin/quake3 -- depth 24
 

Note: 24-bit and 32-bit colour are actually the same thing. 32-bit colour is deprecated in more recent versions of XFree86. 32-bit colour is simply 24-bit colour plus an alpha channel, which does not mean anything as far as display hardware is concerned.

DRI (Direct Rendering Interface)

Traditionally, X-Windows uses a server-client structure that enables the system running programs to be elsewhere and your local terminal is merely displaying the output being piped to it over a network. Even if the X-server (handles keyboard/mouse input and the display) and X-client (program your running basically) are on the same system, the parts still communicate to each other using network protocols.

This method has problems with some things such as accelerated 3D rendering, since a scene would have to be rendered in hardware, the resulting image read back into memory, and then sent straight back to the graphics card (via the X-server) for display. Not efficient. To get over this, DRI was created. In a nutshell, if the X server and X client are on the same system, programs can bypass the X-Windows rendering pipeline and send rendering data straight to the card for immediate display. Implementation of DRI is one of the main aims behind XFree86 Version 4.x

Although some companies, notably nVidia have decided to ignore DRI and develop their own proprietary mechanisms that achieve similar effects, there is nethertheless a large shift from XFree86 v3.x.y towards XFree86 v4.x when it comes to Linux 3D drivers.
 

Setting up XFree86 v4.1 (for an nVidia card)

The drivers for most of the major graphic cards require one of the v4.x series of XFree86, rather than one from the v3.x.y series. However, v4.x only recently came out of beta (actually, it might still be in beta..), and i don't think its yet replaced XFree86 v3.x.y as the standard X-server in Linux distributions (RedHat 7.0 had XFree86 v4.01 as a custom-install option).

XFree86 have written a very good getting-it-running document, and its not that difficult to install. Ideally you ought to have an alternative route to the internet (eg via a duel-boot to another OS, or a seperate system) before starting just in case. Anyway, here's the pointers you'll need:

• XFree86 homepage (main)
• Free86 homepage (UK mirror, a bit broken in places)
• Free86 v4.1.0 installation notes
• Free86 v4.1.0 Release notes (lengthy)

Below i will detail my installation (from tarball) of XFree86 v4.1.0 and nVidia's drivers (for a GeForce2 GTS 64mb) onto a RedHat 6.2 box that has an existing XFree86 install.

RedHat 6.2 uses requires the Linux-ix86-glibc21 set of binaries. I downloaded the entire directory (~60mb), put all the files into one directory, change the script's file permission with chmod 700 ./Xinstall.sh and then ran the script (Xinstall.sh). The first question i answered yes to. The rest i used the default answer (just pressing enter).

Next, i installed the nVidia drivers (as root user), using the rpm command..
    rpm --rebuild NVIDIA_kernel-1.0-1251.src.rpm
    rpm --install /usr/src/redhat/RPMS/i386/NVIDIA_kernel-1.0-1251.i386.rpm
    rpm --install NVIDIA_GLX-1.0-1251.i386.rpm --nodeps

The first line generates a binary RPM from the (kernel) source RPM. This binary RPM is then installed by the 2nd line (the path might need modifiying), and the third line installs the GLX driver. --nodeps is used to stop rpm complaining about the XFree85 v4 dependency (since we installed XFree86 from tarball, rpm doesn't know that its already installed).

Then we need to setup the XF86config file.. Run xf86config (as root user), and press enter. You'll then be asked a series of questions. Here's how i answered them. Note that you may need to answer differetly depending in your monitor/mouse hardware..

Enter a protocol number: Depends on model. I chose 4 for PS/2.

Do you want to enable Emulate3Buttons? n (my mouse is a 3-button one)

Mouse device: /dev/psaux

Enter a number to choose the keyboard: 2

Enter a number to choose the country: 14 (UK)

Please enter a variant name for 'gb' layout: Pressed <enter> for default.

Do you want to select additional XKB options?: Pressed <enter>. I'm not sure what its on about.

Pressed enter to continue to monitor section..

Enter your choice (1-11):   8  (31.5 - 64.3; Monitor that can do 1280x1024 @ 60 Hz)

Enter your choice:  2 (if unsure, choose a lower setting).

Enter an identifier for your monitor definition:  MyMonitor

Do you want to look at the card database?:  y

Enter a number to choose the corresponding card definition.: 320 (NVIDIA GeForce)

Enter to continue..

Enter your choice:  5 (i think this value gets ignored anyway ny nVidia's driver)

Enter an identifier for your video card definition:  Just pressed enter

Depth modes: I decided to make 1024x768 my default, with 800x600 and 640x480 also available. I also
decided not to have an extra-large virtual desktop. To do this i used:
    1<enter>
    432<enter>
    n<enter>
    2<enter>
    432<enter>
    n<enter>
    3<enter>
    432<enter>
    n<enter>

If you want something different, the help text should make it easy to work out what to do. I chose option 4
(OK, continue) once done.

Enter a number to choose the default depth: 5 (may as well make 24bit the default)

Choose 'y' when asked wether to write XF86Config.

You then need to edit /etc/X11/XF86Config and make two changes. Look for a section like..

    Section "Device"
        Identifier  "NVIDIA GeForce"
        Driver      "nv"
        #VideoRam    4096
        # Insert Clocks lines here if appropriate
    EndSection

and change it to..

    Section "Device"
        Identifier  "NVIDIA GeForce"
        Driver      "nvidia"
        Option "NvAgp" "0"
        #VideoRam    4096
        # Insert Clocks lines here if appropriate
    EndSection

Basically we're changing the driver from the nv one included with XFree86, to nVidia's driver. The
NvAgp line disables the faster AGP writes. On quite a few system, not having this option causes a lot of
crashes (in my case, the number of crashes caused by this option's absence accounted for around half of
all the hard system lockups i've ever had with Linux). I've not read up much into it. You also need to enable the OpenGL-X extensions by looking for

    # This loads the GLX module
    #    Load       "glx"

..and changing it to (uncommenting the GLX line)..

    # This loads the GLX module
        Load       "glx"
 

You should now have an operational X-server setup with accelerated OpenGL.

Note: Switching between versions of XFree86 is a case of moving a few directories around (eg moving /usr/X11R6 to /usr/X11R6.new and /usr/X11R6.old to /usr/X11R6), since XFree v4.x keeps all the X-server binaries/libraries under /usr/X11R6, and i think the XF86Config file format has not changed at all since V4.0. You might also have to move some of the nVidia drivers around as well if your using v4.0
 
 
 

Sorting out the Mouse (and DGA)

DGA (Direct Graphics Architecture), seems to be some sort of interface architecture which deals with more than just graphics (a bit like the way DirectX deals with more than just drawing). One such part of DGA Mouse support. With this enabled, the responsiveness of the mouse (in games that support DGA, which includes UT and Q3) is reportedly identical with Win9x. I think the broken DGA Mouse support has been fixed in XFree86 V4.02, but i'm not certain.

However, XFree86 has other mouse options for tweaking. One that a lot of people will be interested in is enabling Mouse wheel support. Here is the /etc/X11/XF86Config section needed to setup a PS/2 Logitech mouse (with wheel):

Section "InputDevice"
    Identifier  "Mouse1"
    Driver      "mouse"
    Option "Protocol" "IMPS/2"
    Option "Device" "/dev/psaux"
    Option "ZAxisMapping" "4 5"
    Option "Resolution" "300"
    Option "SampleRate" "150"
EndSection

I'm not even sure if SampleRate is a recognised option anymore, but Resolution and SampleRate (assuming the mouse supports them), control the responsiveness and sensitivity of your mouse. You may also want to grab the imwheel package, which allows the mousewheel to vertically scroll windows. RPM versions of imwheel have a known security hole, but I don't think it is exploitable over a non-TelNet network connections.

Note: Pre-4.x versions of XFree86 had a less general (therefore different) way of setting out mouse parameters.
 

Mesa and OpenGL (outdated)

Direct3D doesn't exist for Linux, so Linux uses the OpenGL standard instead. For most people, this will mean installing the Mesa 3D library. Mesa cannot technically be called an OpenGL library for various reasons (one being that it is not fully OpenGL compliant, as well as legal reasons), though an OpenGL library is what it more or less is.

Note: If you've got a nVidia card, go straight to the GeForce section. nVidia's OpenGL drivers and Mesa clash with each other.
 

Downloading/installing: At time of writing, Mesa v3.2 is the latest version:

• Mesa 3.2 (RedHat 6.1 compiled RPM)
• Mesa 3.2 (Source RPM)
• Mesa 3.2 (Source tarball)
• Mesa 3.1 (RedHat 6.1 RPM)

libMesaGL*: Before v3.1, Mesa's libraries were (apparently) named libMesaGL*, but have since been renamed to libGL*, probably because libGL* is the standard OpenGL library name. Probably not much of a problem, but could cause confusion if you've read through the LinuxQuake HOWTO and found something about making links to libMesaGL.so.3..

Setting up VooDoo2 (outdated)

3dfx got into the Linux scene relatively quickly, as their cards acted independently from the normal Linux rendering pipeline (not having the problems DRI is solving). However, the VooDoo2 (although quite good for its age) is fairly vintage by modern standards. The instructions below, which in turn are pretty much a rehash of the instructions on 3dfx's Linux site, were written quite a while ago, but i think it is how i got it working with RedHat 6.1. Firstly, you need (i hope the links still work..):

Glide2/Glide3 package
Device3dfx package

Build and install the Device package. Bear in mind that this is a two step process since the first step generates a binary RPM, and the second installs it. The third command line installs the Glide package. I don't think it matters which order the Glide and Device packages are installed in, but if you start changing the order you do things, you may fall into the trap i did (trying to install a package before it was built)..
    rpm --rebuild Device3Dfx2.3-4.src.rpm
    rpm -Uvh RPM_PATH/RPMS/i386/
    rpm -Uvh Glide_V2-2.53-6.i386.rpm

You should then test the package (both as root and non-root) using test3Dfx, testGlide2x, and testGlide3x  (located under /usr/local/glide/bin). If things go wrong, consider consulting 3dfx's own instructions and the Linux Quake HOWTO. Setting up my VooDoo2 was one of those things where i wasn't sure exactly what i did in the quest to get it working, but don't think i did anything much different from the usual route..

See 3dfx's main Linux site for details on getting Linux drivers for other 3dfx cards. 3dfx is very pro-Linux (drivers are fully open-source) so Linux users won't have much trouble with most of the 3dfx 3D cards..

Once done, you'll probably want to install the Mesa 3D drivers to get OpenGL support..
 

Compiling OpenGL programs with nVidia drivers installed

This isn't really game related, but i've decided to include it anyway. NVidia's drivers and Mesa clash because both contain files such as /usr/lib/libGL.so. A pain when you want to use nVidia's drivers AND want to be able to compile OpenGL programs. The way i sorted this is a bit of a hack as it is basically installing Mesa into my home directory rather than in the /usr hierarchy. I'll assume you either download the source tarballs into ~/OpenGL or know which commandline parameters need altering:

• Core Mesa Library (required)
• Mesa OpenGL demos (if you want them)
• GL Utility Toolkit v3.7 (advisable if your learning OpenGL)

The make command takes a few minutes on my system. The other commands are fairly quick. Mesa should now be installed in these locations (the Mesa Demos will be buried somewhere under ~/OpenGL/Mesa-3.2.1/):
    ~/OpenGL/lib/GL/
    ~/OpenGL/include/GL
    ~/OpenGL/etc/mesa.conf

If you also want to have glut as well, run:
    cd ~/OpenGL/
    tar -xzf glut-3.7.tar.gz
    cd glut-3.7
    chmod 660 Glut.cf
    cp linux/Glut.cf ./
    C_INCLUDE_PATH=$C_INCLUDE_PATH:$HOME"/OpenGL/include/"
    ./mkmkfiles.imake
    cd lib/glut
    cp ../../linux/Makefile ./

change Line 482 from Makefile (~/OpenGL/glut-3.7/lib/glut/Makefile) from:
  EXTRA_INCLUDES = -I$(TOP)/include -I$(TOP)

to (replacing /home/xxx with whatever the command echo $HOME gives):
  EXTRA_INCLUDES = -I$(TOP)/include -I$(TOP) -I/home/xxx/OpenGL/include

then run:
    make

You should have libglut.so.3.7 in ~/OpenGL/glut-3.7/lib/glut/ after all this. If you want to compile the example glut programs as well, then that involves more messing around (i didn't bother).
 

Compiling OpenGL programs: During `make install' details on how to link to the Mesa libraries should be displayed. One (not problem free) way of doing this is adding the parameters listed below to gcc. I assume you've got the knowledge to alter these to suit your system:
    -L/home/necro/OpenGL/lib
    -I/home/necro/OpenGL/include
    -Wl,--rpath -Wl,/home/necro/OpenGL/lib
    -lGL
    -lGLU

If your writing Linux OpenGL programs, i advise you to find out for yourself about linking. Look at man gcc, man ld, and the linker options section of gcc.gnu.org. If you don't know what i'm talking about, you should not be writing programs under Linux.
 

Tarballs (tar.gz, Bzip, .Z, ..) and Unix compression

Under Unix, the way compression is done shows signs of evolution. Firstly, there was the need to combine several files into a single file for backing up onto tapes. This was done by the tar command, which created .tar (Tape ARchive) files. Tape Archive files are not compressed.

Compression is a comparativly new thing compared to sticking files together with tar, so when compressors came about, they only compressed single files: People would create a tar file, and then compress it. This is why tarballs have the double extension .tar.gz (though this is sometimes abbreviated to .tgz). In ASCII-art form, this is what happens:

Note: Under Linux, the tar command is able to write to (or read from) a .tar.gz file directly, rather than needing seperate (de)compressed. This is not the case with (some?) commercial Unix implementations such as Solaris.

.tar.gz (aka tarballs) is the most common way of packaging up files under Linux, and is usually referred to as tarballing (i've once or twice come across it being called 'tarring and feathering'). These basic commands should help you work out how to compress/expand tarballs..
 

WARNING: NEVER miss out the output filename when creating tap files. If you do something like tar -cf * the first filename that tar comes across will be used as the output file. Fortunatly, last time i tried this, the file that got smashed was a small one i had a copy of elsewhere, and not the one i had spent a few hours working on without ever backing up.

GZip is not the only compression format available under Linux. One is Bzip, which is simular to Gzip, but has better compression ratios. Here is an at-a-glance list of extensions..