XFree86 4.x provides a more centralized and self-contained approach to video. Much of the funkyness like kernel modules for non-root access of video boards is, thankfully, gone.
If you're getting like 1 fps, then your system isn't using hardware 3D acceleration. There's one of two things that can be going on.
Your 3D system is misconfigured (more likely)
Game X is misconfigured (less likely)
The first step is to figure out which one is happening.
If you have X 4.0 (X 3.* users procede to step 2), look at the output of X -probeonly. You'll see:
(II) XXXXXX: direct rendering enabled
(II) XXXXXX: direct rendering disabled
where XXXXXXX depends on which video card you have. If direct rendering is disabled, then your X configuration is definitely faulty. Your game is not at fault. You need to figure out why DRI is disabled. The most important tool for you to use at this point is the `DRI Users Guide'. It is an excellently written document that gives you step by step information on how to get DRI set up correctly on your machine. A copy is kept at http://www.xfree86.org/4.0/DRI.html.
Note that if you pass this test, your system is CAPABLE of direct rendering. Your libraries can still be wrong. So procede to step 2.
There is a program called gears which comes with the "mesademos" package. You can get mesademos with Debian ( apt-get install mesademos) or you can hunt for the rpm on http://www.rpmfind.net. You can also download and compile the source yourself from the mesa homepage.
Running gears will show some gears turning. The xterm from which you run gears will read "X frames in Y seconds = X/Y FPS". You can compare your system to the list of benchmarks below.
CPU TYPE VIDEO CARD X VERSION AVERAGE FPS
Compiling Mesa and DRI modules yourself can increase your FPS by 15 FPS; quite a performance boost! So if your number is, say, about 20 FPS slower than a comparable machine, chances are that gears is falling back on software rendering. In other words, your graphics card isn't 3D accelerating graphics.
More important than FPS is having a constant FPS for small and large windows. If hardware acceleration is working, the FPS for gears should be nearly independent of window size. If it's not, then you're not getting hardware acceleration.
If the following lines aren't present in your XF86Config file, put them in:
Section "DRI" Mode 0666 EndSection
This allows all non-root users to use DRI. For the paranoid, it's possible to restrict DRI to only a few non-root users. See the DRI User Guide.
Voodoo card hardware acceleration only takes place ONLY at 16bpp color and fails silently when starting X in another color depth.
Also, Voodoo cards need the 3dfx.o kernel module and a /dev/3dfx device file (major 107, minor 0) for non-root hardware acceleration. Neither the module nor the device file are used under XFree86 4.x.
First of all, it's probably not the game, it's probably your setup. AFAIK, there are 3 options to getting a sound card configured under Linux: the free OSS sound drivers that come with the Linux kernel, the Alsa drivers and the commercial OSS sound drivers. Personally, I prefer the free OSS drivers, but many people swear by Alsa. The commercial OSS drivers are good when you're having trouble getting your sound card to work by free methods. Don't discount them; they're very cheap (like 10 or 20 bucks), support bleeding edge sound cards and take a lot of guesswork out of the configuring process.
There are 5 things that can go wrong with your sound system:
Something's already accessing the sound card
You're using the wrong driver
A permissions problem
The first thing to do is to figure out if you have an IRQ conflict. ISA cards can't share interrupts. PCI cards can share interrupts, but certain types of high bandwidth cards simply don't like to share, including network and sound cards. To find out whether you have a conflict, do a "cat /proc/interrupts". Output on my system is:
$ cat /proc/interrupts CPU0 CPU1 0: 24185341 0 XT-PIC timer 1: 224714 0 XT-PIC keyboard 2: 0 0 XT-PIC cascade 5: 2478476 0 XT-PIC soundblaster 5: 325924 0 XT-PIC eth0 11: 131326 0 XT-PIC aic7xxx 12: 2457456 0 XT-PIC PS/2 Mouse 14: 556955 0 XT-PIC ide0 NMI: 0 0 LOC: 24186046 24186026 ERR: 1353
The second column is there because I have 2 CPU's in this machine; if you have one CPU (called UP, or uniprocessor), you'll have only 1 CPU column. The numbers on the left are the assigned IRQ's and the strings to the right indicate what device was assigned that IRQ. You can see I have an IRQ conflict between the soundcard (soundblaster) and the network card (eth0). They both share IRQ 5. Actually, I cooked this example up because I wanted to show you what an IRQ conflict looks like. But if I did have this conflict, neither my network nor my sound would work well (or at all!).
If my sound card is PCI, the preferred way of fixing this would be to simply move one of the cards to a different slot and hope the BIOS sorts things out. A more advanced way of fixing this would be to go into BIOS and assign IRQ's to specific slots. Modern BIOS'es can do this.
Sometimes, a card is hardwired to use a certain IRQ. You'll see this on ISA cards only. Alternatively, some ISA cards can be set to use a specific IRQ using jumpers on the card itself. With these types of cards, you need to pass the correct IRQ and memory access, "I/O port", to the driver.
This is a sound card specific issue, and beyond the scope of this HOWTO. (I should write about how to pass info to the driver).
Perhaps an application is already accessing your soundcard. For example, maybe you have an MP3 player that's paused? If something is already accessing your card, other applications won't be able to. Even though it was written to share the card between applications, I've found that esd (the enlightenment sound daemon) sometimes doesn't work correctly. The best tool to use here is lsof, which shows which processes are accessing a file. Your sound card is represented by /dev/dsp. Right now, I'm listening to an MP3 (not a Metallica MP3, of course...) with mp3blaster.
# lsof /dev/dsp COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME mp3blaste 1108 p 6w CHR 14,3 662302 /dev/dsp
fuser is similar; but it lets you send a signal to any process accessing the device file.
# fuser -vk /dev/dsp USER PID ACCESS COMMAND /dev/dsp root 1225 f.... mp3blaster root 1282 f.... mp3blaster
After issuing this command, mp3blaster was killed with SIGKILL. See the man pages for lsof and fuser; they're very useful. Oh, you'll want to run them as root since you'll be asking for information from processes that may be owned by root.
There are only two ways to configure your card:
Support must be compiled directly into the kernel
You must have the correct driver loaded into memory
You can find out which driver your sound card is using by doing "lsmod" or looking at the output of "dmesg". Since sound is crucial for me, I always compile sound into my kernels. If you don't have a driver loaded, you need to figure out what's been compiled into your kernel. That's not so straight forward. Your best bet is to compile your kernel. BTW, let me say that compiling your own kernel is the first step towards proficiency with Linux. It's painful the first time you do it, but once you do it correctly, it becomes very easy down the right, especially if you keep all your old .config files and make use of things like "make oldconfig". See the Kernel HOWTO for details.
If you haven't compiled the kernel yourself, there is an overwhelmingly good chance that your system is set up to load sound drivers as modules. That's the way distros do things. Have everything under the sun compiled as a module and try to load them all. So if you don't see your sound card's driver with lsmod, your card probably isn't configured yet.
If the sound card works when you're root but not any other user, you probably have a permissions problem. If this is the case, as root, look at the group owner of the sound card using ls -l /dev/dsp; it'll probably be audio. Then, as root, add your non-root user to the audio group in /etc/group. For example, I added the users p and wellspring to group audio on my system:
Then log out and log back in as the non-root user. Your sound card should work. Thanks to James Barton for reminding me to add this to the howto.