← Previous → Next Contents
Last modified: Sun Jan 8 21:37:14 EST 2017
(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 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. If you are lucky enough to have a monitor and video driver that handle 320×200 correctly, then the only thing you get with the higher resolutions is more scan lines.
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.
Version 2.x releases: http://www.chocolate-doom.org/wiki/index.php/Downloads
Latest source (2.x branch):
git clone https://github.com/chocolate-doom/chocolate-doom.git
SDL_mixer version 1.2.12 added FluidSynth support, which makes possible the use of SF2 sound fonts. Chocolate DOOM has not yet caught up with this development, but if your SDL_mixer lib has been linked with FluidSynth (tested with fluidsynth-1.1.6), enabling it is easy. This patch adds a new setup/config variable, SDL_SF2_path, to specify the desired soundfont.
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.
Version 2 of Chocolate DOOM added support for Hexen, Strife, etc., but it reverted the resampling code to an earlier version that doesn't prevent clipping.
This patch is intended to apply after the previous one. It 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.
Note: Pitch shifting (added in 2.3.0) still works with HQ resampling, but the sound quality is not preserved.
You can choose between OPL emulation and "Native MIDI" in chocolate-setup. Chocolate DOOM can use actual OPL hardware if you have it, but if you have it then you might be able to run Vanilla DOOM.
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".
"Native MIDI" means SDL_mixer. Without the above patch to enable SF2 sound font support, you are using an old, bundled version of Timidity which is limited to using Gravis UltraSound (GUS) type patches for a sound font. For it to work, the GUS patches have to be installed in such a way that the SDL_mixer library will find them:
cp /usr/local/share/timidity/timidity.cfg /etc/timidity.cfg
dir /usr/local/share/timidityas the first line.
The resulting music isn't bad and it works reliably.
2.x added a GUS emulation mode that generates a Timidity configuration file and a corresponding setup option to specify its location. I have not tested it extensively.
To avoid poor-quality resampling you have to build Chocolate DOOM with libsamplerate support.
snd_samplerateto the native sample rate of your sound card / Alsa mixer / SDL mixer (48000) and set
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.
Given what a pain it has become to make standard VGA modes work on new monitors, you might need to try several resolutions in chocolate-setup to find one where DOOM's graphics don't end up being stretched or squashed in one direction or the other. All of these will be up-scalings done in software, which is fine as long as your graphics card has the bandwidth and isn't running in PCI compatibility mode.
If you want to try to bludgeon all recalcitrant hardware and software into producing the original 320×200 resolution to avoid the overhead of scaling, read on.
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
autoadjust_video_settings 0 fullscreen 1 aspect_ratio_correct 0 screen_width 320 screen_height 200
The 320×200 mode offered by X.Org in Slackware 14.0 has a vrefresh of 85.3 Hz, which is rejected by my LCD monitors. This is fixable with a modeline. The following works for my Dell 2007FP monitor if I set "Fill" mode and then manually adjust the horizontal in the monitor's menus (DVI works with less fiddling than the analog input):
Section "Monitor" Identifier "2007FP" # http://xtiming.sourceforge.net/cgi-bin/xtiming.pl + tweaked horiz Modeline "320x200" 12.02 320 344 360 400 200 204 207 211 doublescan EndSection
OTOH, it's impossible to define any 320×200 mode that will display correctly on my ASUS VK246H widescreen monitor because the menu option for aspect ratio is always grayed out. Given that it's stuck in 16:9 mode, the only thing to do is set the pixel width to the closest multiple of 8 to the width it would need to pillarbox a 320×200 source. Thus:
Section "Monitor" Identifier "ASUS VK246H" Modeline "424x200@76d" 16.43 424 456 480 512 200 204 207 211 doublescan # HorizSync = 32.09 kHz EndSection ... Subsection "Display" Depth 24 Modes "1920x1080" "424x200@76d"
In ~/.chocolate-doom/chocolate-doom.cfg, change 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.
If you get 256×200, then you still need to set aspect_ratio_correct to 0. Similarly, if it all gets blown away and changed to 640×480, then you still need to set autoadjust_video_settings to 0.
Support for custom modelines has been unreliable since the version jump from 295 to 304. As of 304.123, custom modelines are accepted if Option "ModeValidation" "AllowNonEdidModes" is added to Section "Device" and will sometimes do the right thing, but not always. With 304.123 drivers, an AGP 6200, and a Dell 2007FP monitor, the 320×200 mode was corrupted on DVI and horizontally squished on D-sub. It worked fine with the 331.67 drivers and a PCIe 8500GT. The 424×200 mode worked fine with the 343.36 drivers and a GTX 970.
In cases where it does not work, reverting to 173.14.39 will fix the problem, but 173.14.39 is out of maintenance and needs patching for compatibility with recent kernels.
(Very old info)
Version tested: chocolate-doom-r845-win32.zip
Source: http://126.96.36.199/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.)