Last modified: Sun Aug 17 13:48:34 EDT 2008
The purpose of this survey is to determine what I must do to continue being able to play Classic DOOM.
The options for getting some semblance of Classic DOOM running fall into a few broad categories.
Most source ports either are incompatible with Vanilla DOOM or have intolerable defects. The reasonable options are summarized below.
| Program | OS | Strengths | Limitations |
|---|---|---|---|
| DOOM 2 Version 1.9 | DOS, Windows 98 SE | The original. | Requires obsolete OS. |
| Chocolate DOOM | Linux | Faithful to the original. | Music using TiMidity is not identical to the original. Software is still in development. |
| PrBoom | Linux | Supports OpenGL as well as highly compatible software rendering. | Music using TiMidity is not identical to the original. Software is still in development. |
| DOOM 95 | Windows 98 SE | Officially sanctioned port. | Requires obsolete OS. Invisibility is rendered incorrectly. Sound glitches depending on hardware and drivers. Has several problems that can be worked around. |
Although both Chocolate DOOM and PrBoom support Windows XP SP2, they both run better under Linux.
Following are four simple compatibility tests that can all be conducted in the vicinity of the starting point of E1M1.

Examine the rectangular texture on the far wall dead ahead. In Vanilla DOOM, the rectangle is slightly taller than it is wide. In source ports with broken aspect ratio correction, the same texture appears to be slightly wider than it is tall.
Right: 
Wrong: 
Also from the starting position of E1M1, examine the barrel to your right. Note that it has three horizontal ridges. In Vanilla DOOM, the bottom ridge is as far from the floor as the top ridge is from the top of the barrel. In some source ports, this barrel sinks into the floor so that the bottom ridge is basically on the floor.
Right:
Wrong: 
Ironically, this problem results from correct rendering of incorrect WAD data. When an object has a Z coordinate (altitude) that is set too low, such that it should penetrate the floor, the Vanilla DOOM renderer draws the entire object anyway. When the same data are used by a rendering engine that does the "right" thing, the affected object actually does sink into the floor. Some ports rectify the problem by increasing the Z of affected objects, but the result doesn't look the same as Vanilla DOOM.

This is the stairway that is to the left at the beginning of E1M1. On Ultraviolence, there are goons hiding behind each of the columns (you can see the tops of their heads in this screenshot). If you run up the stairs and hide in the back, do they follow you up the stairs? In Vanilla DOOM, they can't. In some source ports, they do. Sometimes there is a compatibility switch affecting exactly this behavior.

This is the view through the window that is to the right at the beginning of E1M1. In the distance, in the part of the building on the other side of the courtyard, two goons are walking back and forth. Can you take them out? In Vanilla DOOM, it's pretty easy. In some source ports, it's difficult or impossible.

(Screenshot scaled from 320×200 to
320×240 to preserve original appearance.)
Description: Vanilla DOOM.
Source: Retail package DOOM 2 on 3.5 inch floppies, patched up to Version 1.9.
There is no music, sound effects break up and gameplay is jerky. Compatibility mode doesn't fix anything, no matter whether it's set to Windows 95 or Windows 98 / ME.

If Ctrl-F12 is pressed until the emulation consumes all available CPU cycles on a 3.2 GHz Pentium 4, DOOM 2 becomes playable—but just barely. Gameplay is not nearly as smooth or subjectively pleasant as when running under FreeDOS on a 166 MHz Pentium.
On one computer, the mouse just worked; on another, it just didn't. I've been known to force the issue for serial mice by installing a DOS mouse driver in AUTOEXEC.BAT.
DOOM works under FreeDOS. It's your problem to make sure that the SoundBlaster is configured properly and that you have a working combination of mouse and mouse driver. Most people will have a newer BIOS with a "legacy" feature that allows USB mice to work under DOS. However, currently I'm DOOMing on an ancient Pentium PC where both USB and PS/2 ports are via an add-in card with no DOS drivers and no BIOS support. I couldn't get either USB or PS/2 mice to work, but the old serial trak ball works fine.

(Screenshot scaled from
640×400 to 640×480 to preserve original
appearance.)
Description: "Official" source port of Final DOOM v1.9 to Windows 95 with higher resolution graphics (up to 640×480) and improved music.
Source: Retail package DOOM Collector's Edition on CD-ROM.
The mouse / trak ball doesn't work. This is a documented issue and it has no fix.
DOOM 95 is playable under Windows 98 SE if you install working drivers and respect its limitations. However, it has enough issues (some internal, some inflicted by Windows) that I can't really recommend it over DOS DOOM.
DOOM Collector's Edition failed to include the mouse driver, DMOUSE.VXD. A description of the problem and the remedy for it is available at http://www.classicdoom.com/dmouse.htm. In summary, you have to put this file in the same directory as DOOM 95 and then make sure DOOM 95 is configured to use the mouse.
The option to run in a window does not work.
The configuration sometimes becomes corrupt, with one possible symptom being that the mouse still does not work. (Mouse sensitivity is one of the configurables.) This is fixable by deleting the configuration and rebuilding it.
If DOOM 95 is exited and relaunched, it hangs.
There is no correction for the aspect ratio when 320×240 or 640×480 modes are selected, resulting in vertically compressed graphics. The workaround is to stick to 320×200 or 640×400 mode.
Rendering bug: Invisibility is not rendered correctly.
This is not the fault of DOOM 95, it is just something that needs to be worked around if you are going to play it.
With an nVidia GeForce2 MX 200 graphics card, versions 71.89 and 81.98 of the nVidia ForceWare drivers are unable to render 320×200 or 640×400 modes correctly. The graphics appear letterboxed in what is actually a 320×240 or 640×480 screen. Version 66.94 of the ForceWare drivers does not have the problem.
When used with a PCI SoundBlaster Live! and the drivers that came with the card, I did not notice any sound glitches. However, when used with an ISA SoundBlaster 16 PnP and Microsoft's sound drivers, I had trouble with sound effects cutting out.

(Screenshot scaled from
640×400 to 640×480 to preserve original
appearance.)
Description: Faithful source port of DOOM 2 to Windows with higher resolution graphics (up to 1024×768).
Source: http://doomworld.com/doom4win/
Key bindings cannot be changed. Motion is jerky. Aspect ratio is not properly adjusted for 4:3 modes. 640×400 mode is OK.

Description: Faithful source port of DOOM 2 to Windows with higher resolution graphics (arbitrary size window).
Source: http://www.s2.org/ntdoom/
It crashes.
There is no way to make it go full screen. Even this kludge does not help:

Consequently, there is no way to access a genuine 320×200 or 640×400 mode and there is no workaround for the incorrect aspect ratio. Specifying a mode like 800×720 to try to stretch it vertically does not work.
As suggested in the readme, it is necessary to Alt-Tab away from the window and back again to persuade the mouse to function correctly.
NTDoom detects my Cygwin environment and silently hides a config file in ~/.doomrc, thereafter ignoring the config file in the working directory.

(Screenshot scaled
from 640×400 to 640×480 to preserve original
appearance.)
Description: Faithful source port of DOOM 2 to Windows, Linux, et al.
Source: see OS below
At http://www.chocolate-doom.org/wiki/index.php/About, Fraggle writes:
Almost all modern Doom source ports change the game in some way. In some cases, this is to fix bugs. In others, it is to add new features or even change the behavior of the game. Chocolate Doom is different, in that the focus is on creating a maintained version of Doom that looks, feels and behaves exactly like the original DOS version of Doom.
Consequently, Chocolate DOOM does not suffer from the engine incompatibilities that cause most source ports to flunk out before finishing E1M1. All of the normal DOOM things like F11 gamma correction and command line switches like –warp and –skill just work. The issues to be resolved are related to those things that were forced to change. The following is excerpted from the BUGS file included in the Chocolate DOOM source code distribution:
Sound may not set volumes correctly.
It is possible that volume of sound effects does not scale properly with distance from the sound source. It is also possible that sound effects are cut off at the wrong distance. This needs further investigation.
Music plays back differently.
The DOS music code was not in the Doom source release as Doom used a proprietary sound library. The mus ←→ mid conversion mostly works well but some patches are different.
Chocolate DOOM offers a command line switch to select which of the three variants of Vanilla DOOM Version 1.9 it should emulate, but normally it will do the right thing depending on the IWAD.
Chocolate DOOM comes with a setup utility that is nicely reminiscent of the Vanilla DOOM one but has been updated to do what is needful.
Consistent with its mission, Chocolate DOOM does not attempt to improve on the 320×200 graphics of Vanilla DOOM. It supports various larger screen resolutions, but all of them are up-scalings of the 320×200 source. Unless you have a monitor or video driver that refuses to handle 320×200 correctly, the only thing you get with the higher resolutions is more scan lines.
Version tested: 1.1.1
Released source: http://sourceforge.net/project/showfiles.php?group_id=144368&package_id=158721
Latest source: svn export https://chocolate-doom.svn.sourceforge.net/svnroot/chocolate-doom/trunk/chocolate-doom
To get music to work, you have to install TiMidity and put timidity.cfg somewhere that it will be found (like the current working directory). TiMidity music is not identical to what Vanilla DOOM produced using a SoundBlaster, but it is close enough and possibly the best that is doable.
The response to the trak ball is acceptable and remains smooth even as the mouse speed and acceleration parameters are increased to my preferred level of sensitivity. However, vertical and horizontal sensitivity cannot be configured separately.
If Chocolate DOOM cannot switch to the screen resolution that it was set up to use, it will change your settings to the largest resolution that fits on your screen and go with that. For best results, do the following.
xorg.conf.
The relevant section should look something like this:
Section "Screen"
Identifier "Screen 1"
Device "GeForce 6800 GT"
Monitor "EV910"
DefaultDepth 24
Subsection "Display"
Depth 24
Modes "1024x768" "320x200"
ViewPort 0 0
EndSubsection
EndSection
With older versions of Chocolate DOOM I had some gripes about the quality of sound effects when using AC'97 motherboard sound that only does 48 kHz. Fraggle was nice enough to incorporate and clean up a patch I sent to fix the problem; unfortunately, that patch, as it still appears in src/i_sdlsound.c as of 2008-08-16, has bugs. To get the best results with 48 kHz sound, do the following.
~/.chocolate-doom/chocolate-doom.cfg, set snd_samplerate to 48000 and set use_libsamplerate to 5.-mb 64 (or use
a higher number if you like). This makes the heap bigger so that there is
room for the expanded sound effects. The default heap size is only
16 MiB.I_PrecacheSounds_SRC: Precaching all sound effects........Then it should play normally with high-quality sound.
Version tested: chocolate-doom-r845-win32.zip
Source: http://84.40.169.249/al/files.php?sAddDir=/raztk/chocolate-doom (linked from http://www.chocolate-doom.org/)
Although it is usable, the Windows binary suffers significant Windows-inflicted lossage that does not occur under Linux.
I have to increase mouse speed to 15 and mouse acceleration to 3 before my trak ball is sufficiently responsive. After that, it's playable, but the motion is jerky.
Sound quality is poor. The problem mentioned in the BUGS file about not setting the volume of sound effects correctly is definitely happening here, but in addition the sound effects just sound lousy. (N.B., this test was conducted with a much earlier version that did not include the libsamplerate support.)

(OpenGL version.)
Description: Enhanced source port.
Source: http://edge.sourceforge.net/
Syntax used: gledge32.exe -res 1024 768 -bpp 2 -iwad doom.wad
Edge fails both the steep stairs and distance shooting tests, even when Compatibility is set to Boom. This is a shame because overall Edge runs very smoothly and reliably.
Graphics are a bit too dark or a bit too contrasty, though this could possibly be fixed in the nVidia driver.
Horizontal mouse sensitivity is too high even on the lowest setting. Seems to be worse in gledge32 than in edge32 (possibly timing-related).
The key repeat delay is close to zero, which makes it very difficult to navigate menus and select options correctly.
No music. Does not run as smoothly as the Windows version.

(Software renderer, without OpenGL.)
Description: Enhanced source port.
Source: http://prboom.sourceforge.net/
Problem: /usr/bin/ld: cannot find -lGLU
Solution: ./configure LDFLAGS="-L/usr/X11/lib"
To get music to work, you have to install TiMidity and put timidity.cfg somewhere that it will be found (like the current working directory). TiMidity music is not identical to what Vanilla DOOM produced using a SoundBlaster, but it is close enough and possibly the best that is doable.
The menu lets you choose 6 or 8-channel sound, but I only ever got stereo out.
User input and rendering are smooth. There are separate sensitivity controls for the vertical and horizontal axes of the mouse / trak ball, and you get plenty of headroom on both.
A raft of run-time options control compatibility nits like the
stair-climbing ability of goons, but the simplest thing is to use the
command-line switch -complevel, which takes a magic
number as documented in README.compat to specify what version of DOOM
to emulate. When it works and is
properly configured, PrBoom is very DOOMlike.
Last year, I was all ready to toss Vanilla DOOM in favor of PrBoom 2.3.1 until I discovered a broken trigger in The Focus. Version 2.4.1 had worse problems. No gripes so far with 2.4.5, but it only takes one broken trigger to ruin my day.
| Version | Gripe | When/how fixed |
|---|---|---|
| 2.4.1 | Somehow miss when attacking at point-blank range | Version 2.4.3: "fix bugs in gameplay occurring with gcc-4.1." |
| 2.3.1 | Broken trigger in The Focus | Irreproducible—went away when compiled with new GCC, new libs. |
When OpenGL is enabled, the graphics get much darker. If I max out the gamma in PrBoom and set it way higher in the nVidia driver, then it's playable However, many objects sink into the floor. There is an option called "Item out of floor offset" that can be used to fudge all of the coordinates higher; a value of 3 yields tolerable results.
Rendering nits appear with regularity when OpenGL is enabled, but the vast majority are attributable to the WAD file and are just obscured by software rendering. The rendering nit shown below, from E1M6, is present in the OpenGL renderer but not in the default "8bit" software renderer.

Here are some more screenshots with OpenGL enabled. All have
been postprocessed with qdgamma 1.75 to simulate the
effect of increasing the gamma in the nVidia driver. All have
gl_sprite_offset ("Item out of floor offset") set to 3.
(Screenshot) Default settings for PrBoom 2.4.7: gl_colorbuffer_bits=16, gl_tex_filter_string="GL_LINEAR" and gl_tex_format_string="GL_RGB5_A1"
(Screenshot) With gl_colorbuffer_bits=24, gl_tex_filter_string="GL_LINEAR_MIPMAP_LINEAR" and gl_tex_format_string="GL_RGBA8"
(Screenshot) That, plus 16xAA and 16xAF set in nVidia driver
(Screenshot) E2M2 at 1600×1200, with the same GL, AA and AF settings as the previous.
As of 2006-11 (and PrBoom 2.4.5) I played all the way through E1 and E2 in OpenGL without encountering a serious problem. Considering that most source ports flunk out before finishing E1M1, this is quite an achievement.
(Tested with PrBoom 2.3.1) Does not run as smoothly as the Linux version.

(Screenshot postprocessed with
qdgamma 2.0 to simulate effect of adjusting gamma in nVidia driver)
Description: Enhanced source port.
Source: http://www.3ddownloads.com/?file_id=7509
The key that is supposed to do gamma correction actually launches the menu. Consequently, I had to boost the gamma to stratospheric levels in the nVidia driver to make the game playable.
Although there is a control panel option to select the graphics mode, I can't seem to change it from 640×480, 16 bpp.
Response to the trak ball is jerky.
Spurious vertical black lines appear in the graphics.
The status bar background and gun graphic have had their aspect ratios corrected, but other things have not (note the texture on the far wall).

(Direct3D
with ambient light. Screenshot
postprocessed with qdgamma 1.75 to simulate effect of
adjusting gamma in Control Panel.)
Description: Enhanced source port.
Source: http://www.doomsdayhq.com/
I had a bunch of problems with the Doomsday launcher that went away after I reinstalled it. It may have been a victim of my dinking with the list of enabled XP services.
F11, the key that is supposed to do gamma correction, actually launches the menu. However, a newer gamma control that seems to operate at the video driver level is included in the Control Panel.
Also in the Control Panel is a setting for ambient light, which must be increased to make everything look decent. Unfortunately, that setting does not stick from one game to the next.
The response to my old trak ball is so jerky as to be unplayable until I enable the "Filter mouse movement" setting. After that, it's much better, but still slightly uneven.
With default gameplay compatibility settings, the goons in E1M1 climb the stairs and the spectres in Gauntlet are able to squeeze through the doorways to escape from the area that is supposed to confine them. After toggling several of the compatibility settings, one of which says "Use exactly DOOM's clipping code" and another of which says "Monsters can get stuck in doors," both problems go away—but I am not sure exactly which options do what. Dummies like me need one big option that says "Run like DOOM," or else that needs to be the default behavior.
Idclev does not work in the normal way. You must go to the console
and type cheat idclevxx.
It is more difficult to hit targets at a distance than in Vanilla DOOM.

Description: Enhanced source port.
Source: http://risen3d.newdoom.com/
Risen3D is a fork off the Doomsday tree, so it is not surprising that they have major similarities. Risen3D is better than Doomsday in the following ways:
In fact, if I increase the F11 gamma correction to its maximum and then use the Control Panel to increase ambient light to its maximum, Risen3D is the most visually appealing of all of the source ports. The only fly in the ointment is that the ambient light setting doesn't stick—not even from one level to the next! Perhaps there is some "save settings" button that I'm missing, or at least there should be some way to manually edit it into a config file somewhere.
It is still more difficult to hit targets at a distance than in Vanilla DOOM.

Description: Enhanced source port.
Source: http://legacy.newdoom.com/
The launcher hangs every time. Running the binary directly works.
The trigger to release the cacodemons at the end of Waste Tunnels is broken.
The volume of sound effects varies strangely.

Description: Enhanced source port.
Source: http://zdoomgl.mancubus.net/
ZDoomGL is a derivative of ZDoom with added support for OpenGL.
By raising the gamma in ZDoomGL to its maximum and turning off the Depth Fog special effect, I can make the graphics bright enough for the game to be playable. However, no matter what settings I adjust, the colors look washed out and dingy.
Upon changing the screen resolution, it is necessary to exit and restart to avoid buggy rendering of the status bar.
On one launch, ZDoomGL put my graphics card into a weird mode and my monitor shut down with an out of frequency range error.
ZDoomGL still contains software rendering support, but when I enable it, the borders of the screen on the left and right are rendered incorrectly.

Description: Enhanced source port.
Source: http://www.zdoom.org/
After gamma correction, the appearance of the graphics is still not as good as some other ports.
I can walk into the last part of Gauntlet while invisible and the three pinkies across the way don't notice that I'm there. They just stand there until I do something to wake them up. There are plenty of gameplay and compatibility options, but that's not one of them.
After a battle in the Gauntlet, a piece of somebody's chaingun was visible through the floor, probably as a consequence of having penetrated the wall of the stairway. However, this seems to be an original DOOM bug and not a ZDoom-introduced bug.

Description: Enhanced source port.
Source: http://www.doomworld.com/eternity/
Crashes repeatedly, apparently at random.
To go to the next configuration menu (marked with a right arrow), you must actually press Ctrl-Arrow.

Description: Enhanced source port.
Source: http://www.doomworld.com/doomgl/
Does not run.

(Screenshot scaled from
640×400 to 640×480 to preserve original
appearance.)
Description: Enhanced source port.
Source: http://www.vavoom-engine.com/index.php?Lang=Eng
Vavoom does the aspect ratio correction backwards: The world is vertically compressed in 640×400 mode just the same as in 1024×768. That and the leftover splash screen graphics hanging out in the corners make it unique.
I cannot get enough motion from the mouse even with maximum sensitivity. I think it was calibrated so that people using mouselook wouldn't get dizzy. With mouselook off, it needs acceleration.

(Screenshot scaled from
320×200 to 320×240 to preserve original
appearance.)
Description: Enhanced source port.
Source: http://www.doomworld.com/doom3d/
Resolutions other than 320×200 have incorrect aspect ratios.
The slider to adjust the music volume does not work, and the music plays off-key (too slow). Also, the face graphic flickers distractingly.
The 8-bit software renderer (sw8) works like Vanilla DOOM. When the Direct3D renderer is used, the graphics become too contrasty. Installing the optional MD2 3-D models introduces rendering bugs, like the shotgun goes through walls.

(With ambient light set to
maximum. Screenshot postprocessed with qdgamma 1.5
to simulate effect of adjusting gamma in Control Panel.)
Description: Enhanced source port.
Source: http://grafzahl.drdteam.org/
If you look carefully, at the bottom of the above screenshot you can see one line of the splash screen graphics left over. It is more obvious on a black background.
GZDoom has an ambient light setting and gamma adjustment that work and that stick from one run to the next. Alas, it also has a broken trigger. In Gauntlet, the square wall that is dead ahead in the screenshot below is supposed to lower when one of the two switches is thrown, but it does not.

As in ZDoom, I can walk into the last part of Gauntlet while invisible and the three pinkies across the way don't notice that I'm there. Also, the chaingun guy in Gauntlet who usually teleports as soon as I'm in range doesn't teleport immediately but instead starts shooting at me from the vicinity of the teleporter.
Some objects sink into the floor; others levitate.
Monsters seem to be more effective at reducing their own numbers through friendly fire than they are in Vanilla DOOM.

Description: Remake—a mod for DOOM 3 that recreates Knee-Deep in the Dead in a DOOM 3 kind of way.
Source: http://cdoom.d3files.com/
Before I pick nits with a generally brilliant remake, dig Brian Kline's (Sonic Clang) remake of the E1M1 music. (Your browser must be set up to play OGG files for that link to work.)
As I said, it is a brilliant remake. The levels are reproduced in loving detail, instantly recognizable and fun to play. The nits are that the overall gameplay and the terrible lighting are loyal to DOOM 3. Auto-aim is a luxury that you will not find here.
One of the nice things about Classic DOOM was you could move forward and back using a mouse or (preferably) a trak ball, and use the keyboard for strafing and firing. In DOOM 3, the option to allow forward and back motion with the mouse is broken and would be of dubious value in a true 3-D level anyway.
Extreme slowdown using version 71.82 of the nVidia drivers. No such problem with drivers version 87.62.
Cannot get the audio to work except with +set s_driver oss
+set s_numberOfSpeakers 2 (which gives up surround sound).
A non-default keyboard layout (e.g., Dvorak) causes doom3 to corrupt its key bindings from one run to the next. I work around by preserving uncorrupt copies of base/DoomConfig.cfg and cdoom/DoomConfig.cfg and overwriting the ones under ~/.doom3 before each run.
Having done all that, the Linux version runs more smoothly than the Windows one, but with inferior audio.
If you are viewing this page on an LCD screen you might not know what the fuss is about. DOOM existed long before there was an LCD monitor on every desktop. The graphics were always too dark. If you couldn't get gamma correction to work, everything was black. But LCD monitors have an interesting flaw—they can't do black! All dark colors are brighter than they would be on a CRT. So, ironically, the infamously dark DOOM graphics look fine and dandy without a lot of gamma correction.
I am still sitting in front of a big honkin' CRT, and it's not the brightest one ever made, so the screenshots might look a little overexposed on an LCD screen.
DOOM's software renderer makes more distant objects appear darker, as if all light were emitted from the player. This effect is usually eliminated in OpenGL ports. While this makes everything look better, it unfortunately makes it impossible to see some "lighted corners" that are used to hint at the existence of a secret, such as the example from E2M2 shown below. The extra lighting is only visible when the surrounding area is affected by distance-darkening.


The behavioral differences are summarized from http://doom.wikia.com/wiki/Doom_1.9, 20080225.
Original DOOM 1.9 executable was used for DOOM shareware, registered DOOM and DOOM II. It was named doom.exe in shareware and registered, doom2.exe in DOOM II.
DOOM2/DOOM2.EXE: MD5 = E2 38 2B 7D C4 7A E2 43 3D 26 B6 E6 BC 31 29 99
DOOM2/DOOM2.EXE: SHA1 = AA06 68FA E2F7 43EE 5E3E 5634 EE42 D3C8 ACE7 D907
DOOM2/DOOM2.EXE: RMD160 = 1887 5E56 90F7 1D35 E77D 2288 7EFF 5F37 3A6D 1EBD
DOOM2/DOOM2.EXE: SHA224 = 11913326 975EBDFE 8A6629AD 34C72128 12696709 76770F63
0D5BAD17
DOOM2/DOOM2.EXE: SHA256 = B8020523 561A5AD9 706E009A 52D61C57 8F37FAAF D85AC471
96230840 6292CE27
DOOM2/DOOM2.EXE: SHA384 = 54880089 7A7406C9 B948F14B EE83FB0E FF855C73 843F0FDC
CC4AAA9D 67C28625 E9FE4559 470B0F88 3A062985 F75DA321
DOOM2/DOOM2.EXE: SHA512 = 3104D991 E2893D98 2220030A B714FC3F C079F7B4 BB88C0E8
E47403D7 5A68B2AE FD381893 FDE0B493 2373D71E 530B1ED8
C32FB561 9F135644 CDC65A1B EC5BBDA2
Ultimate DOOM executable interprets Tag 666 (triggered by killing some big baddie) differently and fixes a bug in the behavior of lost souls when they collide with the ground.
Ultimate/DOOM.EXE: MD5 = 74 2A 5F 99 53 87 16 87 34 1E 37 94 46 88 94 D8
Ultimate/DOOM.EXE: SHA1 = 64E6 DF0E E478 868B 42D5 EB7D 4434 3028 3B0D DC0C
Ultimate/DOOM.EXE: RMD160 = 6783 0ECF DE4D 6EE3 1A28 4EDF 17BA FE8B AFF1 8327
Ultimate/DOOM.EXE: SHA224 = 8E5DB966 6FCD14B9 CDC61F70 C53EB116 1D8CFB41
EE7F4716 22CA8226
Ultimate/DOOM.EXE: SHA256 = 4970B0D1 FEFA4583 6A572377 7D2BB41E 79329657
82678ACA 6C2BBEEC 705B38D4
Ultimate/DOOM.EXE: SHA384 = C8147AB4 F431FAE9 4BAAEC92 26D4CE82 9E207507
008A0D80 3C6AF0ED B0432288 A0BE949B A805B9D6
C2AF7D91 C18860BB
Ultimate/DOOM.EXE: SHA512 = 9229510C AB17C9EB 01236255 7D0F6E4B 80E294B6
108F2CD2 AA188294 EF9DBEFB F7B52F06 9FAFE5BD
CE0FEAAB 50EC196F 2A195884 014B497E 9094EB55
40F35E75
Final Doom executable has the changes made in Ultimate DOOM, plus the altitude of teleported objects is no longer set to the floor. While autorun can be enabled in the other two versions by setting joyb_speed to 29, for Final Doom you must use 31 instead.
Team TNT wrote, "...we have some reports of teleport exits making you appear up in mid-air and dropping you. Cool effect, but it's a bug..."
Final/DOOM2.EXE: MD5 = F0 06 DE 4F D2 82 BA 61 D7 D0 AF 41 A9 93 F9 BA
Final/DOOM2.EXE: SHA1 = 9269 FA5C 0957 15D9 2601 5CAD 3381 A421 8E4F 2D7E
Final/DOOM2.EXE: RMD160 = 6108 03FB F4F6 7F65 1FAF FC67 2357 3CF7 6A68 8368
Final/DOOM2.EXE: SHA224 = 15985E25 AD1C89B8 C6DD9E30 707B3787 61731FF4 560CB9BF
DE298DFF
Final/DOOM2.EXE: SHA256 = 1F474EB4 7B440E44 D0A0931C ACC70E58 9884C22A EFDDD626
C71EE3A9 6A08EE4B
Final/DOOM2.EXE: SHA384 = B37A17C2 3E3B7F69 B2E2939A 02D97CF4 AD5EAF5F EA177B53
364F503B 284CF1B8 BFDDC981 B7A8D9A9 E4B0AA0F 3D179CD1
Final/DOOM2.EXE: SHA512 = 5B13B81E 72DE0798 937FED3B E736EFE2 562B1B2D 76653FBB
902E0A41 AA5D771A EA723486 4C2B6C7F 02EF2DEB FF2ED57E
6359A959 A5156D71 46AD860B D3303FDC