
Note: infant2 no longer has any Doom files. The Doom archive has
temporarily moved to ftp.orst.edu until a more permanent home can be found.
The directory on this temporary site is still pub/doom.

--

[Note: This latest edition has been automatically formatted (with
some minor hand editing) from the new! HTML version.  If you
have a World Wide Web browser, open URL:
http://jcomm.uoregon.edu/~stevev/Linux-DOOM-FAQ.html
for the fancy hypertext version (including a few gratuitous
screen shots).  If you don't, you'll notice this version looks
somewhat different from the last version.]

Linux DOOM FAQ

(revision 4, 94/10/28 -- now in HTML!)

Compiled by Steve VanDevender (stevev@efn.org)

	  1. Introduction
		  1) What's DOOM?
		  2) This document

	  2. Where to get Linux DOOM and DOOM add-ons
	  3. Prerequisites and installation
		  1) Compatibility requirements
		  2) Installation instructions

	  4. Problems and solutions
		  1) DISPLAY=(null)
		  2) ioctl(dsp, ...) == -1
		  3) Could not get shared memory
		  4) Error: Game mode indeterminate
		  5) R_TextureNumForName: SW1BLUE not found
		  6) Cannot find STBAR; Demo is from different version
		  7) Sounds are missing or garbled
		  8) Some (or all) keyboard commands don't work
		  9) Pixel doubling/tripling options look funny
		 10) DOOMWADDIR doesn't work as advertised
		 11) The colors are totally bogus
		 12) I have an 8-bit soundcard, how can I get sound?
		 13) Segmentation fault during startup
		 14) Other known problems (not all solvable)

	  5. Configuration, tweaks and tricks
		  1) The .doomrc file
		  2) Linux-specific command-line switches
		  3) Making lower-resolution X video modes
		  4) Dealing with add-on WADs
		  5) DOOM editors

	  6. Other sources of information

------------------------------------------------------------------------------

1. Introduction

1.1) What's DOOM?

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 XFree86.

1.2) This document

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 port 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@efn.org).  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].

------------------------------------------------------------------------------

2. Where to get Linux DOOM and DOOM add-ons

David Taylor has uploaded his releases of Linux DOOM to sunsite.unc.edu,
directory /pub/Linux/games/x11/action/doom , in file linxdoom.tgz .  This is a
gzipped tar file of the executables and a README with documentation for the
game.  doom1wad.tgz is the shareware DOOM data file doom1.wad.  This directory
contains other Linux-specific DOOM support files, like the 16-to-8-bit sound
converter doom_16to8bit_snd.2.tgz .  There are also a couple of joystick
drivers, joystick4doom.tgz and smooth-joystick4doom.tgz .  I haven't tried
other of these, so you'll have to figure out which one works better for you.

An HTML-formatted current index of the files in sunsite's Linux DOOM directory
is available in
ftp://sunsite.unc.edu/pub/Linux/games/x11/action/doom/INDEX.html .

infant2.sphs.indiana.edu is probably the biggest DOOM FTP site.  However,
because of a space shortage, for the time being they have Linux DOOM have been
moved to a different machine, mimosa.astro.indiana.edu, in directory
pub/doom/id/LINUX [note: as of this writing, the linxdoom.tgz there does not
have the DOOMWADDIR fix].  This is also one of the best sites for getting
add-on WAD files and the Linux version of DEU, one of the most popular DOOM
editors.  The WAD archives and other DOOM add-ons are still available there in
pub/doom .

However, infant2 is frequently spammed to the limit with other DOOM fanatics,
and you may want to go to a site that's topologically closer to you, so here
are several sites that mirror infant2.  Here's a list of DOOM FTP sites
recently posted to alt.games.doom.announce:

	o ftp.uwp.edu, pub/msdos/games/id/home-brew/doom/
	o ftp.orst.edu, pub/gaming/doom/
	o ftp.uni-erlangen.de, pub/pc/msdos/games/ID/DOOM-stuff/
	o aurora.bld189.jccbi.gov, /infant2
	o nctuccca.edu.tw, /PC/games/DOOM/
	o ftp.cdrom.com, pub/doom/
	o ftp.luth.se, pub/misc/games/doom/
	o ftp.demon.co.uk, pub/ibmpc/games/id/
	o ftp.sun.ac.za, pub/msdos/doom/
	o ftp.sunet.se, pub/doom/

ftp.uwp.edu is id's official FTP site; their files are in directory
pub/games/id.  The latest updates to MS-DOS DOOM appear there first (but
probably propogate to infant2 and mirror sites quickly and could be more
accessible there).

Jan Sandorf (jsf@krynn.solace.mg.se) has put Linux DOOM up for FTP in Europe
at ftp.solace.mh.se, directory pub/Linux/games/, in file linux-doom.tar.gz .

If you want to buy the registered copy of DOOM for MS-DOS (which you would
have to do to legally obtain the registered doom.wad file), call 1-800-IDGAMES
[North America only; I'd like to know the number for international callers to
use.] The cost is $40 plus (approximately) $6 shipping, charged to a major
credit card.  Delivery time is usually around a couple of weeks.

------------------------------------------------------------------------------

3. Prerequisites and installation

This section describes what you'll need to have to run DOOM under Linux.

3.1) Compatibility requirements

To run DOOM under Linux, you will need:

	o Linux 1.0 or above with SYSV IPC enabled
	o XFree86 2.0 or above (if you compiled it from source yourself, make
	  sure to have the MITSHM extension enabled)
	o The Linux DOOM executables
	o A doom*.wad file for version 1.666 of DOOM (which contains all of
	  the game data)

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:

	o The Linux sound driver (Voxware) 2.90 or above (cat /dev/sndstat to
	  find out your version)
	o A 16-bit soundcard (such as the Sound Blaster 16, Pro Audio Spectrum
	  16, or Gravis Ultrasound).  You may be able to get your 8-bit
	  soundcard to work with the package doom_16to8bit_snd.tgz -- see the
	  section titled "I have an 8-bit soundcard, how can I get sound?".

Here's the output of ldd (which gives dynamic linking information for
executables) for linuxxoom and sndserver.  If your shared libraries are older
than these versions and you're having problems, you may want to consider
upgrading them.

$ 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

3.2) Installation instructions

Obtain the file linxdoom.tgz from one of the FTP sites listed above.  If you
don't have MS-DOS DOOM, you can get the shareware doom1.wad file, probably in
the same place, in the file doom1wad.tgz.  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.

The simplest installation is to extract linxdoom.tgz into a directory and
place the doom*.wad file of your choice in that same directory.  You have to
be running the X server before you can start DOOM.  If you have met all of the
prerequisites above, then just run linuxxdoom and have a Hell of a good time!

If you don't have the appropriate sound card or sound driver available, rename
or delete the program "sndserver" to disable sound effects.  Many respondents
say that not running sndserver also speeds up the frame rate significantly.

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 linuxxdoom
can findit.  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  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 included in linxdoom.tgz.  It contains most of the
information here (in briefer form), complete documentation of the game
commands and gameplay features, and also explains 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, mouse control, and modem or IPX network play) and
probably never will add the missing ones.

For additional configuration options, see the section titled "Configuration,
Tweaks, and Tricks".

------------------------------------------------------------------------------

4. Problems and solutions

Most of the headers in this section contain key words from an error message
output by DOOM when something doesn't work.

4.1) DISPLAY=(null)

This means you are trying to run DOOM without X. You need to start your X
server before you can start 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.

4.2) ioctl(dsp, ...) == -1

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.  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.

If you get messages like "Could not find lumpname: [something]" then that
means you don't have DOOM II yet.  These messages are harmless and occur
normally; they just mean that sndserver can't find sound files specific to
DOOM II.

4.3) Could not get shared memory

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.

4.4) Error: Game mode indeterminate

DOOM is looking for the doom*.wad file that it needs.  This could mean that
you haven't installed a doom*.wad file 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:

	o doom1.wad
	  Run in shareware mode (no -file switch, only the first episode is
	  available)
	o doom.wad
	  Run in registered mode (-file switch works, three episodes
	  available)
	o doom2.wad
	  Run in DOOM II mode (-file switch works, one episode of 32 levels)

4.5) R_TextureNumForName: SW1BLUE not found

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.

4.6) Cannot find STBAR; Demo is from different version

These messages come up if your doom*.wad file is from a version of DOOM other
than the latest one, 1.666.  You will need to patch your doom*.wad file to the
latest version.  Unfortunately, you will have to install DOOM under MS-DOS and
run DOS to do this, since the patch program runs under MS-DOS.  If you can't
bring yourself to do this, get doom1wad.tgz with the shareware version of the
1.666 doom1.wad, or buy the MS-DOS registered DOOM and get a friend with DOS
to patch it to 1.666 and give you the files.

If you are really desperate, try invoking doom with the "-warp" command-line
option to jump directly into the game and skip the demos:

linuxxdoom -warp 1 1

4.7) Sounds are missing or garbled

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.

4.8) Some (or all) keyboard commands don't work

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).

4.9) Pixel doubling/tripling options look funny

The very first released version of Linux 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 (section 5.3) to
magnify the window and get maximum frame rate.

4.10) DOOMWADDIR doesn't work as advertised

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).

4.11) The colors are totally bogus

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.

4.12) I have an 8-bit soundcard, how can I get sound?

Harry C Pulley (hpulley@uoguelph.ca) writes:

     8 bit sound for DOOM:

     Charles  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.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 :-(

4.13) Segmentation fault during startup

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.

4.14) Other known problems (not all solvable)

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.  Well, you can (see the section
titled "Linux-specific command-line switches" ) but it doesn't work very well.
This is one of the most frustrating things for me (I'm a die-hard mouse user
because I find it the best all-around control for both speed and precision)
but I can think of several programming reasons why it is very difficult to
support under X.

David Taylor contributes this explanation about the lack of mouse support and
music in Linux DOOM:

     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.

------------------------------------------------------------------------------

5. Configuration, tweaks, and tricks

5.1) The .doomrc file

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:

key_right: turns you to the right key_left: turns you to the left key_up:
moves you forward key_down: moves you backward key_strafeleft: moves you
sideways to the left key_straferight: moves you sideways to the right
key_fire: shoots or activates your current weapon key_use: activates doors,
lifts, and switches key_strafe: when held down, key_right and key_left act
like key_straferight and key_strafeleft key_speed: when held down, increases
the rate of motion of all movement keys 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-typing keys, but those given in the default .doomrc are:

up-arrow 173 down-arrow 175 left-arrow 172 right-arrow 174 SHIFT 182 CTRL 157
ALT 184 Note that your X window manager may interfere with the use of SHIFT,
CTRL, or ALT (see section 4.7).  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.

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.

5.2) Linux-specific command-line switches

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.

5.3) Making lower-resolution X video modes

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.

5.4) Dealing with add-on WADs

Linux DOOM is perfectly happy with the supplementary WAD files that MS-DOS
DOOMers have been playing for months, with the important exception that sound
WADs don't seem to work at all (you can specify them, but no sound effects get
replaced).  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.

One problem you may encounter is that older 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.

5.5) DOOM editors

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 them to Linux.  Please contact me
(stevev@efn.org) if you would like to let me try porting your utility to
Linux.

------------------------------------------------------------------------------

6. Other sources of information

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 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.

DOOM also has a large and detailed FAQ available from infant2.sphs.indiana.edu
in directory pub/doom/text/ , file dmfaq58.txt .  Much of the information is
tailored to MS-DOS specific problems with DOOM, but is probably the best
general introduction to the game and its culture.

A DOOM WWW (World Wide Web) page, DoomGate , is available at URL
http://www.cedar.buffalo.edu/~kapis-p/doom/DoomGate.html.

"finger help@idsoftware.com" returns a status report about DOOM and Id's next
game, Quake.

The comp.os.linux.help newsgroup is a good place to ask for information about
how to set up Linux itself.  The comp.windows.x.i386unix newsgroup deals
mostly with XFree86 for various 386/486 UNIX variants including Linux.
alt.games.doom is where the DOOMers hang out (beware -- they're mostly MS-DOS
users).  It's also where copies of the DOOM FAQ are posted.
alt.games.doom.announce is where many people post announcements of DOOM-based
utilities and new WAD files.

