![[DOOM logo]](doom.gif)
(revision 7, 95/10/29)
Compiled by Steve VanDevender <stevev@jcomm.uoregon.edu>
![[bloody bits of meat fly everywhere]](doomact2.gif)
DOOM is a wildly popular action game developed by id Software where you, a trained space marine, have to fight your way through a series of increasingly hellish moonbases that have been invaded by demonic creatures. It features stunning realtime texture-mapped 3-D graphics, chilling stereo sound effects, and frenetic gameplay. You can also play DOOM in multi-player cooperative or Deathmatch games using modems, IPX networks, and TCP/IP networks. id distributes a full-featured shareware version with the 9 levels of DOOM Episode 1, "Knee-deep in the Dead", and for a $40 registration fee you can buy two more episodes, "The Shores of Hell" and "Inferno". A commercially distributed sequel, DOOM II: Hell on Earth, is being sold in stores. DOOM enthusiasts have decoded the formats of DOOM resource files with the blessing and support of id's programmers and created literally hundreds of user-designed levels (often called WADs or PWADs) to supplement the 27 levels in the registered version of DOOM or the 32 levels in DOOM II (you must have the registered version of DOOM or DOOM II to use these add-on levels).
Although primarily marketed for MS-DOS, DOOM was originally developed on NeXT systems and has been or will be ported to SGI systems, Macintoshes, the Atari Jaguar, MS-Windows, and more. Now, a Linux port done by David Taylor of id is available that runs with Linux and the Linux SVGA library or XFree86.
I have compiled this document from my own experiences and information other people have posted on the net. Whenever I remembered to, I have credited sources of information. If I missed crediting you, I'm sorry.
This document is meant to provide information to help you install and use the Linux ports of DOOM. It does not attempt to answer questions about Linux or DOOM that are better answered by other sources, like how to recompile your Linux kernel or how to play DOOM. References to some of these other sources are included.
Please feel free to send comments, changes, and additions to me <stevev@jcomm.uoregon.edu>. If I use them, I will try to credit you.
Since things change rapidly, sometimes pieces of this document will be out-of-date or just plain wrong.
When I am looking for more information on a subject or have a parenthetical comment, I will enclose it [in brackets].
David Taylor has uploaded his releases of Linux DOOM to sunsite.unc.edu, directory /pub/Linux/games/doom . linuxxdoom.tgz contains the X executable, while linuxsdoom.tgz contains the SVGAlib executable. Each is a gzipped tar archive of the executables and a README with documentation for the game. doom1v18.tgz is the shareware DOOM data file doom1.wad. If you want to get a complete kit all in one file, retrieve linux-doom-1.8.tar.gz , which contains:
SVGAlib 1.2.5, which is current as of this writing, includes the MouseSystems patch; if you have that version or later, you don't need the one included in the linux-doom-1.8 package.
An HTML-formatted current index of the files in sunsite's Linux DOOM directory is available in ftp://sunsite.unc.edu/pub/Linux/games/doom/INDEX.html .
ftp.idsoftware.com is id's official FTP site; their files are in directory /idstuff. The latest updates to MS-DOS DOOM appear there first. A large archive of user-contributed WAD files and other goodies are available under the /tonsmore directory. The same material is also available by FSP at fsp.idsoftware.com.
If you want to buy the registered copy of DOOM for MS-DOS (which you have to do to legally obtain the registered doom.wad file), call 1-800-IDGAMES. The cost is $40 plus (approximately) $6 shipping, charged to a major credit card. Delivery time is usually around a couple of weeks. DOOM II is sold only in stores or by retail mail order.
This section describes what you'll need to have to run DOOM under Linux.
To run DOOM under Linux, you will need:
For best performance, you should have a 486-33 or better with at least 8M of memory and a VLB or PCI-bus video card (although many people are getting good results with high-quality ISA-bus video cards as well). There are quite a few variables that affect DOOM performance; some people find it unplayable on otherwise spiffy-looking systems and some 386-40 users think it's perfectly playable on their systems.
In addition, if you want sound effects, you will need:
Here's the output of ldd (which gives dynamic linking information for executables) for linuxsdoom, linuxxoom and sndserver. If your shared libraries are older than these versions and you're having problems, you may want to consider upgrading them. Note that if you want to run the X version, you must have the X11R5 libX11.so.3.1.0 available somewhere on your system, since X11R6 uses a different major revision number for its shared libraries.
$ ldd linuxsdoom
libvga.so.1 (DLL Jump 1.1pl8) => /usr/local/lib/libvga.so.1
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.5.26
$ ldd linuxxdoom
libXt.so.3 (DLL Jump 3.1) => /usr/X386/lib/libXt.so.3.1.0
libX11.so.3 (DLL Jump 3.1) => /usr/X386/lib/libX11.so.3.1.0
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.5.26
$ ldd sndserver
libm.so.4 (DLL Jump 4.5pl26) => /lib/libm.so.4.5.26
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.5.26
Obtain the file linux-doom-1.8.tar.gz from the FTP site listed above. You can also obtain the individual parts of the original distribution, but these instructions are geared toward the complete package. If you have DOOM for MS-DOS, then you can use doom1.wad from the shareware version, doom.wad from the registered version, or doom2.wad from DOOM II.
First, extract linux-doom-1.8.tar.gz with the command
zcat linux-doom-1.8.tar.gz | tar xvf -
(it will extract its files into a new directory doom-1.8). Do this as root so that the correct permissions will be placed on the SVGAlib DOOM executable, or see "Cannot get I/O permissions" below to find out how to set the permissions manually. If you already have registered DOOM or DOOM II, and want to use the WAD files that come with those, remove or rename doom1.wad and copy doom.wad or doom2.wad into the doom-1.8 directory.
If you want to use the SVGAlib version of DOOM (I highly recommend it), you will either need to have SVGAlib 1.1.8 or above, or install SVGAlib 1.2.0 from the kit. If you are installing the kit version, copy libvga.so.1.2.0 to /usr/local/lib, make sure /usr/local/lib is in /etc/ld.so.conf, and run ldconfig to make it available. Also copy README.config to /usr/local/lib/libvga.config and edit it to match your system's VGA card and mouse settings. If you already have SVGAlib and use a MouseSystems-type mouse, you may want to install the kit version or apply the patch given in the README file to fix a problem with SVGAlib handling of MouseSystems-type mice.
If you don't want sound effects or don't meet the prerequisites above for sound hardware/drivers, remove or rename the file "sndserver".
When you're ready to try it out, change to a text-mode virtual console and give the command
sdoom -warp 1 1
If you want to play in X, get into X and give the command
xdoom -warp 1 1
Make sure your mouse is in the "No Name" window that DOOM comes up in, or click on the window if your window manager uses click-to-focus input focusing.
Press ESC to get the DOOM main menu, if you want to select something other than the default starting location and difficulty level. Your mouse may not work right away. See "Configuration, Tweaks, and Tricks" for more information about setting your mouse type and customizing the keyboard and mouse.
If you would like to install the binaries in one directory and keep the doom*.wad file in another, you can set the DOOMWADDIR environment variable to the name of the directory where you are keeping doom*.wad so that linux[xs]doom can find it. You can also make a symbolic link to a copy of doom*.wad in a mounted MS-DOS filesystem if you don't want to duplicate doom*.wad into a Linux filesystem (although the game will start much faster if doom*.wad is in an ext2 filesystem). If you can't get DOOMWADDIR to work, see the section titled "DOOMWADDIR doesn't work as advertised" below.
H. Peter Anvin <hpa@ahab.eecs.nwu.edu> has written a shell script that acts as a front-end for Linux DOOM as part of a package including the DOOM executables and the sndcvt program for 8-bit sound support. The package is available by anonymous FTP from eecs.nwu.edu in pub/linux/doom/doom.tgz . The script installs into /usr/local/bin and runs DOOM from /usr/local/lib/doom.
Read the README.linux[xs] and README.dos included in linux-doom-1.8.tar.gz. They contain most of the information here (in briefer form), complete documentation of the game commands and gameplay features, and also explain id's policy towards the Linux port -- it exists because "Linux gives [David Taylor] a woody" and is not officially supported by id. Linux DOOM does not support all MS-DOS doom features (notably music and modem or IPX network play) and probably never will.
Most of the headers in this section contain key words from an error message output by DOOM when something doesn't work.
SVGAlib applications must run as root or setuid to root in order to obtain permission to write to the VGA I/O registers. Run SVGA DOOM as root, or say "chown root linuxsdoom; chomd 4755 linuxsdoom" to make SVGA DOOM setuid to root so it can be run by non-root users.
This means you are trying to run X DOOM without X. You need to start your X server before you can start X DOOM. If you try to set the environment variable DISPLAY without having an X server running, or the variable is set wrongly, then instead you'll probably get a message containing "Cannot connect to server".
If you have to install X, you will need to install the SVGA version of X or one of the versions tailored for various accelerated graphics chipsets, and run the display in 256-color mode (not monochrome or 16-color mode, or the 16- or 32-bit color modes available in XFree86 3.1). DOOM will not work with a display whose color depth is anything other than 8 bits.
This comes up if you give just the command "sdoom" or "xdoom" and wait for the game to play the prerecorded demos in the registered WAD files. At this time, the Linux DOOM executables think they're for version 1.8, while most likely you have WAD files for version 1.9 (if you're a real DOOM fiend) or 1.666 (if you're a wimp and haven't upgraded yet). If you are using the shareware WAD file, then it's still version 1.8 and actually will play its demos.
The way around this, of course, is to invoke sdoom or xdoom with the "-warp" command-line option to jump directly into the game and skip the demos:
sdoom -warp 1 1
This will place you in Episode 1, Level 1 of registered DOOM. If you are using DOOM II, then you give only one number for the level you want to jump into.
These messages from the sndserver program indicate that you don't have the 2.90 version of the Linux soundcard driver installed (if you have a soundcard and the sound driver enabled at all). The latest Linux DOOM release says you need the 3.0 drivers; I'm still running 2.90 and everything seems to be working OK.
The reason you need the more recent driver is that Hannu Savolainen (the sound driver author) included changes to the driver provided by David Taylor to support real-time sound effects. Without the new driver, you will get delayed sounds, garbled sounds, or no sound at all.
You can get the latest Linux soundcard driver from sunsite.unc.edu, in the directory pub/Linux/kernel/sound, in file snd-driv-2.90.tar.gz. Two patches, snd-driv-2.90.patch1.gz and snd-driv-2.90.patch2.gz , are also available there, so you should probably get them. The snd-driv-2.90.tar.gz file is meant to replace the drivers/sound directory tree in the 1.0 Linux kernel source. These drivers are standard in the Linux 1.1 and 1.2 kernels. You will have to compile the kernel with the new, correctly configured sound driver, install the kernel, and boot from it before DOOM sound effects will work correctly.
This could happen along with the message described in the section titled "ioctl(dsp,...)==-1" above. If sounds are missing, but you have all the other prerequisites taken care of, make sure that sndserver is in your executable search path where DOOM can find it.
Even if you have the current sound driver, you may need to recompile your kernel anyway to enable SYSV IPC, which includes shared memory (that is, the ability for multiple processes to share a common region of physical memory between them). Linux DOOM uses a display buffer shared between the DOOM process and the X server to greatly speed up the process of drawing your DOOM display; without shared memory DOOM would have to transmit a 64K bitmap through a UNIX socket for every frame and would not perform well at all.
The question about whether to include SYSV IPC is in the first round of questions asked when you run "make config" in the Linux kernel source directory.
DOOM is looking for the doom*.wad file that it needs. This could mean that you haven't installed a doom*.wad file, that more than one of doom1.wad, doom.wad, or doom2.wad is available, or that you have an incorrect setting for the DOOMWADDIR environment variable that DOOM uses to locate doom*.wad.
The name of the WAD file is significant and is used to determine what mode the game should run in, like this:
You did something dumb and gave the WAD file the wrong name. DOOM determines whether it should act like the shareware or registered version by the name of the WAD file. The shareware wad (about 4.8 megs in size) is called doom1.wad, and the registered version (about 11 megs) is called doom.wad. If you rename the shareware doom1.wad to doom.wad, DOOM will die when it can't find resources for the registered version in the shareware WAD. If you rename the registered doom.wad to doom1.wad, then DOOM won't let you play the second or third episodes.
Versions of SVGAlib before 1.2.5 had some bugs in the mouse input code for a couple of mouse types. Upgrade to the latest version at ftp://sunsite.unc.edu/pub/Linux/libs/graphics/ . If you got the linux-doom-1.8 package mentioned above, you have a version patched to work right with just MouseSystems-type mice.
If none of the advertised keyboard commands work, put the mouse pointer inside the DOOM window (or click on it if your window manager is set for click-to-type input focusing) so that it is the keyboard focus.
If just the SHIFT, CTRL, or ALT keys don't seem to work right in DOOM, this is the result of your X window manager wanting to grab certain keys for its functions. fvwm and olwm/olvwm have default actions or modifiers bound to the SHIFT, ALT, and CTRL keys. You can redefine DOOM's key command bindings (see the section titled "The .doomrc File"), turn off the window manager bindings for those keys (see your window manager man page), or use a different window manager (twm is commonly available and doesn't treat those keys specially).
The very first released version of Linux X DOOM had a bug with the -2, -3, and -4 command-line switches that scale the DOOM window size. David Taylor says you're stupid to use them (they kill the frame rate) but ended up putting an updated linxdoom.tgz on sunsite a couple days after the first version was released that fixed the problem with -2 and -3. Pixel quadrupling (the -4 switch) is still broken, but you need a display bigger than 1280x1024 to use that anyway. You really are best off not using -2, -3, or -4 to magnify the window. You can use a lower-resolution video mode in X (see "Making lower-resolution X video modes") to magnify the window and get maximum frame rate.
The originally released version of Linux DOOM had another bug -- the DOOMWADDIR environment variable couldn't be used to locate the doom*.wad file in a directory other than the current one. This has been fixed in the most recent release (94/9/13).
Linux X DOOM uses a local colormap in X because it needs all 256 colors. Your mouse pointer must be inside the DOOM window for the DOOM colors to look right. Of course, this makes the colors of the rest of your display look weird instead. DOOM also does palette tricks that may cause your entire screen to flash red, white, or green as it manipulates the colormap.
Harry C Pulley (hpulley@uoguelph.ca) writes:
8 bit sound for DOOM:
Charles <nsa@link.xs4all.nl> wrote a package called
doom_16to8bit_snd.tgz on sunsite.unc.edu in
/pub/Linux/Incoming. It probably won't stay in that
directory and is probably available from other sites as
well. This package allows users of non-SB16 cards to hear
the sound effects on their card. It works by patching
sndserver to send the output to a pipe which sndcvt reads
and sends, in 8-bit format, to /dev/dsp. Most cards which
have a 8-bit /dev/dsp device should work with this setup.
Paraphrasing the readme file, you must run "sed
s,/dev/dsp,/tmp/dsp,g < sndserver > sndserver.new"; then
replace sndserver with sndserver.new. Next, run "mknod
/tmp/dsp p" to create a pipe for sndcvt.
Now, to run doom with sound, run "sndcvt & linuxxdoom"
(optionally add a "&" to put the linuxxdoom in the
background). sndcvt will automatically die when doom is
finished.
The package includes a binary and source code.
On my 486DX-33 with 8MB of RAM, VLB video and a clone 8-bit
SB card, this works great and I get good performance. The
sound is slightly behind the action but I have heard users
with genuine SB16 cards complain about the same thing. I
have never heard it on a SB16 so I can't tell you if there
is more delay or not. I suspect that there might be more
delay due to pipe and context switch overhead.
Note that you still only get sound effects; no background
music :-(
David.Lecomber@comlab.oxford.ac.uk had this problem and said that upgrading his system's C and X11 shared libraries to the current versions got rid of it. See the section entitled "Compatibility Requirements" for full compatibility information.
The 1.666 registered doom.wad has a bug in E3M9 (Warrens) resulting from a bogus linedef in the level. A binary patch for this has been discussed in alt.games.doom and if you know what I'm talking about here, then you can probably manage to apply it and may even want to.
Sound PWADs (WAD files that are intended to replace DOOM sound effects) don't seem to work with Linux DOOM.
You can't use the mouse for a control device in Linux X DOOM. Well, you can (see the section titled "Linux-specific command-line switches") but it doesn't work very well. The mouse works just fine in Linux SVGAlib DOOM.
David Taylor contributes this explanation about the lack of mouse support and music in Linux X DOOM. Note that David obviously found time to do the SVGAlib DOOM port after writing this.
Mouse:
I'm going to go into this one because it's pretty frustrating, and
it would be nice if a sympathetic X coder took it to heart. You
mentioned the grim -grabmouse thing. That was one of several failed
attempts. First off, the mouse cursor is pretty darn important in
X and other windowed environments. If a process is misbehaving,
you drag the pointer elsewhere and kill it. It's therefore considered
exteremely rude (and rightly so) to grab all the mouse input.
Nonetheless, if you think about how mouse control works for DOOM,
this is what is required. So assuming we're going to be rude, what
I need next is a way to get what are called "mickeys", the bare-bones
information sent from the mouse to the computer. They're basically
a delta-x and delta-y movement pair that simply tell you how much
the mouse has moved.
Unfortunately, X in its attempt to be nice to most normal apps,
does not give you this information. Instead, it gives you the new
pointer position on the X server. This causes several problems.
One is that it doesn't have to stream this information to you at
the rate the mouse is providing it. It can simply collect up
several delta pairs and give you the resulting new position. That
causes jerkiness. But let's say for the sake of argument (and the
sake of -grabmouse) you sort of reverse this by taking the deltas
of what X is feeding you.
What happens when you move the mouse to the left side of the window
and want to move your character left? Nothing. It registers as
zero movement even though you're moving your mouse. You therefore
need to periodically warp the mouse pointer back to the center of
the window to keep it from getting near the edge.
I think this is where the real trouble is coming from. I believe
information is being lost in the warp. A smooth drag to the left
has to be interrupted several times a second to keep it from getting
to the edge. These interruptions appear as stutters in your
movement, and you get that not-too-nifty feel of -grabmouse.
The thought of opening up ol' /dev/mouse even though the X server
is using it crossed my mind, but I didn't even try. I wasn't
looking for trouble.
But besides it being somewhat painful to implement, the thought
that everyone would have to play with the keyboard in deathmatches
appealed to be instantly. I'm a fairly good keyboard player but
feel like a blind cripple against any decent mouse player. I
know, I know.. power corrupts.. :)
I should point out here that Hannu is not the only nice guy writing
code for Linux. The author of svgalib, Harm Hanemaaijer, was trying
to sway me to write an svgalib version. I said I didn't have time
and wanted to write one version for all high-end UNIX platforms
and that by the way, svgalib had no provision for portable mouse
measurements. He promptly added that feature, and I hope other
games out there capitalize on it as I probably should have. I am
the part owner of a small shareware game company on the side, and
if it's any comfort to him, they're writing an extremely high-quality
game which will be available for Linux with both X and svgalib
versions. (sorry- no dates/details. deadlines=stress.)
Music:
Because the existing code isn't ours and isn't terribly portable
in this case, it's a pain to do from scratch, and although missed,
it is not essential to the experience. Bobby's gonna kill me for
saying that.
Your .doomrc file has a variety of customization options for DOOM. The MS-DOS version calls the file default.cfg instead and has a SETUP utility that can change many of the important options. Since you're a wizardly Linux user, you get to edit the file manually instead. Some options are set within DOOM itself, and those won't be described here.
The file has a simple format: The first word on each line is a DOOM variable, and following it after some whitespace characters is that variable's value. If you don't have a .doomrc in your home directory when you first start DOOM, it will create one with default values. Once you customize it, DOOM will keep those values.
A group of variables contains keycodes for DOOM keyboard commands. These are:
The number following each is a keycode for the desired key. For most normal typing keys, this is the ASCII code of the character generated by the unshifted key, i.e. the 'A' key has keycode 97 (ASCII lowercase 'a'). I haven't figured out what the keycodes are for all of the non-ASCII keys, but a brief list in the README.linuxs has some codes:
Note that if you are using Linux X DOOM, your X window manager may interfere with the use of SHIFT, CTRL, or ALT (see "Some (or all) keyboard commands don't work (X)"). DOOM also has some non-configurable commands -- ESC to bring up the main menu, 1-7 to change weapons, F1-F10 for various options, TAB to toggle the automap. You probably don't want to assign other commands to those keys, and you may also see your window manager override the function keys.
The variable mousedev takes a string giving the device name of your mouse, i.e. "/dev/ttyS1" or "/dev/mouse". mousetype gives the type of the mouse, one of "microsoft", "mousesystems", "mmseries", "logitech", "busmouse", or "ps2".
If you want to disable use of the mouse completely, set the variable use_mouse to 0.
The variables mouseb_fire, mouseb_strafe, and mouseb_forward take mouse button numbers for the mouse buttons you want to perform those functions. The mouse button numbers may not correspond neatly to the button locations; for example, on my 3-button mouse the left button is button 2, the middle button is button 1, and the right button is button 0. Your mouse may vary.
mb_used is a Linux-specific variable in .doomrc. It controls the size of the heap used by DOOM for dynamic storage. The approximate memory requirements of your DOOM process are 1.6+mb_used megabytes for DOOM itself, and another 1.6 megabytes or so for sndserver. mb_used is 2 by default. If you have more memory, you may slightly reduce hesitations in the game caused by DOOM swapping resources in and out by setting it to a higher value (as long as this doesn't induce virtual-memory swapping in Linux itself); increasing it really has no consistent beneficial effect on overall frame rate in timing experiments that I've done, but I run with mb_used set to 4 anyway.
sndserver contains the pathname of the sndserver program, normally just "sndserver".
snd_channels controls the number of simultaneous sound effects that DOOM will try to play. By default, it will play no more than 3 overlapping sound effects at once. If you have a really nifty sound card that can handle it and don't mind a slight performance hit, you can set this to a higher value (I successfully use 8 with my Gravis Ultrasound).
If I haven't mentioned a .doomrc variable here, it's either because 1) you can control it from DOOM itself, 2) it's documented in the standard DOOM README, or 3) it's completely irrelevant in Linux DOOM.
These command-line switches are (usually) specific to the Linux version (and maybe other UNIX/X versions).
-disp and -geom appear to be analogous to the standard X -display and -geometry command line options for specifying the X server to connect to and the initial window geometry. -geom doesn't take the standard X geometry specification (WxH+X+Y) but instead takes two numeric arguments for the initial X and Y position of the window (which may be ignored by your window manager).
-2, -3, and -4 respectively double, triple, and quadruple the window size and pixel size of the DOOM window. -4 doesn't currently work right (and probably never will). -2 and -3 work but slow down your frame rate immensely.
-grabmouse is an undocumented switch that enables what is apparently an experimental mouse control mode for X. You probably won't like it at all, so be warned before you try it. The frame rate goes way, way down when you use it, but other than that mouse controls seem to work like they do in DOS. You may also have trouble if you use click-to-type keyboard focusing in your window manager, since you don't have any time to click on the window to set the keyboard focus before DOOM grabs your mouse.
The -net switch that controls network game play has a different syntax. You follow it first with the node number your machine should use, and then list the domain names or IP addresses of the other machines in the net game.
Command-line switches not described here (there are lots) are covered in the standard DOOM documentation, which is in the README.linux file that comes with the Linux executables.
This is pretty much obsolete with the introduction of Linux SVGAlib DOOM, which runs full-screen at 320x200 resolution in a virtual console.
Because the -2 and -3 switches make your DOOM window readable at the expense of the game's frame rate, you will probably want to use a low-resolution video mode in XFree86 as a way of expanding the window to a readable size while keeping the game fast.
Unfortunately, many of the video mode definitions being thrown around the net are absolutely ludicrous. They may work for their authors, but some have refresh rates so high that those authors may soon be found dead with charred bits of exploded monitor blasted into their steaming bodies.
If you want to avoid a toasted monitor and possible flaming horrible death, the safest thing to do is probably to just use a standard mode like 640x480 that monitors are designed to handle. If you try for a lower-resolution mode than that, make sure that you don't exceed your monitor's horizontal or vertical refresh rates. Use as low of an SVGA dot clock as your card will support and be aware that 320x200 VGA uses some option bits in the VGA registers that double pixels horizontally and vertically -- you probably can't get a SVGA card to duplicate that mode without using those mode bits.
XFree86 3.1 has a generic 320x200 256-color VGA mode driver (use chipset "generic"). You might try that.
Linux DOOM is perfectly happy with the supplementary WAD files that MS-DOS DOOMers have been playing for months, with the important exception that sounds in WAD files aren't loaded (there's a trick to partially hack around this -- see below). IMPORTANT: You must have the registered version of DOOM (with the 11 meg doom.wad) or DOOM II (with a 15 meg doom2.wad) to use the -file command-line option that loads add-on WADs. Buy a copy of DOOM and join the fun.
If you want to load a WAD file that completely replaces the sound effects in DOOM, you can trick sndserver into loading the sound effects from that file by making sndserver think that it's one of the normal DOOM WADs, an idea suggested by Joe Zbiciak <im14u2c@texas.net> that inspired me to write this script:
#!/bin/sh if [ -n "$SNDFILE" ] then ln -fs $PWD/$SNDFILE /tmp/doom.wad export DOOMWADDIR=/tmp sndserver.bin $* rm -f /tmp/doom.wad else sndserver.bin $* fi
To use this script, rename your existing sndserver binary to "sndserver.bin", then place this script in the same directory with the name "sndserver" and make it executable. If you set the environment variable SNDFILE to the name of the WAD with the sound effects, then it will trick sndserver.bin into loading sounds from that file. Note that this will _not_ load unspecified effects from the normal DOOM WAD file as MS-DOS DOOM does when you specify a sound-effects replacement WAD with the -file switch.
One problem you may encounter is that WAD files containing their own demos may cause DOOM to abort with the message "Error: Demo is from a different game version!". This happens for MS-DOS-based DOOM players as well, and is because DOOM won't play demos from a different game version. It probably doesn't mean that you can't play the WAD; it just means that you will have to use command-line options to start the level you want without going through the WAD's demos. For example, to start cleim10.wad, which replaces all of episode 2, say something like:
linuxxdoom -file cleim10.wad -skill 4 -warp 2 1
This loads the replacement wad cleim10.wad, sets your difficulty level to ultra-violence, and "warps" to episode 2, level 1.
Your friends cursed with MS-DOS can run all kinds of DOOM map editors that let them modify levels or create their own, change the "thing tables" in DOOM.EXE, and otherwise have all kinds of fun. So far, few of these exist for Linux. I have heard of a port of the popular DEU editor that runs with SVGAlib under Linux, and rumors are that a later version will run under X. I would be interested in in hearing from authors of DOOM utilities who would be willing to release source code for porting to Linux. Please contact me (stevev@jcomm.uoregon.edu) if you would like to let me try porting your utility to Linux.
You may have received this document as a news posting formatted from my HTML source. If you would like to see this as a World Wide Web page, open the URL http://jcomm.uoregon.edu/~stevev/Linux-DOOM-FAQ.html.
I said this at least three times already, but read the file README.linux[xs] that comes with the binaries. It's a note from David Taylor stuck on the top of the MS-DOS README file, so it's got what you need to know about the game and how to play it.
If you need to know how to recompile your Linux kernel, configure XFree86, or edit your own WADs, there are much better FAQs available than I can write.
For Linux and XFree86 configuration information, there are FAQs available by FTP and WWW from sunsite.unc.edu. Start with the file pub/Linux/docs/HOWTO/META-FAQ or the Linux Documentation Project Home Page at URL http://sunsite.unc.edu/mdw/linux.html.
A DOOM WWW (World Wide Web) page, DoomGate, is available at URL http://doomgate.cs.buffalo.edu/.
"finger help@idsoftware.com" returns a status report about DOOM and id's next game, Quake. id also has their own Web site at http://www.idsoftware.com/ and an FTP site at ftp.idsoftware.com/.
The comp.os.linux.setup newsgroup is a good place to ask for information about how to set up Linux itself. comp.os.linux.x is for questions about setting up X on Linux. Stuff related to both Linux and DOOM should fit into comp.os.linux.misc. The comp.windows.x.i386unix newsgroup deals mostly with XFree86 for various 386/486 UNIX variants including Linux. rec.games.computer.doom.* is where the DOOMers hang out (beware -- they're mostly MS-DOS users). The DOOM FAQ is posted to rec.games.computer.doom.announce. rec.games.computer.games.doom.announce is where many people post announcements of DOOM-based utilities and new WAD files.
![[berzerk-punching an imp]](doomact1.gif)
Go to
DoomGate