Running Doom under Linux

[Edit: 2014-03-05: I’m closing this thread now.  Check out the references to chocolate-doom in the comments below as probably our last resort to actually compile Doom from a reasonably corrected source for our modern times.  Beyond that, I’m pretty much as clueless as you are]

I love Doom. Actually, Doom II was the first PC game I ever got in my hands onto. The game was fast-paced, gritty and scary like hell, even with its 8 bit architecture. The sound was ominous, the levels and monsters were darn frikin’ hard to go against … I totally agree with anyone that would put it onto their top list of games since the beginning of that instrustry we call “gaming”.

This post is about compiling Doom on a modern Linux distro.

The source of the Doom engine (which ran Doom, Doom II, and Ultimate Doom) was released in 1997 as a Linux port that used X with a separate sound server. It is still available here.

I got interested in the source code in 2003 and started taking notes about compilation, PCX and 8bit paletting, and WAD (de)construction. Now, in 2010, I re-read my notes and decided to give it a go again, this time putting those notes public, although there’s nothing really new here for anyone. With so many ports of Doom that have spawned over the years, there are better options today in playing Doom with full screen graphics, perhaps in 3D, and MP3 sound and music instead using 16 bit mono WAVs and on board MIDI.

But I like retro stuff and this is as close as we can get to the original. The SDL version, made by SDL creator Sam Lantinga, is a straightfoward port of the original with sound and can run on 640 x 480 without palletting. It’s a great way to see how SDL works. But before compiling that version, keep reading this post, there is at least one modification you should be aware of.

Fixing errors and compiling

The first thing about Doom, is that its creator, id software, did released the source code but not any of the data files to run it, called IWADs, which contain the images and sounds of the game. You must either have the commercial version of Doom, Doom II or Ultimate Doom, or the shareware version (a copy of the shareware IWAD is available here). Unzip it and put that file somewhere on your system. We’ll need to point to it later on.

Unzipping the file gives you two packages, the source code of DOOM and a separate sound server that Doom will imbed at run time (apparrently, id licenced a copyrighted sound engine at the time, which is why there is no original DOS release: ‘A mistake’ says John Carmack in the README.TXT file.)

Unzip the source code and make the following changes:

In i_video:49, replace

#include <errnos.h>

with

#include <errno.h>

In i_sound.c:166 and i_video.c:669, delete all declarations of

extern int errno;

and include this file somewhere at the top of i_sound.c:

#include <errno.h>

In s_sound.c:367, replace

#ifndef SNDSRV

with

#ifndef SNDSERV

In the Makefile, add the -DSNDSERV define for compilation.

Finally, and this affects both the original and SDLDoom, change d_main.c:587 from

doomuwad = malloc(strlen(doomwaddir)+1+8+1);

to

doomuwad = malloc(strlen(doomwaddir)+1+9+1);

This “off-by-one” error will generate a ASSERT error in malloc.c:3074 once the X display kicks in. The gdb debugger will tell you so, and yet we are very far from any video initialization at this moment. It took me a while to trap this.

Compile by simply calling ‘make’ at the command line. Everything should compile under 30 seconds. Don’t (?) worry about all the warnings you’ll see passing by. They shouldn’t affect the game at this point. Feel free to clean up the code if you like.

Compiling the sound server

Unzip the sound server’s package and change to that directory. Simply call ‘make’ at the command line.

Move the ‘sndserver’ binary located in the ‘linux’ directory to the same directory you put your IWAD, mentionned above.

Switching to 8 bit

Doom runs in 8 bit (256 palettized colors) at a whoppin size of 320 x 200 pixels. It’s better to simply call another X desktop instead of ruining your current setup.

Issue the following on the command line.

sudo startx -- :1 -depth 8 vt8

This starts another desktop at vt8 (i.e. Ctrl-Alt-F8. You can return to your original desktop with Ctrl-Alt-F7 or loggin off from that session). You’ll notice how rough your desktop will look because of the 8 bit palette it’s running on.

Note that you will be running your new desktop with super-user privileges, so be VERY careful.

Open up a console and set an environment variable called DOOMWADDIR like so:

export DOOMWADDIR=<my path>

and replace <my path> with the location of the IWAD and sound server. If you dip into the code, there always a way to set those changes to a permanent location without defining this value or doing it through some parameter.

You can now run the binary located at linux/linuxdoom in the source code directory.

You’ll see your desktop flashing because Doom will set up its palette to it.

Voilà. Enjoy playing Doom on an itsy bitsy scale. 🙂

You can alway resize your desktop to 640 x 480 to see it a little larger. Don’t forget to set it back to its original size. I believe if you don’t, it will screw up your default settings once you run X again from a fresh boot.

If you don’t want to go through all this trouble, make the change I recommend to d_main.c:587 in SDLDoom, compile it and call the -fullscreen parameter to play Doom at a reasonable scale.

  • Trackback are closed
  • Comments (17)
    • baxzius
    • 07/13. 2010 7:28pm

    thanks… for helping me to compile,make and installing the doom source code. you are great.
    do you have any other greatest source codes?

    • narc
    • 07/13. 2010 8:00pm

    @baxzius
    I compiled Quake 2 a few years back when I bought the official Linux port [can’t get the levels if you don’t buy the official version ;-)]. The port crashed at some level and my only hope was to successfully compile the GPL version to continue my game. I believe I used gcc 2.7.2.3 because gcc 3 created the same crashes. Q2 is located on the same server as the Doom source code. I haven’t tried it since but if you’re up to it, good luck and let me know about it.

  1. well i compiled it successfully using the source of
    lsdldoom.tar.gz.but later i try to execute the binary
    file called lsdldoom. i got following message? why?

    LsdlDoom v1.4.4.4 (http://firehead.org/~jessh/lsdldoom/)
    Z_Init : Allocated 6016Kb zone memory
    found /usr/local/share/games/doom/doom1.wad
    IWAD found: /usr/local/share/games/doom/doom1.wad
    IWAD tag not present: /usr/local/share/games/doom/doom1.wad

    • narc
    • 09/14. 2010 8:40pm

    @baxzius
    I’m not a real fan of this version. It took me a while to compile it (link errors galore between C and ASM object files) and found it incredibly difficult to follow with unmistakable errors that old compilers might let go but unforgivable in terms of actual C syntax (extern on static variables ???). The changes in the info.c file are unwarranted if you only wish to play with the shareware version (Why does it tell me that CRBRICK is missing? Are there other PWADs ?).

    As for your actual problem, I did not experience it although I couldn’t run the game myself either. ‘IWAD’ are the first 4 characters of an official .wad file (the homebrew versions are PWADs). Open up that file up and check the header. Your answer lies in file d_wad.c, lines 635-85. Use a debugger and check the IWAD’s compatibility with the actual linuxdoom you compiled earlier.

    Good luck.

    • HJunk
    • 01/23. 2011 4:26pm

    How the hell is possible to solve the problem that baxzius also had? I mean I hate tutorial where everything seems so clear..

    • narc
    • 01/24. 2011 1:57am

    @HJunk
    Please read the comment above yours (!?) My tutorial is about the original Doom source code while baxzius had problem with LsdlDoom (not to be confused with SDLDoom, see above), a heavily modified port and extension to which I don’t provide any solution. I abondonned the idea to run that program altogether. Sorry if there was any confusion.

    • HJunk
    • 01/24. 2011 4:38am

    Ok. I get it and Ive compiled the linuxdoom1.10 version instead of the SDL one. Neither I can compile sndserv ( got segmentation fault ) nor I can run the linuxxdoom as it doesnt find the .wad file (it says W_InitFiles no files found ). What can I do?

    Thanks

    • HJunk
    • 01/24. 2011 7:47am

    I solved at last. Shareware .was is not accepted. To avoid problems like “W_InitFiles not found” you can either create a bash file or run doom with the command:

    ./linuxxdoom -game save -file /home/USER/Desktop/linuxdoom-1.10/linux/doom.wad -userid /home/USER/Desktop/linuxdoom-1.10/linux/save

    where: .wad has to be the original one.
    USER is the user folder
    save is a folder that has to be created to save game

    • Steve
    • 12/11. 2011 3:37pm

    I cannot get the soundserver to compile. Trouble with linking. No errors or warnings, just:
    collect2: ld terminated with signal 11

    • narc
    • 12/12. 2011 9:39pm

    Ugh! Nearly 1½ year later and compiling the basic code under Ubuntu 64-bits is a hassle, to which I now have no solution. (I used a 32-bits system back then). /me thinks the gcc compiler was updated to support stronger typing: I have a bunch of illegal casting of char * to int * that probably an old, more forgetful compiler would accept.

    Fortunately, I could compile the sound server. Your problem is similar to what I read in a different forum and which I was able to reproduce (with a different signal though). I simply forgot to indicate a change in linux.c:56, to also eliminate the extern int errno in the same fashion as above and include <errno.h> somewhere at the top.

    Hope this works. And if you have some additional tips about my compilation problem, feel free to contribute.

    • Steve
    • 12/26. 2011 2:40pm

    Thanks. That’s fixed it.

    I’m also working on making the code 64 bit compatible. That’s a lot of work, but will be worth it. It’s mainly fixing the pointers for wad loading, that is, according to Fraggle.

    Wish me luck!

    • Steve
    • 12/31. 2011 7:51pm

    Some more fixes for you:

    dstrings.h lines 46 & 55 require commas at the end. This stops linuxdoom crapping out at the quit message. Also, add a space at the end of the string in line 50: …at the dos prompt! ” – This makes sure the whole string is displayed.
    doomdef.h line 34 should be 109 and not 110. This will make demos work.

    Linuxdoom compiles fine under Debian Squeeze BTW.

    • Greg
    • 01/23. 2012 10:09pm

    I got the original doom to work on Arch Linux with X server 1.11.3 and the vesa driver. I don’t know if this is specific to my system but the colors were displaying incorrectly. Apparently the color map wasn’t taking affect because it wasn’t installed. The color map can be installed immediately after creation (i_video.c:794):

    XInstallColormap(X_display, X_cmap);

    This seems to be a necessary step and I don’t know why it wasn’t done originally. Maybe it’s a requirement of more recent X servers.

    • ryan
    • 07/17. 2013 7:45am

    Perhaps you guys should check out chocolate-doom at chocolate-doom.org, its a doom engine made to feel as much like the original as possible, and the source has already been sanitized.

    • narc
    • 07/17. 2013 7:26pm

    Looks nice. Thanks ryan.

    • pstep
    • 12/05. 2013 5:53pm

    Is there another way of running programs that need 8 bit colour than changing your whole desktop to 8 bit? X11 refuses to start with 8 bit colour on my machine.

    • narc
    • 12/05. 2013 10:41pm

    Afraid not. 8 bit video uses a palette for the colour whereas 24 and 32 bit video uses RGB/A components.

    As for X in 8 bits, they make it so much difficult now. The recipe I copy-pasted in my article doesn’t work any more and I’ve tried a local VNC in 256 colours with questionable results.

    I guess after 3½ years, I’ll have to retire this thread soon as it’s getting pretty old.

    BUT … There is still hope! I just compiled chocolate-doom on my EEE PC 32 bits Ubuntu 12.04 LTS using SDL-1.2 (main and friends): Works great. I couldn’t do it on my main system because I’m pretty much SDL 2.0 for my OpenGL stuff, so I don’t know how it would compile on a 64 bits system. It’s not 100% the original code but it’s a close as you’ll get to your Dooming pleasure without the hassle (and with a bunch of corrected bugs to boot).

    Happy Dooming.

Comment are closed.

return top