(Screenshot scaled from 640×400 to 640×480 to preserve original appearance.)
Last modified: 2024-09-28 19:34
(Screenshot scaled
from 640×400 to 640×480 to preserve original
appearance.)
Description: Faithful source port of DOOM 2 to Windows, Linux, et al.
Fraggle wrote:
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: https://www.chocolate-doom.org/wiki/index.php/Downloads
Latest source: github
To avoid poor-quality resampling you have to build Chocolate DOOM with libsamplerate support.
~/.chocolate-doom/chocolate-doom.cfg, set snd_samplerate to the native sample rate of your sound card / Alsa mixer / SDL mixer / PulseAudio and set use_libsamplerate to 5.I_SDL_PrecacheSounds: Resampling all sound effects to 44100 Hz........Then it should play normally with sound effects that are faithful to the original sound.
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.
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 https://sc55.duke4.net/games.php#doom.
If you dump the sound files into the directory specified by the setup
configurable music_pack_path, Chocolate DOOM 3.1.0+ will
recognize the commonly used file names automatically from the list
hardcoded in i_musicpack.c. You can also still put a file with the .cfg
extension that provides a mapping from the SHA1 hash of the music lump to
the 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.
There are now two ways to do this: with FluidSynth or with SDL2.
To use FluidSynth, select FluidSynth as the music option in chocolate-doom-setup and fill in the path to the soundfont file underneath it.
To use SDL2, select Native MIDI as the music option in chocolate-doom-setup but DON'T fill in a path to a Timidity configuration file. Leave it blank. Also make sure that you don't have /etc/timidity.cfg or any other Timidity config file in a default location. Then, when you run chocolate-doom, specify the path to the soundfont file in the SDL_SOUNDFONTS 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.
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.
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.
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.
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.
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++.
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.
(Very old info)
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.)