Chocolate Doom 2.1.0 released

[chungy]

This release brings some rather significant improvements over Chocolate Doom 2.0.0. Some highlights of what has been added among all four games supported are:

• Support for substitute music packs in Ogg Vorbis or FLAC formats, intended to replace OPL or MIDI synthesis with recordings from a Roland SC-55
• Support for joysticks and gamepads has improved significantly, with several built-in configurations for common devices
• Multiplayer with fully working sound should work for all platforms now. The old netsync code is also presently the default mode until 2.0.0's kinks can be worked out.
• PNG screenshots are now supported. Taking screenshots without -devparm is also supported.
• The -geometry command-line parameter now works more like PrBoom, allowing you to specify a windowed or full-screen mode with the letters 'w' or 'f' appended to the dimensions.
• All games now exit with a helpful error message when the wrong IWAD is loaded (eg, hexen.wad with Chocolate Strife)

There are also numerous changes to each game, including many compatibility improvements for Doom, Heretic, Hexen, and Strife. You can view the release announcement on GitHub. Pre-built downloads for Windows and Mac, as well as source code for other platforms are linked on the Chocolate Doom wiki; NixOS, Arch Linux, and Debian Sid users also all have had their packages updated for the 2.1.0 release.

[Doom_user]

I have a question/complaint about Chocolate Doom. When running a screen resolution of 1920x1080, why is the game rendered at 1280x1000 instead of 1280x960? 1280x1000 isn't a 4:3 aspect ratio and as a result everything gets vertically stretched and looks wrong.

[fraggle]

I'd encourage people to skim through the entire release notes as there are a whole bunch of things that have been changed and improved. They're mostly small things, but I hope that some of them, like the fixes to the OPL MIDI playback, which was clearly a pain point to a lot of people, should make a big difference.

One other thing I'm including in this version for the first time is the philosophy document, which attempts to describe the design philosophy behind Chocolate Doom. I get a lot of requests for features to add to Chocolate Doom, many of which I end up rejecting, and I hope that this helps explain the reasoning and arguments that I use to decide whether to accept or reject feature requests. It also might just be interesting if you're a user.

One thing I should note: chungy's post mentions the PNG screenshot and substitute music pack support. The Windows binaries on the website don't actually have this compiled in, so if you're using Windows you might be disappointed. These two features require some extra libraries (for PNG, FLAC and Ogg Vorbis support) and there have been some teething problems getting the libraries to compile and work on Windows. Hopefully I can supply some updated binaries in the future.

Doom_user said:

I have a question/complaint about Chocolate Doom. When running a screen resolution of 1920x1080, why is the game rendered at 1280x1000 instead of 1280x960? 1280x1000 isn't a 4:3 aspect ratio and as a result everything gets vertically stretched and looks wrong.

So first of all, the context here is that Chocolate Doom can only scale up to certain predefined sizes (640x480, 960x720, etc.). The simple answer is that 1280x1000 is closer to your actual screen size than 1280x960 is. When you're using a mode like 1920x1080, for which there is no "perfect" scale-up algorithm, it tries to pick one that's as close as possible, to minimize the amount of black border that you get at the screen edges.

You ask another good question, which is: why is there 1280x1000 in addition to 1280x960? The answer is complicated so bear with me.

When scaling up the screen and doing aspect ratio correction, there are two possible ways to adjust to the desired 4:3 aspect ratio. The first is to scale up and stretch the screen vertically. This is what you get when you're using 640x480 for example. 640x400 is a pixel-doubled 320x200, which is then stretched to the desired aspect ratio of 640x480.

The other option is that you can squash the screen horizontally. When you're using 800x600 this is what's happening: 320x200 is tripled up to 960x600 and then squashed horizontally to 800x600.

These are essentially two different algorithms that achieve the same thing, though they each can reach different sets of resolutions. Without the squashing algorithm it wouldn't be able to do 800x600, which is (or was) a very common resolution.

When you're using 1280x960 you're getting the stretched version (320x200->1280x800->1280x960) whereas 1280x1000 is the squashed version (320x200->1600x1000->1280x1000). Note that the squashed resolution is actually the wrong aspect ratio (1.28 rather than 1.33). In your case that's what you get because it's slightly closer to the ideal 1920x1080.

Several of the squashing aspect ratios are actually at this wrong 1.28 aspect ratio. Even though it's not exactly right, it's closer to 1.33 than the "uncorrected" 1.6 that you get from simple pixel doubling. However, after considering this more I do think you're right to bring it up. It's better to use the right aspect ratio in this case and I don't think that 1280x1000 adds anything. I've filed a bug to remove 1280x1000.

In the future I hope these issues should go away as Chocolate Doom will be able to use hardware scaling to efficiently reach any resolution. There's an experimental branch called gl-branch that adds this, or you can check out the bug to add it.

[axdoomer]

release notes says:
Behavior of older versions of Doom back to v1.666 can now be emulated.

Doom v1.666 emulation? What was changed between Doom v1.666 and Doom v1.9? The only changes I know between those two versions are sound code changes. Other changes were in the IWAD.

[fraggle]

axdoom1 said:

Doom v1.666 emulation? What was changed between Doom v1.666 and Doom v1.9? The only changes I know between those two versions are sound code changes. Other changes were in the IWAD.

No changes to game behavior as far as I can tell. All this really does is change the version number in the .lmp demo header so that you can play old demos.

There were more changes in earlier versions. PrBoom+ can actually emulate v1.2 behavior, and there were a lot more changes between 1.2 and 1.666 to the game behavior. I'm planning to steal this feature so that Chocolate Doom can do the same ;) It's just a shame that we can't emulate v1.1 yet - I want to be able to watch those monsters tearing themselves to death.

[chungy]

fraggle said:

The Windows binaries on the website don't actually have this compiled in, so if you're using Windows you might be disappointed. These two features require some extra libraries (for PNG, FLAC and Ogg Vorbis support) and there have been some teething problems getting the libraries to compile and work on Windows. Hopefully I can supply some updated binaries in the future.

Hmm, I'm disappointed and I don't even use Windows! What kind of problems have been encountered with this? Is there a bug in the issue tracker about it?

Also, why stop at Doom 1.1? Going all the way back to shareware 0.99 would be sweet :)

[StalkerZHS]

So I just installed ChocoDoom 2.1.0 and I end up switching the music to GUS. It autodetected Doom3BFG's GUS patches just like the changelog said it was supposed to. Everything SHOULD have been fine, but when I entered the game there was NO music.