Gaming in the Third Dimension

SAN FRANCISCO (08/25/2000) - It began simply enough. I was a little bit ahead on my deadlines, so I took the opportunity to do a little "research." I visited several sites I knew to be reservoirs of mission-critical Linux applications and decided to sample one: a demo of a 3D game called Soldier of Fortune that I found at Loki Games. Little did I know this was to be my first step on the Path of the Thrice Doomed.

Installation was a snap. Following the long download (the demo is a 90 MB tarball wrapped in self-installing shell script), I typed sh sof-demo-xf86.run from an xterm in my home directory. The install script verified the integrity of the compressed data, created an sof-demo subdirectory, and placed the decompressed bits within it. I entered the directory and found a README, a few libraries, and the executable itself. The README hinted at a few problems I might encounter, but oh, my dweebs, it did not tell me of the tortuous path or the endless blind alleys that lay ahead!

My desktop machine is a 450 MHz AMD K-6 with 192 MB of RAM and a Voodoo3 3000 video card with 16 MB of video RAM to call its own. At the time, I was running Helix GNOME and Sawmill on Red Hat 6.2, using the 3.6.6 release of X that came with the distribution. Not a killer machine, by any means, but more than adequate for my day-to-day tasks -- and most games.

Still, when I cranked up the demo, it went into a slow-motion time warp as soon as the 3D part of the startup appeared. I was able to control the cursor only by making a long series of quarter-inch mouse movements, each followed by a wait of a few seconds for the cursor to move. Perhaps I am just gifted in these affairs, or perhaps it is because of my years of first-hand personal computing experience, but I sensed almost immediately that something was not right. Blind alley numero uno.

I turned to Rawn Shah, LinuxWorld's reviews editor and game connoisseur nonpareil, for guidance. Rawn said that I was not using hardware acceleration properly, and suggested that I write to Michael Vance, lead programmer on the Soldier of Fortune port at Loki Games, for advice on how to update to the latest Mesa libraries. Vance agreed that my problem lay in my use of software rendering, and pointed me towards the latest (3.2.1) Mesa/GL libraries.

Tips for travelers in the third dimension Here are a few tips for those who want to use the 3D hardware they have in their 3dfx or Nvidia cards with the latest games from Loki.

Before you start building your new Mesa and GL libraries, locate all existing libGL.so.* files on your system and rename them or move them elsewhere. Note that they may be in more than one place, such as in /usr/lib as well as in /usr/X11R6/lib.

Before installing X 4.0 or 4.01, be sure to make backups of your existing /usr/X11R6 and /etc/X11 directories and XF86Config file so that you can quickly and easily get back to safe ground if you get into trouble.

Do not use XFree86 --configure to create the XF86Config file for your new X server.

If you are running SuSE and need to build an Nvidia driver, be sure to take note of the problem I ran into with the symbolic link pointing to the wrong directory.

Last, and perhaps most importantly, make friends with all the folks on the #loki and #nvidia channels on Open Project IRC.

So off I went in search of the Holy Grail. The 3dfx site (makers of my Voodoo3 3000) has a page on Linux drivers (see Resources for a link). There, I found source code for Glide, the 3dfx drivers, and even 3dfx-specific X server code, with or without DRI (direct rendering infrastructure). The path turned wicked on me here. So many choices, so few clues. For Glide, did I want DRI or not?

Did I dare to use 3dfx X code instead of the official server code from XFree86.org? I was cautioned not to do so, and so I followed that advice.

As best I can recall, I chose to install Glide and 3dfx drivers for the 3.3.6 X server, though the path has forked so many times since then that I am not certain. Suffice to say that it did not work. All the signs indicated I should upgrade to the latest version of X. I had planned to do that for some time, but had put it off, hoping that docs for the XF86Config file would eventually be available beforehand.

I knew that X would require some tinkering and I couldn't afford to give up my primary desktop box while that effort was underway, so I decided to move my 3D pursuit to my test machine. That box has a Guillemot 3D Prophet (Nvidia GeForce DDR) video card instead of another 3dfx, but no problemo: Nvidia has Linux drivers, too. The test machine also has a 300 MHz K-6 with 128 MB of SDRAM.

I downloaded the installer and the requisite files from the XFree86.org site and installed it with the supplied binaries. I ran XFree86 --configure to create the new configuration file. The resulting file required some tweaking to get X running in the modes I wanted to run, but other than that small problem, all went well.

Then it was off to the Nvidia site to grab the tarballs for the Mesa replacement libraries and the driver. The drivers hook into the kernel, so if you download a binary RPM file, make sure that you're grabbing the right one for your release of the kernel. I downloaded the source for both the driver and the Nvidia GLX libraries.

I ran into another nasty twist while building the driver. Variations in directory structure and usage is a problem that I believe the Linux Standards Base is working on. I hope so. You see, in SuSE 6.4, the /usr/src directory contains a linux-2.2.14 directory, a linux-2.2.14.SuSE directory, and another directory named PACKAGES. There is also a symbolic link called linux, which points to the linux-2.2.14 directory. In Red Hat 6.2, the /usr/src directory contains a linux-2.2.14 subdirectory, a redhat subdirectory, and a symbolic link which, just like on SuSE 6.4, points to linux-2.2.14.

The problem is that the kernel header files needed to build the Nvidia driver are not located in the same directory on both distributions. In Red Hat 6.2 they live in the linux-2.2.14 subdirectory, and thus can be reached using the symbolic link. In SuSE 6.4, they live in the linux-2.2.14.SuSE subdirectory and cannot be reached via the symbolic link.

I am known to be a hardheaded old coot at times who doesn't like computers to get the best of him. And I was inspired by my friend Ramon Fernandez, who feels the same way and acts on those feelings. I refused to give in. I tracked down the header files that the Nvidia make complained about and was then able to puzzle out the problem. I changed the symbolic link to point at the SuSE directory and all was well -- at least as far as that make was concerned. I need to remember to change it back now, since it points to a nearly empty linux-2.2.14 directory.

But when the curse visits your machine, she does not leave that easily. Now armed with a brand spanking new X 4.01, and a brand spanking new driver (I also had to change the XF86Config file to load nvidia instead of the old nv driver), I charged blindly ahead. X started without a whimper. I was encouraged. I started Soldiers of Fortune. X crashed. I was disheartened.

A cry for help

I want to point out that by this time, and the process had dragged on for several days, though I had found a new source of support: the #loki and #nvidia channels on the Open Project network IRC (see Resources for a link). Actually, I had written to Nvidia PR begging for help with Nvidia's unsupported Linux drivers. That was at least two weeks ago and I have yet to hear back.

So it was to IRC that I took my latest tale of woe. And as nice as those folks are, I think they must have cringed when they saw me coming back again. But it was there that I found the final piece of the puzzle. It was iCEBaLM on #nvidia who provided it. He was walking me (again) step by step through everything I had done, when he asked: "You didn't use XFree86 --configure to create your config file, did you?"

And of course I had. iCEBaLM told me that XFree86 --configure would break the nvidia driver, though he wasn't sure why. He told me to use xf86cfg instead. I did. It worked.

In very short time I was in ultraviolence heaven, a mercenary fighting a terrorist gang in NYC, disarming a nuke on a rolling train in Africa, and searching the sewers in Kosovo for bad boys. The 3D graphics on Soldier of Fortune were excellent. It was the very best of Linux 3D gaming. I was so impressed I ordered the game and downloaded two more 3D demos: Descent 3 and Quake 3 Arena.

Now, I haven't played games on Windows for quite awhile, so I am not claiming the 3D on Linux is better. But the guys on IRC tell me that it is almost a dead heat today, and that with some not-ready-for-prime-time optimized drivers, Linux is faster. But I am here to tell you that the 3D effects in Descent 3 are the best I've ever seen. I know it's not a new game, but it is new to me and it is new to Linux. It looks great on my test box.

Unfortunately, the news about the Quake 3 Arena demo is not nearly so positive; in fact, it isn't positive at all. It won't run. It isn't crashing X when I start it, like Soldier of Fortune did; it simply hangs while initializing the sound. The word on the #loki channel is that the SuSE OSS installation gives Quake 3 problems. I've got to start packing for LinuxWorld Conference & Expo soon, so maybe I will let someone else map the path through the 3D minefield this time.

Join the newsletter!

Error: Please check your email address.

More about AMDGuillemotNvidiaRed HatSuse

Show Comments