Doom It Yourself

Portable Doom source code based on iD's LinuxDoom 1.10 sources

• Designed to run as many PWADs as possible.
• Includes fully compatible DeHackEd 3.0 parser.
• Level-compatible with Boom.
• Supports 8bpp, 16bpp and 32bpp colour depths and arbitrary resolutions.
• Optional lump-based WAD compression, reduces typical PWADs to 30-40% their raw size (see armDeu).
• Optional texture resampling using bilinear interpolation in true colour engines.
• No more packed structures and similar Mickey Mouse code.
• Known to compile (and work) on:
  • RISC OS 3.x to 5.x using GCC 2.7.2, GCC 2.9.5 or Norcroft C, linking against the Shared C Lib or UnixLib.
  • Various Unix flavours such as Solaris, Linux and HPUX (no sound on HPUX); run the install.sh script contained in the archive after decompression to convert the source code file structure to Unix.
• Separate frontend available for RISC OS.
• WAD tools armDeu, WadPtr and WARM available from this page, too.
• Check out some images taken from the current version.

Last update: 12 May 2003. See News.

Don't expect a fancy web-page, I have more important things to do, so here's just the bare bones.

Formerly, when you downloaded Doom It Yourself you got an archive with patches. Since the license of the Doom sourcecode was changed to GPL late last year, this is no longer necessary or desirable. There is now only an archive with the full source code, no patching process is necessary anymore (making things easier for all parties involved).

A side effect of the GPL license is that people may distribute, even sell binaries of the DIY source code, as long as they also make the source code available under the terms in the GPL. Since there's also a commercial Doom distribution and I want to preserve the "build-your-own" spirit of DIY I won't put binaries on this webpage, however.

Interesting Doom-related links:

• Doomworld: probably the Doom site on the net. Updated daily.
• Doom Underground: WAD reviews, news, some downloads.
• Levels for Doom, Heretic, Hexen, ... . If it ain't there it's probably no good ;-) (note: this is the latest link since ftp.cdrom.com shut down these directories).
• Yonathan Donner's homepage. He's one of the authors of the infamous Hell Revealed megawad which is probably the biggest bloodbath in computer game history.
• Sir Robin's Doom Castle: one of the best sites for WAD reviews, recently moved to Doomworld due to Doomnation disappearing permanently, by the look of it.
• The COMPET-N homepage: a huge number of absolutely incredible Doom demo lmps. Lots of interesting stuff if you want to be truly amazed.
• Tools-assisted speedruns: a similar theme as COMPET-N, but the demos here weren't recorded in one go but rather piece by piece and then assembled. That makes these demos the most incredible around and you don't have to feel too bad if you have to say "I could never do that!".

Some Features

• Should run on any RISC OS machine, since the first major update even on 4MB ones.

• Should run on practically all 32bit Unix systems (albeit some may not have sound).

• Level-compatible with Team TNT's Boom Engine.

• Allows using ColourCard modes on old style machines to get a fully programmable 256 colour palette or 16bpp display.

• Lots of rendering functions re-written in ARM assembler, speeding things up enormously. As of DIY4.1 most assembler code is macro-generated

• 8 channel stereo sound synthesis done in assembler. Great FX even on my aged A5000. As of DIY4.1, SFX can also be resampled. Optional 16bit sound since DIY4.3.

• Source is resolution-independent. With the first major update the resolution can even be determined dynamically.

• 16bpp and 32bpp engines from major update 2 on. Optional texture resampling since DIY3.3.

Requirements

• Working GCC 2.7.2 installation. Don't bother me about how to set it up, though. You can download it from here, for example. You can also use GCC 2.9.5, but the Shared C Lib that comes with it and socketlib are incompatible.

• A make-utility, for instance this one.

• You don't actually need those but they're strongly recommended:
  • the SharedCLibrary headers and stubs for GCC 2.7.2 by Nick Burrett. Download them from here.
  • if you want to use a network-enabled version with the Shared C Lib, socketlib (used to be on the Acorn FTP site, don't know where that moved to now)
  • if you want to use a network-enabled version with UnixLib, I precompiled the optional network code that comes with UnixLib3.7b which can be downloaded here.

• Last and most importantly: the DIY Source archive containing the full, self-contained source tree. Currently at version 4.3.

Quick installation guide for Unix users

• Unpack the ZIP archive with the sources. These sources are in RISC OS format, however, so you'll first have to install them in normal Unix format which is done by typing sh ./install.sh in the directory you unpacked the sources to.
• Compile an engine binary suitable for your platform and graphics card. The Makefile contains targets for Sun solaris (starting with sun), HPUX (starting with hp) and x86 Linux (starting with linux). You have to append the colour depth to this base name (either 8, 16 or 32) to get the actual target name. There are optional modifiers to append to the depth: t (transparency, automatically enabled for Boom) and/or r (texture resampling).
• By default, a normal Doom engine is compiled. If you want a Boom engine instead, you'll have to add BOOMFLAGS=-DDIYBOOM to the command line of your make call (note that you should delete the objects_* directories before switching between building Doom and Boom engines).
• Set the environment variable DOOMWADDIR to a directory where a suitable main WAD can be found (i.e. doom.wad for classic Doom, doom1.wad for the shareware version, doomu.wad for Ultimate Doom, doom2.wad for Doom 2, plutonia.wad or tnt.wad for Final Doom; see also the -iwad switch).
• For more information about fine-tuning the DIY engine, read the release notes in the DIYDocs subdirectory. Much of it is RISC OS related, but there's also a lot of general interest (compression, resampling, etc.)
• Play Doom ;-).

More information

Make sure you read all the UpdateM* files and the ReadMe file in the DIYDocs directory. These give you valuable information about changes not only of DIY features but also of compile options.

News

12-May-2003

armDeu bugfix update.

6-Apr-2003

DIY 4.4.2 released

This is a small update release which mainly fixes a few bugs.

• RISC OS: screenshot bugs (without frame buffers, 8bpp modes); bug when running with large screenmodes.
• Unix: musserver & fullscreen patches by Darren Salt; optional screenshot code using libpng.

16-Mar-2003

DIY 4.4 released

Long time no update; well, the engine was pretty darn stable and I didn't feel like adding features for a while. I started working on the code again to make it 32bit compatible for Iyonix users and added some cool new stuff while I was at it. For a full list of features read the file UpdateM44 in the DIYDocs directory; the most important changes are:

• All: added optional bilinear resampling for things and masked segments as well. Both have data structures that make it pretty hard to interpolate horizontally, that's why I didn't tackle this issue for a long time, but now it's done and the result looks just great.
• RISC OS: 32bit compatible. Note that it still runs on pre-RiscPC machines, i.e it doesn't require an ARM6 or newer.
• Linux: ironed out some ugly leftovers such as synchronous sound and a superfluous sleep() that screwed up timedemo benchmarks. Also added optional fullscreen support using the XFree86 vidmode extension.

06-Dec-2001

Small bugfix: when saving a game from automap mode, the game may crash when loading this game back in (at least in Boom). The fix for this problem is adding the following lines to the very end of function P_UnArchiveMapNew() in p_saven.c:

  if (automapactive)
    AM_Start();

28-Aug-2001

DIY 4.3 release

Finally a new version of DIY ;-). As usual, a full list of updates can be found in DIYDocs/UpdateM43. So here's just some of the main points:

• RISC OS: fixed assembler plotters, no more freezes with the SCL.
• RISC OS: moved all vectored code into application-independent support module for more safety on fatal crashes.
• RISC OS: full support for optional 16bit sound.
• RISC OS: moved to GCC 2.95.2; if you're using an older version of GCC, you'll have to change the Makefile somewhat (best have a look at the old one before overwriting it). Note that because the SCL stubs that comes with GCC 2.95.2 clash with the SocketLib, you'll have to use UnixLib for network support.
• Use big blockmap, so really big Boom maps (e.g. Demonized) work now.
• Fixed savegame bugs (new format), which caused crashes e.g. when picking up the red/yellow key in map06 after saving.
• Automap overlay mode and simple automap anti-aliasing in true colour modes.

This version is now superceded by DIY 4.4.

16-Aug-2001

• WARM ported to RISC OS. WARM is short for WAD Auxiliary Resource Manipulator, a collection of WAD utilities available in the xwadtools archive. My main incentive when porting it was to provide a reject builder for RISC OS. For more read the WARM section.
• I added a section with demo lumps. I intend to record some more demos when I find the time, it's kinda fun.

8-Dec-2000

Caveat re. the 10 sector WAD and wadPtr: don't use wadPtr on this WAD (nor its successor)! Some of the levels will simply not work anymore, be it because doors can't be opened (level 16) or doors / walls aren't removed when they should (level 5). The reason is probably because both the 10sector WAD(s) and wadPtr use similar tricks which conflict with each other.

26-Oct-2000

Little bugfix for RISC OS users (or whoever uses the ARM assembler plotters): when compiling without DIYNOSHORT defined and using a vertical resolution higher than 255 pixels the redraw of things gets screwed up; this is a bug that got introduced in DIY4.1. Note: this bugfix is obsolete, just get the latest version.

06-Oct-2000

DIY 4.2 released

As usual, a full list of news is in DIYDocs/UpdateM42. There aren't too many changes all in all, at least compared with 4.1, but there are some pretty nice ones:

• Portable savegames. Portable between Doom variants (normal, Boom, FULL_NEW_FEATURES; there are some restrictions, of course, as you can't expect Boom extensions to survive a save with a normal Doom engine, but that goes without saying) as well as portable across platforms (RISC OS, x86 Linux, Solaris, ...). Old games can still be loaded and saved (if you adapt doomrc accordingly) but by default the new, portable format will be written. Besides being portable they're also a little more compact.
• On RiscPCs, use a Dynamic Area for storing the Z_Zone. Especially helpful if you're using a UnixLib binary which for some strange reason never managed to claim more then 11MB with the normal heap manager (and making UnixLib itself use DAs via program-name is extremely hacky and prone to fail).
• Fixed bug that caused some Boom extensions to fail (ironically enough it was the old transparency implementation of all things).
• The usual bug fixes, mostly to do with badly structured PWADs.

This version has now been superceded by DIY 4.3 and is no longer available from this page. Get the latest version instead.

28-Aug-2000 Source release of armDeu (which despite its name is quite portable).

27-Apr-2000

DIY 4.1 released

• License changed to GPL.
• ARM assembler plotter totally rewritten, now created out of macros automatically. This makes maintenance of the whole thing much easier, although it complicates things quite a bit for people who want to change small parts only. This was a huge workpackage but will ensure easy maintenance of the assembler files in future and adds the valuable possibility of conditional assembly. "Side-effects":
  • The plotter API changed (no more global variables referenced); affects C-source as well.
  • The plotters are truly Boom-aware now (textures of arbitrary height); affects C-source as well.
  • Now a 16bpp resampling engine available too; has always been possible with C-source.
  • Optionally forbid loop unrolling for potentially better cache performance on SA RPCs.
• New naming conventions to allow using Doom and Boom engines side-by-side. Get the updated frontend which can make use of it.
• Optionally resample SFX and/or play them at higher frequencies.
• More efficient sprite plotting.
• Several small bugfixes. Also my final word on the freezes in the resampling engine in DIYDocs/FreezeRes.

This archive is now superceded by DIY 4.2.

As with most of the DIY releases I'll be away on vacation from tomorrow (28 Apr 2000). You can reach me again from the 22 May 2000. Until then: have fun with the new version.

27-Mar-2000

Updated the frontend to version 1.14.

11-Oct-99

Updated DIY4 since I was in munich today anyway. The new archive (DIY4b) fixes the nightmare/fast mode bug, the Boom-crashes that happened sometimes after loading a new level, recognizes shared lumps and so on. (Version is now obsolete, get DIY4.1 instead).

1-Oct-99

(Updated 5:10pm: problems with nightmare- and fast mode demos fixed!)

• Updated WadPtr. It got a little more efficient as far as WAD rebuilding goes; besides it doesn't crash anymore if there are level lumps without levels or multiply defined levels.
• Updated armDeu. The new version cooperates better with WadPtr in that it doesn't expand shared lumps again that WadPtr put so much effort in finding.
• Here's the big one: DIY Major Update 4! News in this version:
  • Level-compatible with Boom! Yes, you read that right, you can now play Boom levels on RISC OS. Many thanks to Team TNT for releasing the source and to Darren Salt for helping to merge the relevant parts with DIY. You can decide whether you want a Boom-compatible engine at compile time. All Boom levels should play OK, although not all special effects may be implemented. Deep water, pushers/pullers, variable friction and different colourmaps are all there, Ghostbusters looks superb. Translucency is fixed and only present in true colour engines. Demo compatibility with Boom demos is NOT implemented. Demo compatibility with old demos looks perfect and I managed to hunt down the bug that caused infinite cycles and failed demos in nightmare and fast mode. One of the nightmare demos I tried this with is now working perfectly and there are no other demos known to fail. This is how I wanted this to be, finally! I'll still be on vacation until the 17th of October; have fun in the meantime.
  • Demo playback via wildcards, e.g. if you packed all Hell Revealed demos into a PWAD you can play them all back in one go using -playdemo hr##-uv.
  • Slightly more efficient assembler plotters, but it's unlikely you'll notice anything on a SA RPC.
  • Removed the remaining limits on some internal structures. Optional dynamic limits can be set via doomrc.
  • Fixed the dehacked bug mentioned on 9-Sep-99.
  • Totally overhauled the source, pushing all external declarations into the header files, using static declarations and const pointers wherever possible.
  • Optionally use integers rather than shorts; shorts still recommended on SA RPCs due to bandwidth limits.
  There are some more things, please read UpdateM4 for more information. This update supercedes all previous major and minor updates (now deprecated itself, see DIY4.1).

  As mentioned above I'll be on vacation 'til 17-Oct, so I can't answer any questions you might have until then. In some cases Darren Salt may be able to help you, however.

20-Sep-99

Updated WadPtr. This version fixes a bug that was still in the first release, is much nicer in its memory requirements, got about 10 times faster in sidedef packing and rebuilding WADs with lots of lumps got faster by about infinity.

15-Sep-99

Ported Simon Howard's WadPtr 2.2 to RISC OS and Unix. This is a tool that compresses WADs by transforming some of the lumps like sidedefs and patches. The resulting WAD is still usable by any Doom engine, unlike with the WAD compression offered by something like armDeu.

09-Sep-99

Found a bug in DIY's dehacked.c file that has been in there forever and just hasn't manifested itself before. The first time I noticed something going wrong was when I tried out Doom2 X-treme GOLD where this meant that the shotgun-replacement didn't shoot and some enemies in the first level were basically invincible. This bug has been fixed in DIYM4. news 1-Oct-99).

07-Jul-99

1. DIY M3.4 now official. In addition to the features mentioned in the preview version there's now also transparency in 16/32bpp modes thanks to Darren Salt who did the ground work. I added the plotters for 16bpp and 32bpp resampling. Transparency can be toggled at run-time using a cheat (dstrans). Also the monster infighting cheat, formerly only available via a DeHackEd script, can now be activated with a cheat (adfight).

   DIYM3.4 is now superceded by DIYM4.

   For the first time there's also the full source available for download. With the myriads of source ports for PCs out there it just seems ridiculous to continue releasing patches only.

2. Updated armdeu. Now you can list the levels in the specified WADs using armdeu -p.

17-Jun-99

Updated armdeu for all platforms. There was a minor bug in the pattern matching code. So minor in fact, that I didn't change the version number.

And another thing: if you're running DIY on Linux you have to add -fwritable-strings to the compiler flags, at least if you want to use DeHackEd. Otherwise you might get segmentation violations.

17-May-99:

Version 1.14 of armdeu available for RISC OS, Solaris and HPUX.

26-Apr-99:

1. Version 1.13 of the frontend available. This may be needed for the 3.4 version of DIY because it allows to junk the DigitalRenderer commands in the startup script.

2. Version 1.13 of armdeu available; this version now does proper IWAD merging.

3. DIY M3.4 preview available. This doesn't yet include everything I'd like in there but since I'll be away 'til mid-may I'll release a preview now which already has some very nice improvements:
   • Improved clipping of the plotters for more stability.
   • No more visplane / drawsegs overflows (both dynamic now).
   • Sound now handled via voice generators by default, so you don't need the DigitalRenderer module anymore. Get the latest version of the frontend to make sure no DigitalRenderer-lines are created in the startup script anymore.
   • Fixpoint-code now produces the same output as the LinuxDoom-version. That means that most demos will work flawlessly now (the original demos in (Ultimate) Doom and Doom ][ work, some 3rd party demos still go wrong after a couple of minutes but that's a known problem and happens with all other players based in the linuxdoom1.10 sources too). Now go to the Hell Revealed homepage, download the main WAD and the latest set of demos (hruvlmp2.zip) and prepare to be completely and utterly awestruck. Few Doomsters would be able to imagine this kind of carnage, let alone be good enough players to survive it.
   The preview is now obsolete. Get the official version.

16-Nov-98:

1. Version 1.12 of frontend available. This fixes a small remaining bug that could lead to address exceptions if recursive game definitions were introduced as "game" rather than "game =". Click here to download the latest version.

2. DIYM3.3 now available. The most noteworthy news is optional texture resampling in 32bpp modes. That means textures do no longer look blocky when magnified but are smoothly graded. Don't even think about using this unless you have a StrongARM, though, because it eats up very much processor time. If you want to see how it looks here is a scene from Doom 2, rendered on a Linux machine (266MHz P2, actually playable at this resolution with texture resampling!) with and without texture resampling. Both images are in the 60-70kB area.

   Other changes are a new Makefile which removes the need for multiple source trees for different colour depths, idclev no longer aborting with bad Doom 2 level numbers and a small fix that cures the wrong backgrounds on a wipe that could happen in higher colour depths with only two frame buffers. For more info see the UpdateM33 file contained in the archive.

   This version is now superceded by DIY M3.4.

29-Jul-98:

Everything updated:

1. Version 1.11 of armDeu available. This will correctly output even badly built PWADs and allow extracting only lumps that match a certain pattern.

2. Version 1.11 of the frontend available. Fixes some minor bugs and has a new menu entry to automatically load FrontData into an editor. Click here to download it.

3. DIYM3.2 is here!

   DIYM3.2 features:

   • Fixed some more bugs in old 8bpp modes (fuzz / snapshots). Also it emulates palette effects even on a static palette now.

   • Modified the engine to make WAD merging superfluous. Now you can play all PWADs directly, even big stuff like AliensTC or AODTC. armDeu still recommended for WAD compression, though.

   • WAD filetype supported (&16c). Now your WADs don't have to be called something/wad anymore but can have any name as long as the filetype is correct.

   • Little hack to allow sound synthesis at higher frequencies. Amazingly enough this can make quite a difference but is recommended on fast computers only.

   • Loads of bugfixes (well... most of them make sure bad PWADs can't hurt the player). This fixes errors in StarDoom, Invasion2 and so on.

   • DIYM3.2 compiles on UNIX! Tested on Sun Ultra, HPUX and Linux. All colour depths supported, sound currently only on Sun and Linux. Patches and a Unix Makefile provided.

   This version is now superceded by DIYM3.3 (see News of 16 Nov 98). You can download the latest version from there.

12-Jun-98:

Various updates:

1. Version 1.10 of armDeu available. This can also output PWADs and compress WADs for the DIYM3.1 engine (and decompress them).

2. Minor update 1 for DIYM3 is available (in future called DIYM3.1). This enables the player to use WADs compressed with armDeu 1.10 completely transparently. It also fixes the map colours in old 8bpp modes. This minor update is now superceded by major update 3.2 (see above) and is no longer available.

   Note: due to decompression and the buffer this requires the player needs a little extra memory, starting it up in 1024k does no longer work. Increase the default wimpslot, it'll grow beyond 2MB as soon as Z_Zone kicks in anyway.

3. New version of the frontend available. This offers a new menu for misc options as well as recursive game lists (i.e. submenus). Click here to download it. Unfortunately I had to change the format of the configuration file quite a bit, but the new one should be future-proof.

8-Jun-98:

A small frontend for DIY is now available. Click here to download it. Read the !Help-File for more information.

29-May-98:

The third major update (DIYM3) is here.

3rd major update features:

• More efficient lump lookup, makes menus much faster.

• Number of colourmaps easily changeable in 16/32bpp modes.

• DeHackEd's infighting mode now works as well.

• 3 groovy new cheats that can take the game to new heights ;-).

• Loads of bugfixes, including the redraw bug in 16bpp, the quit-messages, the Ultimate Doom episode skies, screwed up floor/ceiling textures in some PWADs and so on.

• Loads of other small things.

This update is now replaced by DIYM3.2 (see above). For more information make sure you read the file UpdateM3 in the DoomItYs directory.

04-May-98:

Docs on how to use more colourmaps in DIYM2 32bpp modes. Since DIYM2 is now superceded by DIYM3 which already contains all the hooks for more colourmaps this page is no longer available.

28-Apr-98:

New version of armDeu available.

24-Apr-98:

The second major update (DIYM2) is here.

2nd major update features:

• Additional 16bpp and 32bpp engines for improved light effects and better fuzz.

• Removed some bugs that could cause crashes or aborts with 3rd party WADs, particularily Eternal III.

• Melting effect now uses framebuffers instead of statically allocated memory. Saves the memory for 1 to 2 screens.

• Size of saved games is no longer limited. Good news especially for StarDoom users.

• Make sprite-snapshots of any screen in the game.

• Various bugfixes, including idclev in Doom 2 and crashes at the bunny scroll in Doom 1 in higher resolutions.

For more information read the file UpdateM2 in the DoomItYs directory. This update is now replaced with the third major update.

20-Apr-98:

New version of armDeu available.

07-Apr-98:

The first major update (DIYM1) is here. This overrules all other updates and notes previously released. To apply these patches you need an unmodified copy of the sources you got after a successful Doom It Yourself installation.

The update features:

• Net support. For this you need Acorn's socketlib (alternatively here's a german mirror).

• Dynamic resolutions, i.e. you don't need to compile different binaries for different resolutions anymore.

• Inbuilt DeHackEd support. Just add -dehack patchfile when executing the Doom binary to apply a patchfile.

• Better handling of SFX makes it possible to run Doom on 4MB systems! Also rearranging some data made synthesis quite a bit more efficient.

• 16bit sound, but you have to play around with that stuff yourself because I couldn't test it or anything. The 16bit sound sources are included courtesy of Thomas Olsson.

• Lots of other small stuff and bug fixes. Check out the archive for more info.

Demo Lumps

• SUIC1656: a 100/100 UV demo of Suicide by Wes Burd Jr. in 16:56. A fun old-style map for (Ultimate) Doom; somewhat odd weapon and backpack placement which slows you down, though. Forgot to hit a switch at one point, unfortunately, so I had to backtrack which cost some time. I still think the time isn't bad for my standards.
• SUIC1356: a 100/100 UV demo of the Suicide PWAD (see above), but 3 minutes faster. I think this is about as fast as I can finish the level, but I'm certainly interested to see what's possible for a Doom God here...

armDeu 1.18b (GPL)

Many of you will probably have come across archives containing additional WADs and a DOS program called DeuSF. The patch files wouldn't work when added using Doom's -file switch. The reason is that you have to merge the patch WADs with your main WAD ((Ultimate) Doom, Doom II) which is what DeuSF does.

I downloaded the Deu source, had a look at it, extracted the bare essentials to perform the WAD merging and compiled the whole thing, which resulted in armDeu which you can download here (source plus arm-riscos binary).

I successfully built the WADs for AliensTC and Simpsons using armDeu, for instance.

Version 1.00 can also handle Doom 2 WADs now. I hadn't noticed this initially so I ended up with only one new level when I built Eternal III. This new version remedies that. But a warning to all Eternal III users out there (and probably some other 3rd party WADs): be very careful about using these WADs with older versions of DIY (before major update 2) because any but the first level of Eternal III will crash your machine big time. It's fixed in major update number 2.

Version 1.01 offers a new command-line switch -e which will eliminate multiple lumps with the same name, leaving only the last one. Using this switch is highly recommended whenever you're using the Ultimate Doom WAD as main WAD, because that one contains 124 duplicate lumps (which is a known problem, they're not supposed to be there) which not only take up 800kB too much space but also screw up a lot of your patched sound samples (e.g. AliensTC). If you want to check whether a main WAD contains multiple lumps just type armDeu -e main-wad and it'll tell you whether it found any.

Version 1.10 can also write out PWADs (older versions could only create IWADs) and compress WADs for use with the DIYM3.1 player (see News 12-Jun-98). For more information read the !Help file.

Version 1.11 will correctly build badly designed PWADs and allow extracting only those lumps that match a given pattern.

Version 1.12 can output raw binary lump data instead of complete WADs and fixes a bug in the pattern matching code.

Version 1.13 now does proper WAD merging, something I put on hold ever since the DIY engine could do it itself. There are problems when creating IWADs that require sprite/patch/flat merging, however, so this is now fixed. All sprites, flats and patches are each merged into big, continuous lump ranges that any Doom engine can understand.

Version 1.14 can now create WADs from raw binary files. You can use this to merge single lump files into a big WAD that's easier to handle. I used this system to merge all the Hell Revealed demo lumps into a compressed PWAD.

Version 1.15 can list all the levels in the specified WADs and fixes a little bug in the pattern matching code.

Version 1.16 recognizes shared lumps as created by WadPtr and doesn't expand them any more by default, thus saving space.

Version 1.17 has basically no new features but is a cleanup for a full source code release under GPL license. Maybe the WAD compression code will be interesting to some people: lump-based LZ77 with very fast decompression. Level data usually compresses to 30-40% its original size, graphics to 40-60%. Intended for seamless integration in Doom engines (implemented in DIY). Examples: doom2.wad compresses from 14258kB to 8056kB, eternal.wad from 21998kB to 10299kB. On a 400MHz Ultra Sparc II CPU I get about 12MB/s decompression rate for doom2.wad and 14MB/s for eternal.wad, in other words you won't experience a speed penalty due to compression unless you have very old hardware, but you'll save heaps of space.

Version 1.18 no longer contains the compression code but uses my fastlz library to avoid duplicating code between armDeu and DIY. You therefore need the fastlz library in order to compile armDeu for your system; fastlz is distributed as part of the DIY source archive or as a standalone archive.

Version 1.18b fixes a bug introduced in 1.18 which affected building compressed WADs from already compressed sources. Note you'll need version 0.01 or newer of the FastLZ library if you want to compile this release yourself.

Additionally there are Unix ports of armDeu available:

• armDeu 1.17 for Sun Solaris.
• armDeu 1.17 for HPUX.
• armDeu 1.17 for x86 Linux.

WadPtr 2.3

This is a port of a tool by Simon Howard "Fraggle". It allows you to compress WADs by packing sidedefs, linedefs and patches. The cool bit is that the resulting WADs are still usable by any Doom engine as the transformations produce perfectly legal WAD structures. This also makes it feasible to combine the compression offered by WadPtr with the compression of armDeu, for example (which compresses a typical PWAD to 30%-40% its original size). Typically level data is reduced by about 20%, patches usually compress considerably worse. In contrast to the compression of armDeu this saving in space doesn't only have a beneficial effect on your harddisc space but also on Doom's runtime memory consumption (i.e. a level compressed by 20% also takes up 20% less memory when you play it). For more information read the text-file contained in the archive or check out Simon's homepage.

There are binary versions for RISC OS, Sun Solaris and x86 Linux available here. I've used this version on hundreds of WADs now without any problems whatsoever, so I'm sure I can call this a stable and reliable tool now.

Warning: don't use WadPtr on WADs compressed with armDeu! You'll have to uncompress them first.

WadPtr 2.3 for RISC OS

WadPtr 2.3 for Sun Solaris (2.6)

WadPtr 2.3 for Linux

WARM 1.6

The WARM source code is available in the xwadtools archive; from the documentation: "WARM's main purpose is to build the NODES, SSECTORS, SEGS, BLOCKMAP, and REJECT resources from the basic resources that compose a level". My main incentive to do the port was to provide a reject map builder for RISC OS. The reject map of a level contains line-of-sight information for all sector pairs within the map and can help the Doom engine enormously in quickly discarding non-visible sectors when rendering the screen, thereby speeding things up dramatically. For instance some of George Fiffy's Boom maps play like molasses because he didn't build a reject map for them. You can check whether a map has a valid reject map (and several other map stats) by writing warm -emstat wadfile and checking the output of the Reject field; if it says "zeroed" there's a good chance the level can be made a lot more playable if you create a reject map for it by typing warm -r wadfile outputfile. Some notes:

• Important note for RISC OS users: because opening a file with writable access blocks all other attempts to open it, you must always specify an output file if you change any part of the WAD, otherwise your changes can't be written. So you can't do warm -r wadfile to build a reject map and write the changes back to the same file, for instance.
• Note to all users: building a reject map can take very long, especially on big levels where the reject map can achieve the most substantial speedup of the engine. Some levels like Vrack2 can actually take many hours for the reject map on a StrongARM RiscPC, so you might consider running these reject jobs as a batch job overnight.
• Another warning re. demos: sometimes building a reject map for a WAD can lead to very rare problems when playing back demos for that map. For instance the demo for the Punisher WAD I have gets out of sync if I apply a reject map to the WAD. I don't know whether that's due to a bug in WARM or the original WAD (but I tend to blame it on the WAD). Keep this in mind and have a backup copy of your favourite demo WAD (e.g. Hell Revealed) handy in case demos start to go wrong.
• And a final caveat: I didn't test all parts of WARM, just map statistics, reject and node builders. Basically everything else should work fine too, but I can't guarantee it. In case you have problems with any part of WARM, please let me know.

You can download WARM from here. This archive contains source code and RISC OS binary. The source code also compiles fine on Solaris, HPUX and Linux and I sent my changes to the maintainer of the xwadtools archive so my work won't be lost on future versions of the official distribution.

DIY frontend

This is a small frontend for DIY that was designed with hundreds of add-on WADs in mind. It doesn't have any flash icons or animations, all it provides is a menu from the icon bar which you can use to configure the startup script used for launching DIY. It is now 32bit compatible (as of version 1.15)

The configuration is done via a textfile called FrontData located in the application folder. You can specify an arbitrary number of screen modes, games (can be new WADs) and miscellaneous options. Games can be ordered hierarchically, for instance the Master Levels could be a submenu and so on.

For people who use PWADs rarely or are scared of editing the configuration-file by hand this frontend is probably not the way to go; if you've got hundreds of PWADs to take care of you'll soon appreciate what it does for you, though.

Click here to download version 1.15 of the frontend.

Hints & Tips

• The old problem of the freezes in the resampling engine: these only occur when you link against the Shared C Lib. Build a version linked against UnixLib and it'll work just fine. Something with the SCL keyboard handler must be broken.

• Symbol __uname_control not found when linking (all versions): you compiled with the UnixLib headers and tried to link against the SharedCLibrary, which doesn't (and mustn't) work. Read the documentation again: you have to adapt Unix$Path so it points to your SharedCLib headers or add -mstubs -IC: to CFLAGS in the makefile. Before compiling again after this change you have to delete all your object files! Mixing object files compiled with different library headers is suicide.

• In case you're having trouble using Doom over a network you should try fiddling around with the port parameters. The following parameters are known to have worked on one setup (2 players), for instance: you start one player with

  run Doom:!RunImage -port 26000 -net 1 1.104.29.213

  and the other with

  run Doom:!RunImage -port 26000 -net 2 1.104.162.219

• ENOENT not defined when compiling c.dehacked: this seems to be a problem with some versions of the SharedCLibrary headers. This symbol is not important and you may replace it with 5 if that error turns up. It should be gone in DIYM2.

• Address exceptions at &0000807C: the startup wimpslot is too small. You have to increase it.

• Making DIY work with Linux Doom players in netgames (by Reuben Thomas)
  1. Turn off checksums: load c.d_net into an editor, search for NORMALUNIX (this will be found in NetbufferChecksum()). Replace the line where this occurs with "#if (defined(NORMALUNIX) || defined(__riscos__))".
  2. For players before M3.4 only: Use the original fixpoint-code: load c.m_fixed into an editor and replace the line "#if (!defined(__riscos__) || (FRACBITS != 16))" with "#if 1". Then load the Makefile and remove o.arm_fixed from OBJS.
  3. Change the player's version number to the one of the Linux player (typically 1.08): load h.doomdef into an editor and replace the line "enum { VERSION = 110 };" with "enum { VERSION = 108 };". You can't use a DIYM3 player with FULL_NEW_FEATURES defined with anything but another DIYM3 player.

Andreas Dehmel, 16-Mar-2003.