Crispy Doom 6.0 (Update: Mar 31, 2023)

[ReFracture]

I gotta say I REALLY like that HUD, all the information from the status bar lined up just like normal but without the bar itself.. awesome.

If that was translucent and also showed stats for kills/items/secrets it would be my top pick for Doom huds.

[fabian]

plums said:

I like it, it's a nice little touch. Gibbing is fairly rare but I think that's appropriate.

Yes, it should be the absolute exception, not the rule!

edit: BTW sound no longer goes off when the game is paused using that exe above.

Really? It does for me. I didn't change any code related to music playback or pause.

Mike.Reiner said:

I gotta say I REALLY like that HUD, all the information from the status bar lined up just like normal but without the bar itself.. awesome.

Thank you!

If that was translucent and also showed stats for kills/items/secrets it would be my top pick for Doom huds.

I do not want to overload the HUD, but you may want to enable the level stats for the automap. So far I have successfully resisted to make the HUD translucent, because - honestly - does it really help if it is *less visible*? ;)

BTW, last EXE for this week, I'll be on vacation...
http://www.greffrath.com/~fabian/crispy-doom-45cf738ad5.exe

Edit: Vertical aiming is now optional, you'll have to re-enable it in crispy-doom.cfg. It will be possible to enable it in the setup tool in the next release, of course.

[plums]

Oops, my mistake, I forgot I changed my music to Native MIDI (without timidity) which isn't really controlled by chocolate/crispy doom.

Have a good vacation!

[ReFracture]

fabian said:

I do not want to overload the HUD, but you may want to enable the level stats for the automap. So far I have successfully resisted to make the HUD translucent, because - honestly - does it really help if it is *less visible*? ;)

Heheh, no, not really. Still, great work.

The only other suggestion I'd have then is perhaps to put ammo, health, and armor icons beneath their respective values while using that hud.

[plums]

So even though there's no more updates to the other Crispy games, how much work would it be to get the patches as they are applied to the current Chocolate games branches? Since those are still being updated, it would be nice if the updates also made it into the Crispy versions.

[fabian]

Mike.Reiner said:

The only other suggestion I'd have then is perhaps to put ammo, health, and armor icons beneath their respective values while using that hud.

That should be redundant. As soon as the HUD requires labels next to the numbers, it cannot be considered self-explanatory anymore. I doubt there is a risk of mixing the numbers up if you ever played Doom with the regular status bar on, though.

plums said:

So even though there's no more updates to the other Crispy games, how much work would it be to get the patches as they are applied to the current Chocolate games branches? Since those are still being updated, it would be nice if the updates also made it into the Crispy versions.

The extra effort would be close to zero and I will consider adding them back in the next release. But if you want additional features in them, please provide patches. ;)

[plums]

fabian said:

The extra effort would be close to zero and I will consider adding them back in the next release. But if you want additional features in them, please provide patches. ;)

Excellent, and I juuuuust might :D In any case I should at least set myself up to be able to compile git versions myself.

[fabian]

I have made a new test build available for download:
http://www.greffrath.com/~fabian/crispy-doom_1.3~beta1.zip

Changes in this version:
- Merge chocolate Doom master branch up to commit 242fa1ee46.
+ Fixes a segfault when using Native Midi on Windows, thanks Karl-Stephan Werkmeister for the bug report.
- Add a "quick reverse" key.
- Prevent overriding demos by adding a file name suffix, e.g. -001.
- Entering menus while recording demos pauses the game to prevent desyncing.
- Support inverted mouse on the vertical axis.
- Update automap while playing.
- Center player view when dying or when hitting hard ground, the latter only when mouse look is disabled.
- Fix tutti-frutti effect around the weapon sprite.
- Improve corpse flipping randomization by improving corpse health randomization.
- The lethal pellet of a point-blank SSG blast gets an extra damage boost for the occasional gib chance, disabled in demo recording/playback and netgame mode.
- Add key to toggle always run, default to Caps Lock.
- Make vertical aiming optional, can be enabled in crispy-doom-setup, is disabled by default and in demo recording/playback and netgame mode.
- Center automap markers on the map and fix a crash when a marker reaches the border of the map.
- If the player dies and the game has been loaded or saved in the current level in the mean time, reload that savegame instead of restarting the level from scratch.
- Fix statusbar and face being sometimes visible when using noclip and the screen is not entirely overwritten by columns.
- Add flashing HOM indicator.
- Port "flipped levels" feature over (i.e. steal) from Strawberry Doom.
- Make the SSG available in other gamemodes if the required resources are available, try "crispy-doom -iwad doom.wad -merge doom2.wad doom.wad" and type IDKFA.
- Implement Boom's "tntem" and PrBoom+'s/ZDoom's "notarget" cheats.
- Add a new Crispy Doom icon: The Crispy Doom icon is now composed of the Chocolate Doom icon and a photo of potato crisps (Utz-brand, grandma's kettle-cooked style) by Evan-Amos who kindly released it into the public domain.
- Allow Chocolate Doom 2.0.0 clients to connect to Crispy Doom servers.

[plums]

Nice!

One problem already, I can't turn vertical aiming on. Running the setup program will always start with "Enable vertical aiming" off. In the last git build you posted, I had to enable this setting by editing crispy-doom.cfg since the setup program wasn't also updated, but in this version I can't find that setting even in the cfg file.

Also, what is the "flipped levels feature"?
edit: I figured it out, '-fliplevels' right? Pretty cool, gets me really confused on classic maps like E1M1.

[fabian]

plums said:

One problem already, I can't turn vertical aiming on. Running the setup program will always start with "Enable vertical aiming" off. In the last git build you posted, I had to enable this setting by editing crispy-doom.cfg since the setup program wasn't also updated, but in this version I can't find that setting even in the cfg file.

Indeed, missed one line of config parsing. Thanks for noticing!

Also, what is the "flipped levels feature"?
edit: I figured it out, '-fliplevels' right? Pretty cool, gets me really confused on classic maps like E1M1.

Funky, isn't it?!

[plums]

fabian said:

Funky, isn't it?!

Really confusing at times, muscle memory is quite strong on some levels. A good way to play old maps you're familiar with though, and put a spin on them.

Since you have the SSG for Doom 1 enabled, and new cheat codes, perhaps another new cheat to give only the SSG is a good idea? Also how does that work with game saves?

[fabian]

plums said:

Really confusing at times, muscle memory is quite strong on some levels. A good way to play old maps you're familiar with though, and put a spin on them.

I also find it interesting how different certain levels look and how much one got used to their original layout. It's really a completely different feeling to some of them.

Since you have the SSG for Doom 1 enabled, and new cheat codes, perhaps another new cheat to give only the SSG is a good idea?

That would be "tntweap9" which I have just implemented.

Also how does that work with game saves?

They would get pretty much screwed up, I'd say. It's a similar situation to when you save a game with a PWAD loaded and try to load it without that PWAD. If the necessary resources are missing, things go weird. :)

Edit: What I meant to say was, if you keep the command line intact, loading and saving games should work flawlessly. However, if you try to load a Doom1+SSG game without the additional command line parameters/resources, things will break.

Edit 2: You can even run "crispy-doom -iwad doom.wad -merge doom2.wad doom.wad", type "IDKFA", select the SSG and then save the game and then load that saved game with Chocolate Doom if the latter is also invoked as "chocolate-doom -iwad doom.wad -merge doom2.wad doom.wad". However, you will lose the SSG as soon as you (are forced to) switch weapons.

[fabian]

fabian said:

- If the player dies and the game has been loaded or saved in the current level in the mean time, reload that savegame instead of restarting the level from scratch.

In current GIT this can be overridden by holding the Run key during resurrection.

[fabian]

It is my pleasure to annouce that I have just released Crispy Doom 1.3!

Please check out the Crispy Doom homepage for more information:
http://fabiangreffrath.github.io/crispy-doom

The Crispy Doom source code is available at GitHub:
https://github.com/fabiangreffrath/crispy-doom

Binaries for Windows (x86) are available here:
http://www.greffrath.com/~fabian/crispy-doom_1.3.zip

Have a lot of fun!

- Fabian

Edit: In unrelated news, I have just found an old announcement of Crispy Doom on Doom Universe:
http://thedoomuniverse.prophpbb.com/topic653.html

Since I am not going to register to another forum just to clear out some rumors, maybe someone could cross-post this there: My name is Fabian, not Fabien, and I am not the creator of "a shitty source port for Duke Nukem 3D, called Chocolate Duke3D". Thanks!

[plums]

Awesome news! Thanks for including the other crispy games as well. I played with the SSG in Doom 1 a bit, it's interesting. Makes the iwad maps too easy, but it would be good for other maps that use too many cacos and barons.

[fabian]

plums said:

I played with the SSG in Doom 1 a bit, it's interesting. Makes the iwad maps too easy, but it would be good for other maps that use too many cacos and barons.

Playing Doom 1 + SSG with "-fast" should feel more balanced.

[plums]

One thing I've noticed with the flashing HOM indicator is that it makes slime trails stand out quite a bit more. Normally they're fairly harmless but when they're big red lines it's really noticeable. Tends to be a bit distracting...

[fabian]

plums said:

One thing I've noticed with the flashing HOM indicator is that it makes slime trails stand out quite a bit more. Normally they're fairly harmless but when they're big red lines it's really noticeable. Tends to be a bit distracting...

Indeed. I've noticed that before but forgot about it, so it's good that you remind me. I think I'll leave them being drawn black and turn the red flashing into a command line parameter.

[fabian]

fabian said:

I think I'll leave them being drawn black and turn the red flashing into a command line parameter.

This is implemented in the test build below; the new command line parameter is "-flashinghom":

http://www.greffrath.com/~fabian/crispy-doom_e10b89fb98.exe

This test build also contains the "walk over/under objects" feature that you requested on Github. It allows players (and only players) to walk over/underneath shootable objects (and only shootable objects), i.e. monsters and barrels.

Some restrictions apply to this feature:
1) Only the player can walk over or underneath other objects, monsters can not. This prevents multiple monsters from piling up and avoids more complicated checks in the code (and the inclusion of additional object flags indicating "this monster is already part of a pile" that would break compatibility).
2) It is only allowed to walk over or underneath shootable objects. Most other objects (e.g. lamps, trees, columns) have arbitrary heights hard-coded into the Doom engine which do not necessarily match the actual appereance in the game. So far, this did not matter, because the objects were blocking the player's path anyway. All of these objects would need their height menually adjusted, which I find on the one hand too subjective and simply not worth it on the other. Additionally, these objects are often modified by Partial Conversions and the manually defined heights would then be inappropriate again.
3) Melee attacks are entirely unaffected by this feature. That is, it is still possible for a monster to bite you, even though you are standing on an edge thousands of height units above it or even on its head.

To test this feature, please change the "crispy_overunder" config item to "1" in the config file after the first run. Please find a test level based on the one you provided on Github here:

http://www.greffrath.com/~fabian/overunder.wad

As before, fire the pistol to wake up the cacodemon and walk underneath it. Then you may run over the edge and across a demon's head and a bunch of barrels. Please notice how the cacodemon is not able to trace you down the corridor until you killed the demon by destroying those barrels.

[plums]

fabian said:

This test build also contains the "walk over/under objects" feature that you requested on Github. It allows players (and only players) to walk over/underneath shootable objects (and only shootable objects), i.e. monsters and barrels.

Great! This is a very clever implementation of that feature (~10 LOC!), I'm quite impressed. I think the restrictions are actually not a problem at all. IMHO the main attraction to having monsters not being infinite height is so you don't get stuck under cacodemons you can't see, or above imps while trying to run off of a ledge, and both of those cases are taken care of.

2) It is only allowed to walk over or underneath shootable objects.

Not only does this make the coding easier, but I think it preserves map intent a little more - decorations are sometimes used to block the player. Doom 2 MAP19 comes to mind, where being able to walk above torches leads to some unintended shortcuts.

3) Melee attacks are entirely unaffected by this feature.

That's fine, I think this is still the case in other ports that allow things above things, as well as the other Doom engine games.

Tested this with the example wad and a few others, seems to work as intended!

[fabian]

Update 12 June 2014: Crispy Doom 1.4 has been released!

Crispy Doom is a fork of Chocolate Doom that provides a higher display resolution, raises the static limits of the Doom engine and offers further optional visual, technical and gameplay-affecting enhancements while remaining entirely config file, savegame, netplay and demo compatibile with the original.

Highlights of this release:

* Players are now allowed to walk over or underneath shootable objects, i.e. monsters and barrels.
* Automap improvements.
* HUD improvements.
* Translucent gun flash sprites.
* Prettier screen shots.
* etc.

Please visit the Crispy Doom homepage for more information:
http://fabiangreffrath.github.io/crispy-doom

The Crispy Doom source code is available at GitHub:
https://github.com/fabiangreffrath/crispy-doom

Binaries for Windows (x86) are available here:
http://www.greffrath.com/~fabian/crispy-doom_1.4.zip

Have a lot of fun!

- Fabian

[plums]

Excited as always to see a new release. This caught my eye from the Crispy Doom page:

Secret sector boundaries are now drawn in purple until they are revealed (i.e. as long as sector->special == 9).

This is a very useful and sane implementation of this feature! Having to toggle it through the menu when I want to cheat to find missing secrets always seemed unnecessary.

[Phil1984]

This port is rapidly becoming my number 1 port. I've always erred more on the doom purist side of things so chocolate doom is a brilliant piece of software for me buuut......I grew up on MacDoom which had a 640x400 resolution so Doom as it was on DOS just seems way too pixelated for my nostalgia's liking.

On top of that there are a few features added that I consider worthy improvements over the original exe such as monster/secret counts, key doors showing up on automap and a coloured HUD. And the options I really don't think belong in doom such as mouselook, I never need to turn on.

Brilliant port.

[clarry]

Fabian, thank you for this awesome port. I don't think there is another port as portable as crispy-doom (or chocolate-doom) that still supports free mouse look/aim, hud and crosshair (laser) while utilizing the software renderer that gives the original 90s feel to the game. Last night I downloaded the source from github, compiled it on OpenBSD (no patching or autofools wizardry needed), and had a blast living through EP1 and half of EP2.

I don't know if it's a bug or feature but if I enable always run in the setup, then save or load the game, always run becomes always walk and I cannot run despite pressing the button. If always run is disabled, running will work as it should after saves and loads. Not a big deal for me though since I grew up running manual.. :-)

[plums]

clarry said:

I don't know if it's a bug or feature but if I enable always run in the setup, then save or load the game, always run becomes always walk and I cannot run despite pressing the button. If always run is disabled, running will work as it should after saves and loads. Not a big deal for me though since I grew up running manual.. :-)

I don't have this problem win32 precompiled build. Could be a bug. Are you using a joystick? Do you have a key bound to "Toggle always run" in the "More controls" section of the keyboard setup?

[clarry]

Toggle always run is bound to a key I don't have. I use the "speed on" key. Joystick is not enabled.

[plums]

Surely a bug then. In the meantime, try deleting the key bound to Toggle always run (press delete) or even assigning it to a key that does work for you.

[clarry]

I bound the toggle. If I press it, I can turn off always run and it'll work like traditional doom, with the normal run button allowing me to run. If I toggle it again on, it goes back into always walk mode and the normal run button does nothing.

[fabian]

clarry said:

Fabian, thank you for this awesome port. I don't think there is another port as portable as crispy-doom (or chocolate-doom) that still supports free mouse look/aim, hud and crosshair (laser) while utilizing the software renderer that gives the original 90s feel to the game. Last night I downloaded the source from github, compiled it on OpenBSD (no patching or autofools wizardry needed), and had a blast living through EP1 and half of EP2.

Dear Clarry, thank you for the feedback and the encouraging words. Although most of the portability goodness that you mention is already achieved by the Chocolate Doom code base, I am always glad to know that there are actually some people who find the Crispy Doom additions useful. :)

I don't know if it's a bug or feature but if I enable always run in the setup, then save or load the game, always run becomes always walk and I cannot run despite pressing the button. If always run is disabled, running will work as it should after saves and loads. Not a big deal for me though since I grew up running manual.. :-)

Needless to say that it *should* work. Could you send me the output of "grep _speed ~/.crispy-doom/default.cfg" and "grep autorun ~/.crispy-doom/crispy-doom.cfg", please?

[clarry]

I found the bug. Since enabling always run makes joybspeed greater than the size of the array which holds the button states, you're doing an out-of-bounds read in the xor part of the expression that determines whether speed should be on. On my system, this reads from savename, which gets set when I save or load. So joybuttons[joybspeed] gets a crazy value. Here's my fix:

$ diff -uNp src/doom/g_game.c.old src/doom/g_game.c
--- src/doom/g_game.c.old       Mon Jul  7 18:38:26 2014
+++ src/doom/g_game.c   Mon Jul  7 18:41:44 2014
@@ -349,10 +349,9 @@ void G_BuildTiccmd (ticcmd_t* cmd, int maketic) 
     // allowed an autorun effect
 
     // [crispy] when autorun is active, pressing the run key results in walking
-    speed = (key_speed >= NUMKEYS
-         || joybspeed >= MAX_JOY_BUTTONS)
-         ^ (gamekeydown[key_speed]
-         || joybuttons[joybspeed]);
+    speed = key_speed >= NUMKEYS || joybspeed >= MAX_JOY_BUTTONS;
+    speed ^= (key_speed < NUMKEYS && gamekeydown[key_speed])
+          || (joybspeed < MAX_JOY_BUTTONS && joybuttons[joybspeed]);
  
     forward = side = look = 0;