Novice to Novice

Games, Sound & Other Agonies

by Dean Oisboid

I have to start this month's article with an apology. The original introduction focused on Unix as a mature operating system but one that lacked maturity in the area of entertainment. After a week of exploring the variety of Unix games, I realized my mistake. Unix games may not be as profitable or numerous as DOS games but they have been tremendously influential, and that needs mention.

The first popular games started on the mainframes. "Adventure" spawned "Zork", which spawned the adventure game industry. On the strategy side, I believe Empire was translated from the mainframe. Mac and MS-DOS versions met with great success. Empire also influenced the strategy genre by combining a "conquer an unknown world" motif with multi-player capability, an influence that, in part, resulted in Warlords II, one of my favorite strategy games. Even today, Unix is still a major influence on the gaming world, via the Internet, through Multi-User Dungeons (MUDs). These interactive sessions began the requirement now for many non-Unix games, that they allow for multiple players over a modem or network. Many on-line services are now offering multi-player versions of the most popular MS-DOS games.

Novice to Novice will take a little recreational detour this month and explore a variety of games that may come with Linux disks or CDs. In my case, Slackware Professional 2.1. The eventual goal of this article will be to get DOOM running and use a Sound Blaster 16 because DOOM without the gruesome sounds of unbridled carnage just isn't right.

Slackware allows you to install two sets of games. One set, "Y", contains the BSD games collection and a Tetris clone. The other set, "XAP", contains X-Windows applications and includes some games like GNU chess and xboard (which allows you to run the ASCII GNU chess in X).

I loaded the BSD collection and soon after removed it, with one exception: Mille, a clone of Parker Brothers' popular card game Mille Borne. The binary found on the main Slackware disk had a bug that occurred when the game was extended. Sometimes there'd be an annoying buzzing lockup. However, I found a version on the tsx-11 archive disk that ran smoother. Very addictive!

There are more games than the BSD compilation available. If you snoop around on any of the archive CDs you're bound to find gold. When I found something of interest, I would copy it over to /usr/local/games. It seemed like an appropriate spot to put things. [/usr/games is for games that are installed by the system; /usr/local/games is a good choice for user-installed games --ED]

The Sunsite disk had a plethora of games conveniently divided into general categories like action, strategy, X11, and RPG (role-playing games) which was a major stopping point for me. The names sounded familiar. Some of the games like Rogue, Moria, and (Net-) Hack have been successfully translated to DOS, and in at least one case, given a major facelift. For example, SSI's Dungeon Hack is directly evolved from Hack but redone with SuperVGA graphics and a variety of other additions.

For the heck of it, I copied over Rogue. Any game with a name like my favorite comic book heroine automatically gets special consideration. The version I copied was 5.3pl2. Besides the source code, the archive had a precompiled binary, which I appreciated, but when I ran it, it crashed: "missing library". Fine. I compiled the source cleanly and ran the new binary. It ran for a few keystrokes before stopping from "segmentation faults". Sigh! I dismissed Rogue and looked for other entertainment.

I found something called Omega (version 0.78.1) on the TSX-11 CD that I thought would be like the DOS tank programming game of the same name; instead, it was another Hack clone. This one, unlike Rogue, ran well and my wife had to drag me away after a half hour of playing. It's easy to forget that you don't always need snazzy graphics to produce a deep game. ASCII role-playing games like this amaze me with their detail. Sure, you can add graphics, but then that 500K game explodes into multi-megabytes of size. Also, a keyboard interface can allow you a greater variety of options, which Omega has, than a mouse-based interface cluttering up a graphics screen. The problem is simply remembering the overwhelming number of commands, but a printout of the help file solves that easily enough.

Chess! I've always loved chess, not just the game but the lore and history around it. Since I had installed GNUchess and xboard, well, how about a game of chess? I ran GNUchess straight up and got the ASCII board, moved a few pieces, and lost. Admittedly my chess rating, if I had one, would be somewhere in the low hundreds. But GNUchess worked! Now for the X-Windows interface. I activated my swapfile, entered X-Windows, called up an Xterm shell, and typed in xboard. Quickly a rather pretty chess board appeared. Quickly my hard drive started whirring. I made my first move and the opponent's clock started its countdown from 5 minutes. The hard disk continued to go berserk for 2.5 minutes before I destroyed it out of mercy. This long amount of time for the first move was unacceptable. Perhaps it was the swapfile. I exited X-Windows, shut off the swap, and tried xboard again. This time the board appeared along with an error message about "GNUchessx exited unexpectedly". Sigh! So much for chess. [Adding more swap would have solved the problem with xboard. --ED]

I discovered Empire (Chainsaw version 3.12) under "strategy" and debated compiling it. The README mentioned that it would require TCP/IP among other things. Sure Linux has that and more, but I backed down from compiling. I wasn't hooked up to any network; I just wanted to see what one of these games looked like without having to compile anything. Luckily, I found Conquest (5.5.1a) which, after copying to / and unarchiving, produced an executable game with little modification necessary. Running X-Windows and calling up Xterm, I typed:

xset +fp /usr/X386/lib/X11/fonts/misc/xconq
xset fp rehash

A strong case for Unix games is that for many you get the source code. If the game is too easy or too hard, or needs a wandering wizard--rewrite it! The only answer to this from the DOS side of things is the occasional release of construction sets. Generally, however, these sets do not allow you to change all aspects of a game, just what the designers will allow you to change. That's not quite like having the source code. The negative side is having the source code and not having it compile cleanly. To an expert hacker, this presents no obstacle--dive into the code and make corrections, but for novices, it's agony. That's why, when some of the above games crashed, I moved on. And on that line of thought...

On to DOOM!

I waited. My hard drive started grinding. Terminal messages gave a variety of errors which I assumed would be related to the lack of a sound driver.

And waited. A minute passed and the hard drive was going berserk. Anxiety crept into the room and waited to pounce.

And waited. A small window appeared. The opening screen of DOOM kind of showed up. It looked horribly dark and grainy, but when I clicked the mouse button, the background to X-Windows changed colors and the DOOM window suddenly, dramatically cleared up.

I was in DOOM! The movement was, surprisingly, a little jerky. I brightened up the screen via the F11 key (gamma correction). Yes, this was DOOM. I played for a bit and then quit. DOOM without the gruesome sound is gruesome itself.

The DOOM readme suggests using version 3.0 of Hannu's sound driver but fails to tell where it can be located. The Sound HOW-TO mentions using a shell script found in /usr/src/linux/drivers/sound/Readme.linux, except that no such subdirectory or file existed in my setup. Snooping with mc (Midnight Commander) in /dev, I noticed many empty files including /dev/dsp, which is used for sound. I also noticed and read through the MAKEDEV file and decided to try it.

Entering MAKEDEV audio did nothing--at least, nothing that I could see. The files still remained at size 0. [Device files are always 0-sized. Device files are also sometimes called "special files", for good reason.--ED]

Yes, this has all the makings of a minor crisis. Re-reading the Sound HOW-TO reveals the bad news: recompile the kernel to support sound. No, no, NO! What did I do to deserve this? I just wanted to play Doom with sound. Having to recompile the kernel just to get sound had to be insane, but it seemed that this simple yearning for DOOM had to develop into a learning experience. [Actually, recompiling your very own kernel allows you to make a smaller kernel, which gives you more memory to work with, which means that more of the games will work without the massive swapping experienced here. --ED]

After a day of blaspheming a variety of Linux gods (primary and many secondary), I calmed down to tackle recompiling the kernel. The first thing I did was copy the remaining kernel source code from the "D" set on the CD-ROM. The kernel had been split into three archives, and I had already copied over the third archive as a recommended part of general installation. Admittedly, I found it quite cool that I could fiddle with the source code if I so chose--something I know I'll never experience with Windows or DOS.

Next: I read the manual. It mentioned creating two links:

# ln -sf /usr/src/linux/include /usr/include/linux
# ln -sf /usr/src/linux/asm /usr/include/asm

# ln -sf /usr/src/linux-1.1.59/include \ 
/usr/include/linux
# ln -sf /usr/src/linux-1.1.59/asm \
/usr/include/asm

After setting the links, I switched to /usr/src/linux-1.1.59 and entered make config, which prompted me with a barrage of questions. For the most part, I accepted the default answers except when it came to SCSI, CD setup (I chose the Sony cdu31a option) and sound. Since I don't have any SCSI devices, I opted to eliminate that ability. For sound, I first accepted the default of all sound options, but when configuring the individual parts, a non-SoundBlaster value conflicted with something I specified for my Blaster. The program stopped because of that. I restarted the configuration and this time chose not to fully install all sound options. This way I got to pick just the SoundBlaster options and configure for them.

After the make config finished, I typed make dep which (according to the System Administration Guide) fixes all of the source dependencies. No problems here.

Finally the big moment: make Image to create the actual image. No, it stopped, saying the command wasn't supported anymore and instead to type make zImage to create a compressed version.

I did so and the computer started grinding away. About ten minutes later it crashed: lack of virtual memory. Dumb error on my part! Setting my swap file active with swapon /swap, I restarted the compiling and relaxed as the grinding began.

And continued. 5 minutes. 10 minutes. 30 minutes. About an hour later it finished and finished cleanly. No problems! My chest puffed out in manly pride, and I drank deeply from a virtual beer.

Now what to do with the two resulting files called zSystem.map and zImage? Using mc, I found a similar zSystem.map under /boot. I renamed it and copied the new one in its place. A quick perusal of the System Administrators Guide revealed that sometimes the kernel is called vmlinuz and sure enough I found such a file under /. I renamed it and copied zImage as vmlinuz to /.

[This was enough because Dean uses UMSDOS and does not use LILO. The majority of Linux users, who use LILO to boot, will need to run lilo in order to make their new kernel bootable. Many documents, including the article Dean mentions below, document how to do this. --ED]

The new kernel turned out smaller--about two-thirds the size of the old kernel. Hopefully this will translate into a slight gain in speed. I also discovered--actually I remembered--that Linux Journal had an article in Issue 7 about compiling the kernel, called "Linux Performance Tuning for the Faint of Heart". A quick review revealed that I answered the various kernel questions correctly. Very comforting and also informative. The article explained many of the default choices.

Time for the real test: shutdown Linux and reboot. The kernel loaded cleanly and apparently recognized the SoundBlaster. Great! I set up the swap file, fired up X-Windows, called up a term window, got into /usr/games/doom and ran linuxxdoom. It did its stuff, grinding and YES, YES, YES, DOOOOOOOOM WITH SOUND!!!!! It worked!

For a while, I thought it wouldn't work because there were many error messages during loading saying "can't find lumpname ( )", but it worked!

Now, one more thing to test: whether DOOM would allow me to use an alternate .WAD file (data file) with the game. One of the great appeals of Doom is that the program allows you to use other data files, thus giving you good value for your $US40. People have created 1000s of new levels, sounds, and effects for Doom, Doom II, and the newest family member, Heretic. I doubted that I could use an alternate WAD with this shareware version of Doom because it is version 1.666. Supposedly, the earlier 1.2 version did have the external WAD support, but that meant users wouldn't necessarily buy the full version. Id Software, the publishers, removed that ability in the later shareware versions. Only registered users get to enjoy swapping WADs. I happen to have a WAD handy, so let's try it out:

doom -devparm -file acheron.wad -wart 1 3

A Parting Rant

And yet, with Linux, a compact and essentially free Unix, the home market opens up. If Linux, or any other similar operating system, can create a valid and popular niche in the home market then the scenario changes. With the home market opened up, we see a fantastic new potential for Unix-based entertainment.

Anybody want to design a killer Linux game?

Dean Oisboid, owner of Garlic Software, is a database consultant, Unix beginner, and avowed Strike Commander addict. He can be reached at 73717.2343@compuserve.com