Chocolate Doom

[fraggle]

Chocolate Doom is a conservative, historically accurate source port that recreates the experience of playing vanilla Doom on modern machines.

• For common questions, read the FAQ
   
• To report a bug, file an issue on Github. But be aware that your bug might be intended behavior.
   
• For latest bleeding-edge builds, check out http://latest.chocolate-doom.org.

See the first thread for older posts on Chocolate Doom.

 

[VGA]

lmao I thought there was a new release or something

[vadrig4r]

The King is dead, long live the King!

[HavoX]

Ten years, huh? Let's make sure this one lasts ten years as well, if not more!

[Gez]

Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom: The Next Generation

"♬ Captain Jean-Luc Fraggle, USS Chocolate ♪ ♫"

[Danfun64]

Vanilla, the first frontier. These are the voyages of the USS Chocolate. Its continuing mission: To explore strange old environments. To emulate old bugs and strange DOS behavior. To boldly return to a state that no Doom Source Port has ever experienced before!

edit: To be serious, you guys are doing really great work with Chocolate! Keep up the good work in bringing Vanilla to new devices.

[Csonicgo]

Here is an idea that I've been thinking about for a while-

A lot of users that aren't familiar with Choco's philosophy always mention options for limit removing. Currently, there is no port that lets the user tweak limits easily. Instead of closing those requests as against philosophy, Chocolate Doom can still keep its philosophy but at the same time make these "limits" easier to change.

First way this could be accomplished is an extra header file that simply contains the evil MAX* defines. These could be tweaked by a beginner that wants to use chocolate doom, heretic, hexen, or strife, but cannot stand the "low" static limits. Crispy Doom has been recommended to people that want extended limits, but there are features of Crispy that replace vanilla doom features. This would allow users with the build tools available to "roll their own" versions of chocolate doom easily without having to worry about feature creep from other forked ports. This would also require the programmer to know a little about what they're doing - so a few "presets" that could be commented out would be a great start.

Second way is through -gameversion. This way, if they want doom-plus limit extending, they must specify it. Candidates I had in mind were "1.9+", "ultimate+", "final+" and "final2+". If I record demos in an extended limit map with final2+, they will only play back correctly with final2+. Seems fair. If there is a rise in Doom+ demos, then Chocolate would be able to play them.

Third way is through setup. Not only would we get to pick the MAX defines, but presets could also be made available to simulate older versions (v1.2 anyone?) for those who would like to make a map for an older version and get a feel of those limitations.

I don't think the third way has much of a chance, and the second way may be pushing it - but the first method would be acceptable I think, as modifying the file would be completely optional, and if others want extended limits, they aren't intimidated by having to hunt around the source files, or downloading a fork that may not be precisely what they want.

[kb1]

fraggle said:

This is a replacement for this thread which valiantly ran for over 10 years before it became too big for the Doomworld forums to cope with...

Did it actually reach a forum software limit? You must emulate the forum crash in this thread...You know better than that, man. :)

On a serious note: Thank you fraggle (and your contributors) for the #1 definitive port. Actually Chocolate Doom is the ONLY true "port" in the real definition of the word. An excellent port - great job!

[Altazimuth]

HavoX said:

Ten years, huh? Let's make sure this one lasts ten years as well, if not more!

Extra! Extra! Read all about it! Doomworld user HavoX condones losing interest in Chocolate Doom, and other juicy scoops just like it.

In all seriousness, it's nice to see the Chocolate Doom thread up and rolling again. Keep up the great work on the port.

[Danfun64]

Csonicgo said:

...if they want doom-plus limit extending, they must specify it. Candidates I had in mind were "1.9+", "ultimate+", "final+" and "final2+". If I record demos in an extended limit map with final2+, they will only play back correctly with final2+.

ATM there are no final+ or final2+ executables in existence, unless they are hidden somewhere next to the doom+ and doom2+ exes

[VGA]

Danfun64 said:

ATM there are no final+ or final2+ executables in existence, unless they are hidden somewhere next to the doom+ and doom2+ exes

I guess he means the final doom code with raised limits per the doom-plus modifications.

[Linguica]

Chocolate Doom supports longtics already, so I don't see why a limit-raising parameter would be bad.

Frankly, I would maybe even argue that raised limits ought to be on by default when you download Chocolate Doom. It's nice to have the option to have all the old limits in place, but do most users really feel warm and fuzzy inside when Chocolate Doom bombs out with a visplane overflow, or when a savegame is too large?

[andrewj]

Linguica said:

Frankly, I would maybe even argue that raised limits ought to be on by default when you download Chocolate Doom. It's nice to have the option to have all the old limits in place, but do most users really feel warm and fuzzy inside when Chocolate Doom bombs out with a visplane overflow, or when a savegame is too large?

I think it is about maintaining a standard. If Chocolate-Doom allows maps with greater visplanes than Vanilla, even as a option, then it is no longer living up to that vanilla standard.

Personally I'm not sure that this vanilla standard deserves to live on, but it has been a cornerstone of Chocolate-Doom since its inception and I'd be surprised if fraggle would change that now.

[Linguica]

There's a difference between "maintaining a standard" and being needlessly antagonistic towards a user. Certainly Chocolate Doom wants to maintain awareness of the limits and make sure people acknowledge them. But no one applauds a program crashing in the middle of using it and is glad it did so.

For instance Chocolate Doom does already in fact break vanilla compatibility by letting users choose the option to save games without hitting the buffer overflow. Presumably this is because they considered it needlessly cruel to cause the player to lose all their progress. But at the same time I'm not sure why the distinction is made between the player hitting F6 and losing all their progress, and turning to an angle where they can see 129 visplanes and losing all their progress. It's a distinction that a user is not going to appreciate.

A more friendly attitude could be taken for certain common errors - instead of calling I_Error() and just instantly shutting down the game, bring up a dialogue similar to the quit-game one and have the player hit N to continue or Y to nod meekly and close the game. I venture most people would hit N.

[andrewj]

I agree it is cruel to just I_Error() on a visplane overflow or a savegame overflow (also I didn't know the savegame error had become optional, does seem hypocritical to allow one but not the other.)

But that cruel behavior is what Vanilla does, and if the behavior stops being cruel then I think mappers stop having any incentive to fix their maps to prevent it -- and then the vanilla standard is effectively dead.

So even though I don't particularly agree with keeping any kind of cruel behavior, I respect the decision to keep it -- namely that Chocolate-Doom should behave the same way as Vanilla, warts and all.

[printz]

I think all the limits, including savegame behaviour, should be enforced in Chocolate Doom, without the option to get rid of them. But there should also be a Chocolate Doom+ (chocolate-doom-plus.exe) which increases the limits in the same way as entryway's Doom+ project.

[dew]

printz said:

I think all the limits, including savegame behaviour, should be enforced in Chocolate Doom, without the option to get rid of them. But there should also be a Chocolate Doom+ (chocolate-doom-plus.exe) which increases the limits in the same way as entryway's Doom+ project.

That seems unwieldy and cryptic for the general audience though. Maybe if both were distributed together, but even then it'd lead to confusion.

I'd say limit removal support would be a smart move, since choco would become a viable choice for all wads "below" Boom. As it stands, differentiating between vanilla-compatible and limit-removing wads in order to decide between playing in choco and prboom-plus is a huge hassle, not to mention you don't always have the necessary info. To be honest, the simplified advice I'd give to any beginner would be "it's not worth risking using choco outside of IWADs".

Oh and try asking any vanilla mapper what their initial reaction was when they learned about chocorenderlimits.

[Da Werecat]

andrewj said:

But that cruel behavior is what Vanilla does, and if the behavior stops being cruel then I think mappers stop having any incentive to fix their maps to prevent it -- and then the vanilla standard is effectively dead.

It's already dead in the sense that no one is required to conform to it. As a self-imposed limitation during mapping - sure, why not. But those who consciously map with this limitation probably don't care if it's forced in a random source port or not.

printz said:

I think all the limits, including savegame behaviour, should be enforced in Chocolate Doom, without the option to get rid of them.

In this case I'd also propose moving all additional features such as novert and dehacked patch handling into their own executables (or removing them althogether) for maximum hardcorness.

[Perilous Pear]

Oooh another thread, beam us up for this one (Even though I recently joined).

For the limit removing, I'm for it. Since most of those bugs are nuisance anyway, and were just hardware limitations at the time. If id made the game now, there isn't a single doubt in my mind they would remove all the visplane and save game buffer overflows. Maybe infinitely tall actors, but that isn't much of a problem.

It stays true to vanilla enough to leave some non-game breaking and innocent bugs, like that clipping trick in E2M6, and some glides. Tricks you can't re-create in some source ports.

I personally don't know anybody who plays a game, an error pops up, or an X-box red-rings, or whatever, they lose everything and go: "Oh, nevermind, at least it was like this back in the day". Maybe some of you guys like that, and I'm not calling you out on this or anything. But that's my view on all of this.

[chungy]

Has everyone forgotten that Crispy Doom is a thing? That is already your "Chocolate Doom+"

[Arctangent]

chungy said:

Has everyone forgotten that Crispy Doom is a thing? That is already your "Chocolate Doom+"

Csonicgo said:

Crispy Doom has been recommended to people that want extended limits, but there are features of Crispy that replace vanilla doom features.

[vadrig4r]

Perilous Pear said:

Oooh another thread, beam us up for this one (Even though I recently joined).

For the limit removing, I'm for it. Since most of those bugs are nuisance anyway, and were just hardware limitations at the time. If id made the game now, there isn't a single doubt in my mind they would remove all the visplane and save game buffer overflows. Maybe infinitely tall actors, but that isn't much of a problem.

It stays true to vanilla enough to leave some non-game breaking and innocent bugs, like that clipping trick in E2M6, and some glides. Tricks you can't re-create in some source ports.

I personally don't know anybody who plays a game, an error pops up, or an X-box red-rings, or whatever, they lose everything and go: "Oh, nevermind, at least it was like this back in the day". Maybe some of you guys like that, and I'm not calling you out on this or anything. But that's my view on all of this.

This might help you understand what Chocolate Doom is and why.

[fraggle]

Thanks for all the kind words, everyone. This is just a new thread - I didn't mean for it to represent any kind of milestone. But I'm glad people appreciate my work (and those of the rest of the team!) :)

chungy said:

Has everyone forgotten that Crispy Doom is a thing? That is already your "Chocolate Doom+"

Yep, this is basically my reply too. I understand that it's probably frustrating if you like Chocolate Doom and just want that one extra feature... But I kind of feel like I've stuck my stake in the ground at this point. Please don't think that I haven't put a lot of thought into these decisions already.

Consolidating the limit #defines in a single header file to make integration with Crispy Doom easier might be a good idea - I'd have to consult with Fabian to see if that's something he really needs though.

[Perilous Pear]

Haven't heard a word about Crispy Doom, I guess I could use some source port exploration.

[Quasar]

It's a wild suggestion I know, but maybe Choco is worthy of having a whole forum instead of another 10-year long thread? :V

[VGA]

Personally, I like having these stickied threads with these ports. I don't think there'd be enough content for a subforum. In fact, I'd like Eternity to be one thread here like the rest, heh.

[HavoX]

Quasar said:

It's a wild suggestion I know, but maybe Choco is worthy of having a whole forum instead of another 10-year long thread? :V

Heeeeey, there's a thought!

[fraggle]

So, cool development that I thought I'd share: I added Mac retina display support tonight. Modern Macs have really high resolution screens but the software essentially "pretends" to be a display with half the resolution for backwards compatibility. The idea is that higher resolution should add more detail, not make everything on your desktop tiny. But applications need to support it explicitly to make use of that higher resolution.

So I turned it on for Chocolate Doom and it makes a pretty nice improvement, especially if you're running at a low resolution - for example, a "320x240" window is now actually a 640x480 window. But the really nice thing is that an "800x600" window is actually a 1600x1200 window, which is a pixel-perfect integer scale-up. Here's a screenshot - if you zoom in you'll find that none of the pixels have any of the normal blurriness around them.

[vesperas]

I'm also interested in this. With the release of Chocolate Doom 3.0.0 I'm in fact planning to make a fork which is exactly identical to Chocolate but with raised limits (and maybe an extra option in the compatibility tab of the setup program to support a resolution of 640x400 pixels). Having all the defines in a single header file would be nice, albeit not essential.

[fabian]

Csonicgo said:

[...], but there are features of Crispy that replace vanilla doom features.

Yes, I had to replace some functions in Chocolate Doom to e.g. work around rendering glitches or bugs that lead to maps crashing. Which "features" do you exactly mean that have replaced Vanilla "features"?

fraggle said:

Consolidating the limit #defines in a single header file to make integration with Crispy Doom easier might be a good idea - I'd have to consult with Fabian to see if that's something he really needs though.

Honestly, it won't help at all. For quite some time, Crispy Doom isn't just limit-raising anymore, but has removed any critical limits. That is, most of these #defines are back at their original values and arrays are resized dynamically.

vesperas said:

With the release of Chocolate Doom 3.0.0 I'm in fact planning to make a fork which is exactly identical to Chocolate but with raised limits (and maybe an extra option in the compatibility tab of the setup program to support a resolution of 640x400 pixels). Having all the defines in a single header file would be nice, albeit not essential.

This is *exactly* how Crispy Doom started out some two years ago. More specifically, it might be this patch that you are looking for:

https://github.com/fabiangreffrath/crispy-doom/commit/7ddae38bb3cba814e9cff13ab75898f1f01d20aa

I don't think it is necessary to have all these #defines in one header file, though.