Last modified: Sun Mar 15 14:32:24 EDT 2009

(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. However, as usual, sound is not identical to Vanilla DOOM because the sound code was omitted from the public release of DOOM source, and because we can't count on an ISA SoundBlaster.
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.2.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 passable 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
Update 20090205: Just upgraded my old Gateway EV910 CRT monitor to an ASUS VK246H 1920×1080 LCD monitor, and lo, it does not natively support a normal 320×200 mode, nor even 640×400. This monitor's EDID specifies a minimum HorizSync of 31 kHz and a maximum VertRefresh of 76 Hz, so the custom mode defined below just barely fits within spec:
Section "Monitor"
Identifier "ASUS VK246H"
Modeline "424x200@76d" 16.43 424 456 480 512 200 204 207 211 doublescan # HorizSync = 32.09 kHz
EndSection
Section "Screen"
Identifier "Screen 1"
Device "GeForce 6800 GT"
Monitor "ASUS VK246H"
DefaultDepth 24
Subsection "Display"
Depth 24
Modes "1920x1080" "424x200@76d"
ViewPort 0 0
EndSubsection
EndSection
It's possible to define a 320×200 modeline that is within spec, but the monitor's menu option for pillarboxing is grayed out in this mode. 424 is the closest multiple of 8 to the width in pixels that the 16:9 screen ought to display to maintain the correct shape of pixels from a 320×200 source. In ~/.chocolate-doom/chocolate-doom.cfg, I changed screen_width from 320 to 424. Now when Chocolate DOOM runs, it switches to the 424×200 resolution and pillarboxes a correct 320×200 image in the middle of the wider screen.
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. The final, debugged version of that patch was checked in as r1479 (2009-03-15). You can either get the current release from subversion or you can apply this patch to Chocolate DOOM 1.2.1.
For 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 will be room for the expanded sound effects. (If I ever fork Chocolate DOOM, eliminating the memory management cruft will be high on my list.)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.)