Crispy Doom 6.0 (Update: Mar 31, 2023)

plums said:

Is there a way to turn these off? I kind of like flying blind in maps, it feels more authentic. Especially the stats in the automap, it can really give parts of the level away sometimes.

Yes, I am going to add a config key for them. (As it seems, Chocolate Doom gracefully ignores config keys it doesn't know, so it is still possible to share config files between both ports).

plums said:

A useful idea to me would be to save screenshots in a format besides PCX. Even BMP would be better. Is this something that belongs in Crispy Doom, or should it be requested in Chocolate Doom?

This is definitely a good idea! I think it would even fit into Choco. I'll take care of that.

plums said:

e: Also being able to reassign the screenshot key from F1 to PrintScreen or something else would be nice, though not particularly essential. Nevermind, it seems like it uses the same key as Help, but trying to assign to PrintScreen doesn't work in the setup program.

I believe it is hard-coded to "-devparm" and F1.

plums said:

edit: also you are probably aware, but just in case, all these features appear to be Doom-only:

I know Doom is the focus of the Crispy programs and so if you can't/don't want to implement them in other games, it's fine.

Yes, my primary focus is Doom. I just pulled in the other ports as well, because my changes to the rendering code would have destroyed them else and so I decided to rather fix them. Maybe I'll add some of the enhancements to the other ports as well, let's see...

plums said:

One more thing, would you prefer me to file this stuff on the bug tracker (instead of or in addition to here), now that you have one separate from Chocolate Doom?

Yes, please use the tracker, or else I will literally lose track of all your useful comments and suggestions. Let's turn the tracker into a giant wishlist. :)

Great, I'll put some of those things into the tracker tomorrow.

fabian, I do believe your link to the source on github is a touch borked by that trailing period. :c

Other than that, you've taken my choco-plus branch and proceeded along logical development lines. I look forward to seeing where you go!

- Gio

PS: All choco-plus did was change the various limits of all four games to Doom-plus standards, so I never made much effort to announce it. I eventually planned to upgrade the Doom side of things with the limited mouselook found in Heretic.. I suppose you could consider that a feature request on my part. ^^

Giomancer said:

fabian, I do believe your link to the source on github is a touch borked by that trailing period. :c

Indeed, fixed now. Thank you!

Other than that, you've taken my choco-plus branch and proceeded along logical development lines. I look forward to seeing where you go!

Honestly, I have never heard of your choco-plus branch. But I found the desire to raise the static limits in Chocolate-Doom quite obvious and it even becomes necessary when you raise the screen resolution.

PS: All choco-plus did was change the various limits of all four games to Doom-plus standards, so I never made much effort to announce it. I eventually planned to upgrade the Doom side of things with the limited mouselook found in Heretic.. I suppose you could consider that a feature request on my part. ^^

Free look (optional) is already working in my player2 branch (which overcomes the limitations of the original player_t struct):
https://github.com/fabiangreffrath/crispy-doom/tree/player2

I have merged the necessary changes from the Chocolate Hexen source code and also fixed sky stretching. Mouse look (again optional) does also work, but is currently a bit jerky due to mouse threshold and acceleration, I guess. I believe I need to implement separate mouse settings for horizontal and vertical movement. I think I am going to merge that branch rather soonish.

Edit: BTW, Chocolate Doom is now able to save screenshots in PNG format (which will be the default on Crispy) and there is now also a dedicated key for taking screenshots. In further news, automap statistics and the "A secret is revealed!" message are now optional and I have merged the code from Chocolate Hexen to allow for jumping (though disabled by default, of course).

Can you suggest a few WADs to test on Crispy Doom, beside Vanilla WADs (AV, HR, MM, Eternal, etc.) ?

For example limit-removing stuff...

soner du said:

Can you suggest a few WADs to test on Crispy Doom, beside Vanilla WADs (AV, HR, MM, Eternal, etc.) ?

Honestly, I only play vanilla-compatible PWADs myself. The limits were raised in Crispy Doom to compensate for the additional visplanes that become visible because of the raised screen resolution.

soner du said:

For example limit-removing stuff...

No Rest For The Living breaks the vanilla limits and is a great set of levels. Plus, Crispy Doom has specific support for it, e.g. level names, music, level transitions, intermission screens, etc. It could use some more testing, so if you can get your hands on it...

Wow, more features, great! I kind of forgot to add stuff to the tracker, sorry, looks like everything has been done anyhow though. Also you caught the one bug I did file on the tracker, so good.

At this point the only thing I could really hope for is for OPL playback to be fixed in Chocolate Doom, don't know if it's being worked on right now or if that's something you want to look at...
https://github.com/chocolate-doom/chocolate-doom/issues/352

fabian said:

Honestly, I have never heard of your choco-plus branch.

*laughs*
I would have been shocked if you had! I had detatched the github repo from chocolate-doom (making it no longer tracked as a fork) and it was only 'released' to those on IRC at the time.

fabian said:

Free look (optional) is already working in my player2 branch (which overcomes the limitations of the original player_t struct):
https://github.com/fabiangreffrath/crispy-doom/tree/player2

Oh, that is excellent news indeed.

- Gio

I have just released a new beta version of Crispy Doom 1.1!

One of the new features is that Crispy Doom now has its own setup tool. To summarize the new features affecting the actual game, let me show you a screenshot of crispy-setup:



The package is available for download here:
http://greffrath.com/~fabian/crispy-doom_1.1-beta2.zip

Sorry, only Doom is included this time and will be from now on. The other games have really fallen behind in terms of development and haven't seen any significant changes since 1.1-beta1.

Have a lot of fun!

Hey, looks great again.

fabian said:

Sorry, only Doom is included this time and will be from now on. The other games have really fallen behind in terms of development and haven't seen any significant changes since 1.1-beta1.

Ah, too bad, but understandable. Thanks for including them in the 1.0 release anyhow.

Mouse configuration looks a bit broken ?

soner du said:

Mouse configuration looks a bit broken ?

Hm, indeed, but only on Windows. Everything looks fine on Linux...

Edit: Fixed in GIT, please find a fixed crispy-setup.exe here:
http://greffrath.com/~fabian/crispy-setup.exe

Tank you, everything looks fine now !

Say, do you think you could incorporate separate blood types for some of the monsters? (Dark Green for Barons/Knights, Blue for Cacodemons, Transparent for Spectres, no blood for Lost Souls) It would be awesome to have it in a Chocolate Doom fork.

v0.99-v1.2-style random pitch variations for sound effects would be neat too, if possible.

Patch93 said:

Say, do you think you could incorporate separate blood types for some of the monsters? (Dark Green for Barons/Knights, Blue for Cacodemons, Transparent for Spectres, no blood for Lost Souls) It would be awesome to have it in a Chocolate Doom fork.

That's a neat idea, but I don't want to introduce stupid look-up tables (red -> green, red -> blue, etc.) for the palette-based renderer. However, I am currently working on a true-color port that made good progress, it is currently only blocked by Choco's scaling algorithm but runs smootly at 640x400:

https://github.com/fabiangreffrath/crispy-doom/tree/hicol2

Once this is ready, I can throw colors around like there is no tomorrow. ;)

v0.99-v1.2-style random pitch variations for sound effects would be neat too, if possible.

Never heard of that, could you elaborate a bit, please?

It's a feature that was present in versions of Vanilla Doom before v1.4 and was removed in said version. Here's an example of what I'm talking about.

https://www.youtube.com/watch?v=3UBFrbBnU1M

It basically plays the game's sound effects in random playback rates which adds a certain touch to the game which I thought was pretty cool. Many source ports such as PrBoom+ and ZDoom have implemented it back in.

Also, may I suggest refining that full screen HUD a bit?

Also, the removal was apparently accidental, not deliberate. A bug was introduced which made it stop working.

The recent official console ports (Xbox 360, PS3) have it restored. I'm not sure about BFG Edition on PCs, though.

IIRC the reason it was taken out was actually a change in the DMX sound library and not something id did, I think?

Patch93 said:

It basically plays the game's sound effects in random playback rates which adds a certain touch to the game which I thought was pretty cool. Many source ports such as PrBoom+ and ZDoom have implemented it back in.

Hm, sounds complicated. And I am not even sure I can actually hear a difference. I'll have a look at PrBoom+'s implementation...

Also, may I suggest refining that full screen HUD a bit?

What exactly do you mean, what do you want refined? I have kept it that simple on purpose, so it fits perfectly into the standard HUD that appears in the automap.

The Crispy HUD has fast become my favourite HUD in any port. All the numbers are where you expect them to be, if you're used to the status bar, but you get the benefit of extra visibility.

fabian said:

Hm, sounds complicated. And I am not even sure I can actually hear a difference. I'll have a look at PrBoom+'s implementation...

It's really noticeable (to me at least) if you're somewhere where you hear the same sound frequently. Like MAP31, kill a bunch of SS with the chaingun and it's very obvious that their death sound varies in pitch.

Patch93 said:

Dark Green for Barons/Knights, Blue for Cacodemons, Transparent for Spectres, no blood for Lost Souls)

Spectres now bleed spectre blood, Lost Souls now bleed Puffs.

Actually colorizing the blood is a bit more complicated than expected, though, because the routine that draws the sprite does not know anything about the type of object the sprite belongs to. Will be tricky to implement without breaking savegame compatibility.

Only reason Chocolate Doom doesn't already have pitched sound support is that it's difficult to implement using SDL_mixer. There's an open bug for it - I think it's technically needed for Heretic.

fabian said:

What exactly do you mean, what do you want refined? I have kept it that simple on purpose, so it fits perfectly into the standard HUD that appears in the automap.

It's just that it looks odd without the "Ammo", "Health", "Armor", etc labels beneath the percentages. I think using the stock text to replace them would work fine. Also the statbar face is missing. Adding that stuff would actually make it fit better with the normal HUD that appears on the automap.

fraggle said:

Only reason Chocolate Doom doesn't already have pitched sound support is that it's difficult to implement using SDL_mixer. There's an open bug for it - I think it's technically needed for Heretic.

Don't PrBoom and ZDoom use SDL_mixer too though?

ZDoom uses FMOD Ex, not SDL_Mixer.

fabian said:

And I am not even sure I can actually hear a difference.

Really? I find it quite noticeable.

fraggle said:

Only reason Chocolate Doom doesn't already have pitched sound support is that it's difficult to implement using SDL_mixer.

Strange, since all it should consist of is changing the sample's playback rate.

Gez said:

ZDoom uses FMOD Ex, not SDL_Mixer.

*checks* Oh wait, yes you're right, my bad.

Sodaholic said:

Really? I find it quite noticeable.
Strange, since all it should consist of is changing the sample's playback rate.

That isn't as easy as it sounds.

Sound outputs at a constant rate. Suppose we're running at 44100Hz; if we have a 11025Hz sound effect, that needs to be converted to the higher frequency. For pitched sounds, every sound effect needs to be a different frequency, so it needs an on-the-fly frequency conversion.

fraggle said:

For pitched sounds, every sound effect needs to be a different frequency, so it needs an on-the-fly frequency conversion.

Isn't it already the case, though? The DMX sound format has a field for the sample rate, and some of the sounds in Doom II (and in Strife) use a different rate than 11025 Hz. I haven't tested vanilla's behavior with sounds that have a non-standard sample rate (something that isn't 11025 Hz or a multiple), but the sound format specs by themselves do not prevent having any random value one wants.

I believe fraggle is referring to the need to have multiple instances of the source sample in order to play them at different frequencies simultaneously.

Patch93 said:

It's just that it looks odd without the "Ammo", "Health", "Armor", etc labels beneath the percentages. I think using the stock text to replace them would work fine.

They are part of the background, i.e. that part of the status bar that I wanted to get rid of. Replacing the labels with stock text would be somehow redundant. However, the next rlease of Crispy Doom will have this:

Also the statbar face is missing. Adding that stuff would actually make it fit better with the normal HUD that appears on the automap.

I tried the HUD with and without the face and decided that the face is actually distracting in this specific case. It would be floating over parts of the weapon and would look especially awkward with mods that change the face pictures, e.g. Eternal Doom. If you want the labels and the face, you will have to switch to the full status bar.