← Previous → Next Contents

Last modified: 2022-06-05 17:39

Best faithful source port:  Chocolate DOOM

(Screenshot scaled from 640×400 to 640×480 to preserve original appearance.)

Description:  Faithful source port of DOOM 2 to Windows, Linux, et al.

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 having an ISA Sound Blaster.

Chocolate DOOM offers a command line switch to select which of the four 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 just uses OpenGL to expand that to the current screen resolution.

Version 3.x releases:  http://www.chocolate-doom.org/wiki/index.php/Downloads

Latest source:  github

Sound configuration

Sound effects

To avoid poor-quality resampling you have to build Chocolate DOOM with libsamplerate support.

Patch to restore clipless resampling

Version 2 of Chocolate DOOM added support for Hexen, Strife, etc., but it reverted the high-quality resampling code to an earlier version that doesn't prevent clipping.

This patch restores the second-generation (clipless) libsamplerate code ported from 1.7.0, removes the manual scaling factor, and removes the sound effects cache size limit.  I see no point to having a size limit for the sound effects cache; any possibility of emulating Vanilla memory bugs goes out the window when resampling is done, and evicting the resampled sounds from memory only breaks things.

Note:  Pitch shifting (added in 2.3.0) still works with HQ resampling, but the sound quality is not preserved.


Chocolate DOOM now supports numerous ways of playing music.  It is often difficult to figure out which one is actually being used—if something fails, the usual behavior is to fall through to the next one with no error or warning message.  If /etc/timidity.cfg exists, there is a high probability of ending up with old timidity by accident in lieu of whatever you were trying to configure.

1. Music pack

Chocolate DOOM can substitute regular sound files for the MIDI music embedded in the WAD files, at the cost of possibly glitches when it loops.  Recordings of all the DOOM, DOOM 2, and Final DOOM MIDIs played on Roland hardware are available at http://sc55.duke4.net/games.php#doom.

The setup configurable music_pack_path is the directory containing the configuration files, not the sound files.  These config files provide a mapping from the SHA1 hash of the music lump to the file name of the music file to play.  Template config files can be found at https://github.com/chocolate-doom/music-packs or generated using the –dumpsubstconfig command line switch.

2. SF2 sound font

With luck, you can get Chocolate DOOM to use an SF2 sound font by setting an environment variable:

SDL_SOUNDFONTS=/usr/local/share/soundfonts/SF2/Scc1t2.sf2 chocolate-doom ...

Scc1t2.sf2 imitates the Roland Sound Canvas on which DOOM's music was composed, but you could use one of the Creative/E-mu SF2 files to sound like a Sound Blaster AWE64 or an arbitrary sound font of your choice.

3. Old timidity

The version of timidity that is bundled with SDL is only good for sound fonts that use Gravis UltraSound (GUS) type patch files.  A setup option exists to specify the timidity.cfg to use, though as previously noted, /etc/timidity.cfg has a way of cropping up whether you want it or not.

4. GUS emulation

The GUS emulation mode of Chocolate DOOM reproduces the bugs and limitations of the GUS support in Vanilla DOOM, which make the music worse not better.  All it really does is feed old timidity a config file that remaps instruments in the same way as the DMX library in Vanilla DOOM.

The .pat files must have lowercased names or you just get silence.

5. OPL2/OPL3 emulation

The OPL emulation is great if you want that glorious old Sound Blaster sound.  Great as it is, "there are some MIDI tracks and instruments that will sound wrong".

OPL3 stereo (with swapped channels) is supported via the snd_dmxoption configurable, which seems to get set automatically if you select OPL3 in setup.

6. Passthrough to OPL2/OPL3 hardware

In the unlikely event that you are running Chocolate DOOM on a PC with a sound card that has an actual OPL2 or OPL3 chip on it, Chocolate DOOM will try to use it.  The drivers need to be installed and you need permissions to write to the port.

7. Passthrough to external command

If you've got some way to play MIDI files, you can specify the command in the setup configurable snd_musiccmd.  This can be used to route the music to a sound daemon or external MIDI device via aplaymidi, or to Timidity++.

8. Platform MIDI

Apparently on Windows and Mac OS there is a MIDI API that Chocolate DOOM will try to use.


A lot of versions have come and gone since my original testing and I haven't tested with the serial track ball in a long time.  When I did test it, the response to the track ball was acceptable and remained smooth even as the mouse speed and acceleration parameters were increased to my preferred level of sensitivity.  However, vertical and horizontal sensitivity could not be configured separately, and still cannot.

There are minor, but audible, light clicking artifacts when sound effects start playing.  I have examined the raw resampled sounds and no spikes were evident, so I think the clicking must be getting introduced by SDL or by the way that chocolate-doom is using it.

Windows XP SP2

(Very old info)

Version tested:  chocolate-doom-r845-win32.zip

Source: (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.)

← Previous → Next Contents