Crispy Doom 6.0 (Update: Mar 31, 2023)

[Jon]

I've just checked, and I can raise a PR against crispy doom from github, by going to my own fork of chocolate doom, clicking PRs, clicking new PR, then changing the base fork to crispy doom. It's a bit clunky but it works. I've got crispy added as a remote to my chocolate repo as per my earlier instructions.

[fraggle]

Cyanosis said:

I am using 1920x1080 with aspect ratio set to true and getting the game screen in a black box. What gives?

Chocolate Doom (and presumably Crispy too) only includes scaling code for a fixed set of screen sizes, and 1080p isn't one of them. The closest is 1280x960, so you end up with a border. Your best bet is to switch to a different video mode.

[LexiMax]

Linguica said:

My point is that if I try to fork Crispy Doom so I can make changes to it entirely separately from Chocolate Doom, Github just goes "lol you already have a fork of Chocolate Doom silly!" and that's it.

This is how I solved the problem.

1. Fork fabian's crispy-doom repository in github.
2. Clone the fork I just made to my local machine.
3. Add chocolate-doom as a remote to my local repository, then fetch from that remote.
3a. (Optional) Add fabian's crispy-doom as another remote to my local repository, so I don't have to use Github's web interface.

You will end up with a repository with both the latest chocolate doom and the latest crispy doom commits in it. The branches of each will be namespaced depending on what you named the two remotes, so you can tell the difference between the two.

In effect, this allows you to make branches for Chocolate Doom and Crispy Doom at the same time, depending on which commits you branch from, like so:

Chocolate: https://github.com/AlexMax/crispy-doom/tree/cmake
Crispy: https://github.com/AlexMax/crispy-doom/tree/cmake-crispy

The chocolate branch was forked from chocolate-doom's master, and to get the crispy branch I merely created a new branch from the chocolate branch and merged from crispy's master.

[3_nights]

100/10 best source port. When should we expect crispness support for Heretic/Hexen exe's, if ever?

[fabian]

3_nights said:

100/10 best source port.

Wow, thanks! :D

When should we expect crispness support for Heretic/Hexen exe's, if ever?

"If ever" is the crucial part of this question. Maybe if someone sends a pull request?

Honestly, I am about to drop the three non-Doom games with each Crispy Doom release. I have a high color rendering branch pending that already has them removed. The point is that I don't enjoy playing them that much and so I dont find the incentive to do the quadruple work and port every new feature to these games as well. Sorry, but that's the truth. :/

[3_nights]

fabian said:

Honestly, I am about to drop the three non-Doom games with each Crispy Doom release.

You're killin' me man. Thanks anyways though, still a boss source port. I guess I'll have to walk the lonely road myself.

[VGA]

Fabian, I just tested 3.0 on my win7 laptop and I set the resolution to 1440x900, fullscreen but it has black borders all around.

Also, what will the hicolor option achieve? Will it eliminate color banding like I saw at some glitchy Odamex beta some months ago?

Also, do you intend to achieve full MBF Dehacked support?

[Megamur]

3_nights said:

100/10 best source port.

I might have to agree with this. It provides an authentic DOS Doom experience with a few extra, non-intrusive trimmings that the original game really should have had in the first place.

How do you enable uncapped framerate? Is it a cheat code or a command-line switch or what? I can't seem to find it in the option menus.

And it would be great if future releases allowed you to assign mouse buttons to perform automap functions. I've really gotten used to ZDoom's ability to zoom the map in and out with the mousewheel. Even being able to set the thumb buttons to zoom in and out would be nice.

[chungy]

run crispy-doom-setup and look under crispness

[jmickle66666666]

What's the status/roadmap in terms of boom support? because at the moment the number of say, my own pwads that i can run in crispy doom is prettty low.

Some of the crispy features are kinda cool and it'd be fun to play through some more of my favourite maps with it.

[VGA]

jmickle66666666 said:

What's the status/roadmap in terms of boom support? because at the moment the number of say, my own pwads that i can run in crispy doom is prettty low.

Some of the crispy features are kinda cool and it'd be fun to play through some more of my favourite maps with it.

He told me this in another thread:

In order to add support for Boom linedefs etc. you'll have to modify and/or replace integral parts of the port, down to the thinkers level. Each line you modify there may result in throwing away the main achievments of the underlying code base, i.e. this strict compatibility, that's why I am so hesitant to step foot on this terrain. If you don't care about preserving these acheivements, fine, there you go.

So it seems it would be a bigger effort to add boom support to crispy doom than it was for doom retro.

[Megamur]

chungy said:

run crispy-doom-setup and look under crispness

It's not there. I must be running an outdated version. Where's the download for the binary of the newest version, anyway? The first page still links to v2.3.

Edit: Ah, there it is. I hope my savegames will still work.

[fabian]

VGA said:

Fabian, I just tested 3.0 on my win7 laptop and I set the resolution to 1440x900, fullscreen but it has black borders all around.

Sure, because 1440x900 isn't an integer multiple of 640x480.

Also, what will the hicolor option achieve? Will it eliminate color banding like I saw at some glitchy Odamex beta some months ago?

It will not add additional color levels, but the colors in the color levels will not have to get mapped to palette colors anymore.

Example:

Also, do you intend to achieve full MBF Dehacked support?

Do you mean the additional code pointers? Yes, maybe.

So it seems it would be a bigger effort to add boom support to crispy doom than it was for doom retro.

Well, the effort would be quite the same. Of course, I could just copy and paste the affected functions over from MBF or PrBoom+. But this is not how I maintain my code. That is, I sometimes did in the past e.g. for the code removing the Medusa effect. But I couldn't stand it, reverted this change and fixed it by learning to understand what the code does and merging the relevant lines back into the Vanilla functions.

To me, Crispy Doom is still just this:

$ git diff --shortstat upstream/master origin/master 
 159 files changed, 11256 insertions(+), 1426 deletions(-)

That is, a patch against Chocolate Doom. By replacing integral parts of the engine I would effectively change my code base and this has never been my intention.

Well, that being said, you will like to hear that I already started work on implementing support for generalized linedefs. They kind of work at the moment, but all the new actions that weren't already in Vanilla aren't implemented yet. However, I am not sure if I will ever invest more effort into this branch and eventually even merge it. Also, I don't think I will ever add support for all the other features that Boom added. I recommend PrBoom+ for that. :p

https://github.com/fabiangreffrath/crispy-doom/commits/genlin

[fabian]

Megamur said:

Edit: Ah, there it is. I hope my savegames will still work.

*gasp* Yes of course they will!

[ptoing]

Just played through some of Doom and noticed that the skull doors in E3M5 (left part of the map, doors leading to the shuriken like room) have the black and brown grid at the bottom visible. This should not be the case.

Esselfortium told me this is due to a bug in vanilla where if patches in the texture file have a negative y offset it counts it as 0. As a result in vanilla (and also indeed choco doom, as well as at least Eternity) it looks fine.

So the reason seems to be that Crispy fixes the y offset bug but does not make special cases for places in the iwads where it should.

[Megamur]

Indeed, my savegames worked just fine in the new version, and the uncapped framerate is wonderful. :)

Other suggestions for future versions:

-Make it optional that the screen dims while paused. Sometimes when I get an invulnerability sphere or radiation suit, I like to pause and look at the automap to plot out the fastest course before the power-up fades. The darkened pause screen makes it harder to read the map.

-Make the low health HUD blinking optional.

-An alternative Crispy HUD with the DoomGuy's face still on it. (Or failing that, some sort of on-screen indicator that lets you know which direction damage is coming from, like Doom 3.)

-Let the player set the percentages at which the HUD numbers change color, and if they want white or colored % icons, like in PrBoom-Plus.

-Is it possible to make it that crushed corpses retain the fixed blood colors? (For example, the pools of blood from crushed cacodemons being blue.) I know ZDoom can do that.

-A Crispness option that causes DSSLOP to play when monsters are crushed, like PSX DOOM.

Really looking forward to the hi-color version. :)

[ptoing]

Oh yeah, one thing I noticed. I think it would be good to NOT randomly mirror the explosions of barrels, because those have very distinct sideways shading on them and that flipping around just looks weird.

[fabian]

ptoing said:

Just played through some of Doom and noticed that the skull doors in E3M5 (left part of the map, doors leading to the shuriken like room) have the black and brown grid at the bottom visible. This should not be the case.

Indeed, this looks very strange. However, turns out this is not a rendering error. If you extract the texture from the IWAD with deutex, it really looks that strange.

Esselfortium told me this is due to a bug in vanilla where if patches in the texture file have a negative y offset it counts it as 0. As a result in vanilla (and also indeed choco doom, as well as at least Eternity) it looks fine.

Turns out this is only half-correct. There is no code in Doom that does "if the patch has a negative offset ignore it". The real reason is that in Crispy Doom even single-patched texture columns are pre-rendered into a cache, whereas in Vanilla these are directly read from the patch lump. This is to allow for single-patched transparent textures to be used as upper/lower textures and middle textures on one-sided walls and was introduced in Crispy 3.0.

When pre-rendering the columns into the cache, the patch offsets are taken into account. Whereas Vanilla, when drawing the column from the patch lump, ignores them. I have now added a check to ignore the patch offset when texture columns are pre-rendered into the cache that would normally get drawn directly from the lump.

Fixed in GIT, thank you!

So the reason seems to be that Crispy fixes the y offset bug but does not make special cases for places in the iwads where it should.

No. Doom Retro contains a hard-coded check that resets the patch offsets to 0, but I have never incorporated this.

[fabian]

Megamur said:

And it would be great if future releases allowed you to assign mouse buttons to perform automap functions. I've really gotten used to ZDoom's ability to zoom the map in and out with the mousewheel. Even being able to set the thumb buttons to zoom in and out would be nice.

This would risk demo desyncing! For example, at the start of MAP01 grab the chainsaw, hit TAB to enter the automap, scroll up, hit TAB again: you have selected the pistol. Now imagine someone recording a demo and changing weapons with the mouse while in the automap.

[fabian]

ptoing said:

Oh yeah, one thing I noticed. I think it would be good to NOT randomly mirror the explosions of barrels, because those have very distinct sideways shading on them and that flipping around just looks weird.

I was never sure about that, thanks for the advice! Fixed in GIT.

[fabian]

Megamur said:

-Make it optional that the screen dims while paused. Sometimes when I get an invulnerability sphere or radiation suit, I like to pause and look at the automap to plot out the fastest course before the power-up fades. The darkened pause screen makes it harder to read the map.

Hm, I agree the automap is really hard to read while paused. Will it help if I supporess the fading while the automap is active?

You know, I'd like to keep the number of options and switches at a bare minimum.

-Make the low health HUD blinking optional.

C'mon, is it really that distracting? I really want to avoid adding options for each micro-feature.

-An alternative Crispy HUD with the DoomGuy's face still on it. (Or failing that, some sort of on-screen indicator that lets you know which direction damage is coming from, like Doom 3.)

I already tested the Crispy HUD with Doomguy's face on it, but it always clashed with the weapon sprite and thus looked really crappy.

I have never played Doom 3, but I guess the borders of the screen are illuminated when hit from aside, right? And I would have to make these indicators optional, right? ;)

-Let the player set the percentages at which the HUD numbers change color, and if they want white or colored % icons, like in PrBoom-Plus.

At the moment it is just colors on or off. I would even agree to handle colored HUD text and the colored status bar separately. But this percentage threshold and gray '%' sign switcheritis that Boom-based ports offer is exemplary for the feature micro-management that I want to avoid for Crispy.

-Is it possible to make it that crushed corpses retain the fixed blood colors? (For example, the pools of blood from crushed cacodemons being blue.) I know ZDoom can do that.

Sounds like a nice idea, never thought about it.

-A Crispness option that causes DSSLOP to play when monsters are crushed, like PSX DOOM.

This does also sound like a nice idea, but I don't like the part with the additional option. ;)

Really looking forward to the hi-color version. :)

You'll have to wait (patience!) for Chocolate Doom to merge the sdl2-branch. I am not going to divert from Choco in something as crucial as the low-level rendering code.

Thank you very much for your suggestions, they are highly appreciated!

[Gez]

ptoing said:

Esselfortium told me this is due to a bug in vanilla where if patches in the texture file have a negative y offset it counts it as 0. As a result in vanilla (and also indeed choco doom, as well as at least Eternity) it looks fine.

So the reason seems to be that Crispy fixes the y offset bug but does not make special cases for places in the iwads where it should.

There are two different vertical offset bugs in vanilla.

[fabian]

Gez said:

There are two different vertical offset bugs in vanilla.

Hm, Crispy seems to look like Vanilla in both cases.

[Megamur]

fabian said:

Hm, I agree the automap is really hard to read while paused. Will it help if I supporess the fading while the automap is active?

That would be great.

C'mon, is it really that distracting? I really want to avoid adding options for each micro-feature.

It kind of is, and I like having my info on-screen at all times rather than popping in and out of view on an endless loop. I'd think DoomGuy's bloody face, the status bar numbers turning from orange to red, or just noticing your health counter only has one digit in it, are enough to alert you that you're almost dead.

I have never played Doom 3, but I guess the borders of the screen are illuminated when hit from aside, right? And I would have to make these indicators optional, right? ;)

Optimally, but I suppose they could just be inexorably bound to the minimal Crispy HUD. And Doom 3 displays these little red cones at the edges of the screen in the direction the damage came from. But this really isn't a major feature, just a little nicety.

At the moment it is just colors on or off. I would even agree to handle colored HUD text and the colored status bar separately. But this percentage threshold and gray '%' sign switcheritis that Boom-based ports offer is exemplary for the feature micro-management that I want to avoid for Crispy.

Well, if making new menus is the problem, I'd be fine with the micro-managing features being things that the player would have to edit in a CFG file. But if it's just too much work, so be it.

Thank you very much for your suggestions, they are highly appreciated!

Thank you, too. Nice to see someone who actually seems open to user feedback. :)

[Megamur]

Oh, and I don't know if it's been reported before, but sometimes when you take a screenshot, the HUD and/or gun model will briefly vanish. This is noticeable both in the resulting screenshots and real-time, in-game. It's slightly ruined a few caps I've taken already.

The framerate, resolution, detail level, whether it's windowed or not, and whether I'm using the regular HUD or the Crispy HUD--it doesn't seem to make any difference. I toggled the screenshots to save in PCX format, and ALT is my screenshot key, if that's important at all.

[Jon]

Megamur said:

Oh, and I don't know if it's been reported before, but sometimes when you take a screenshot, the HUD and/or gun model will briefly vanish. This is noticeable both in the resulting screenshots and real-time, in-game. It's slightly ruined a few caps I've taken already.

The framerate, resolution, detail level, whether it's windowed or not, and whether I'm using the regular HUD or the Crispy HUD--it doesn't seem to make any difference. I toggled the screenshots to save in PCX format, and ALT is my screenshot key, if that's important at all.

Are you running when you screenshot? I think this is a feature. Try lifting shift and seeing if that makes a difference.

[Megamur]

Huh, I guess it is. That's weird. I think it'd be better if it was enabled by a key you wouldn't press during normal gameplay, like ~.

[fabian]

Megamur said:

Huh, I guess it is. That's weird. I think it'd be better if it was enabled by a key you wouldn't press during normal gameplay, like ~.

Jon is right that it's a special feature of Crispy Doom to take a "clean" screenshot when the run-key is pressed.

However, you are also perfectly right that this feature should get its own dedicated key. As it is now, the feature is either completely overlooked or used by accident. Now, in current GIT, it has its own key and is thus much better discoverable by using the setup tool.

Thank you very much for this suggestion. I am still puzzled why I never had this idea myself.

[fabian]

VGA said:

Also, do you intend to achieve full MBF Dehacked support?

So , I just spent some time and added the missing code pointers in a separate GIT branch. And, just as I finished this, I realized how pointless it is. I mean, which map would require loading an MBF Dehacked patch without also relying on all the other MBF features as well? In the end, since I am not going to open the can of worms and implement Boom/MBF support partially, I am not going to implement it at all.

Crispy Doom is meant to be Chocolate Doom with Doom-compatible enhancements, not Boom. If you want Boom, I'd rather recommend playing the original. Sorry guys!

[fabian]

Megamur said:

That would be great.

Fixed in GIT. The automap is not shaded anymore when paused (it is still shaded in overlay mode, though)

It kind of is, and I like having my info on-screen at all times rather than popping in and out of view on an endless loop. I'd think DoomGuy's bloody face, the status bar numbers turning from orange to red, or just noticing your health counter only has one digit in it, are enough to alert you that you're almost dead.

Fixed in GIT. The health widget will not blink anymore. If it is disregarded as distracting, it has to go.

Optimally, but I suppose they could just be inexorably bound to the minimal Crispy HUD. And Doom 3 displays these little red cones at the edges of the screen in the direction the damage came from. But this really isn't a major feature, just a little nicety.

Maybe a little too far out of scope for Crispy, sorry.

Well, if making new menus is the problem, I'd be fine with the micro-managing features being things that the player would have to edit in a CFG file. But if it's just too much work, so be it.

It's not about making the menus, that's nearly trivial. It's about keeping track of all the config options and variables.

I don't like full configurability, I like reasonable defaults. If a feature is questionable but not crucial enough to justify its own menu entry, I'd rather kick it out (and have often done so in the past).

Thank you, too. Nice to see someone who actually seems open to user feedback. :)

It is also nice to see someone who actually plays my ports and provides user feedback at all. ;)

While we are at it:

- Assigning mouse buttons to zooming in the automap is currently discussed in the Chocolate Doom issue tracker. I think that this feature could also fit into Choco and should get implemented there first.
- Crushed corpses retaining their fixed blood colors was a gold suggestion. It fits perfectly and I still ask myself why I did not have this idea myself before.
- Playing dsslop when monsters are crushed. Hm, people are very sensitive regarding sounds and playing sounds where they don't belong is usually frowned upon. If you say it is actually played in the PSX port that may be a different thing, but i am still not sure. (One thing is sure: there won't be a switch for this! ;) )