Crispy Doom 6.0 (Update: Mar 31, 2023)

Eh, I don't know about that floating HUD design. The placement looks awful without the status bar it was intended for. There's too much empty space on the right side, and the big numbers look too high up because of the total ammo count being taller.

There's a reason that every floating HUD design has rearranged the status elements. I'd recommend ditching it for something else, like Doom 64's (perhaps too minimalist for some), Doom Retro's, PrBoom's, ZDoom's, etc. As it is right now, it just doesn't look good at all.

Sodaholic said:

Eh, I don't know about that floating HUD design. The placement looks awful without the status bar it was intended for. There's too much empty space on the right side, and the big numbers look too high up because of the total ammo count being taller.

Please, don't judge from screenshots alone. I am sure you would get used to the HUD rather quickly, because all the numbers are at the exact same position where you expect them from the status bar. It is not distracting at all.

fabian said:

Please, don't judge from screenshots alone. I am sure you would get used to the HUD rather quickly, because all the numbers are at the exact same position where you expect them from the status bar. It is not distracting at all.

Seconded, when I saw the first screenshot of the HUD I thought "um, well I didn't really need a HUD anyhow" but it took all of one run through MAP02 of Doom 2 to win me over.

I have just released Crispy Doom 1.1!

Highlights of this release are:
* Minimal HUD
* Colored Status Bar Numbers
* Colored Monster Blood
* Translucency
* Free Look
* Jumping
* Laser Pointer
* and many more...

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.1.zip

Please test extensively and have a lot of fun!

- Fabian

Looks good! Interesting choice to just disable jumping entirely for demos, but it makes sense.

I'm not complaining here, but how many more features are you planning to add to Crispy Doom? It's already got a lot more than I expected since the original announcement.

I have a few ideas and minor bugs, I'll put them on the tracker. In brief:
-vertical mouse aiming is way too sensitive with a high mouse sensitivity
-options screen could handle large mouse sensitivity values
-mirrored corpses like in Doom Retro would be cool
-more as I think of them...

plums said:

Looks good! Interesting choice to just disable jumping entirely for demos, but it makes sense.

This is also how it is done in PrBoom+.

I'm not complaining here, but how many more features are you planning to add to Crispy Doom? It's already got a lot more than I expected since the original announcement.

I am surprised myself! ;)

Honestly, I never intended Crispy Doom to get so many additional features and I always emphasized that in the beginning - buit it was so much fun to code on it. That said, most features are optional and even those that are not are disabled in demo recording and playback. So, with all additional featues turned off, Crispy Doom should still play and feel like "the real thing" [tm].

As I mentioned earlier, I have true color rendering in the queue, but currently my attempts to adapt screen scaling fail on the SDL side. Furthermore, I am dreaming of implementing a "real laser pointer", i.e. not a colored pixel in the view, but an actual sprite that gets projected on the opposing wall.

Apart from that, I think Crispy Doom has pretty much achieved feature saturation. That flipping corpse thing that you suggested in the bug tracker is neat, but first it would require adding another field to mobj_t (or adding an entire new struct just for that single new field) and second it is one of the most characteristic features of Doom Retro and I don't want to "steal" it for Crispy. I'll have to sleep a night or two over it...

I have a few ideas and minor bugs, I'll put them on the tracker. In brief:
-vertical mouse aiming is way too sensitive with a high mouse sensitivity
-options screen could handle large mouse sensitivity values
-mirrored corpses like in Doom Retro would be cool
-more as I think of them...

I've seen them, thank you very much!

fabian said:

I am surprised myself! ;)

Honestly, I never intended Crispy Doom to get so many additional features and I always emphasized that in the beginning - buit it was so much fun to code on it. That said, most features are optional and even those that are not are disabled in demo recording and playback. So, with all additional featues turned off, Crispy Doom should still play and feel like "the real thing" [tm].

I do like most of the features, and I still think it feels true to the original idea of "Doom with a bit less chunky pixels". That said I really enjoy being able to jump in Doom, even though it can sequence break or get you stuck a lot, using it carefully is fun and convenient.

That flipping corpse thing that you suggested in the bug tracker is neat, but first it would require adding another field to mobj_t (or adding an entire new struct just for that single new field) and second it is one of the most characteristic features of Doom Retro and I don't want to "steal" it for Crispy. I'll have to sleep a night or two over it...

That's a good point, I didn't consider that it is quite a unique feature to Doom Retro. Though, I think Doom Retro has lots of other things about it that make it different from other ports. As far as technical concerns, well, that's not something I have in mind when suggesting features ;) but I understand if it's something you wouldn't want to add based on code changes required.

plums said:

That's a good point, I didn't consider that it is quite a unique feature to Doom Retro. Though, I think Doom Retro has lots of other things about it that make it different from other ports.

As you may have seen, I have just implemented it but used a *completely different* approach.

As far as technical concerns, well, that's not something I have in mind when suggesting features ;)

You shouldn't, please keep on suggesting! So far your suggestions have all been very inspiring to me.

fabian said:

As you may have seen, I have just implemented it but used a *completely different* approach.

Haha, that's pretty clever! Well done.

One thing I just noticed now is that using mouselook with the GIT snapshot update actually changes your aim, as in Heretic/Hexen. When recording a demo, it goes back to the PrBoom+ style of changing your viewpoint but not affecting aim. (Smoothness remains the same either way.) I don't know if this is intentional, but I do like it this way.

Woo, that was fast! I just released Crispy Doom 1.2!

Crispy Doom 1.2 is mostly a bug fix release to fix the jerky mouse look in Crispy Doom 1.1. If you were unsatisfied with the mouse look performance of Crispy Doom 1.1 it is highly recommended to upgrade to Crispy Doom 1.2!

Features:
* Unjerkify mouse look.
** In Crispy Doom 1.1 vertical mouse movement changed the look variable which decided how the actual player->lookdir variable will be changed in the next game tic. However, the look variable is intended for keyboard use and changes the lookdir in rather coarse steps. The code has been changed to now act directly on the player->lookdir variable which provides for a much smoother mouse look.
** Mouse sensitivity selection is moved into a separate sub-menu of the Options menu.
** Allow to set separate values for horizontal and vertical mouse sensitivity in both the Options menu and in crispy-doom-setup.
** Increase mouse sensitivity thermometer range up to 20.
** Fix a crash in the Options menu when mouse sensitivity exceeds the maximum value. Instead, allow to exceed the thermometer range and print values next to it.
** Fix slopes for bullets and missiles that would not have hit a target anyway. This means that missed shots will now go into the actual vertical direction looked into. However, auto-aim will still work and guide shots to their aim. This feature is only enabled in single-player games (though probably harmless).

* Monster death sprites and corpses are now flipped randomly. While the idea is stolen from Doom Retro, the implementation is completely different. The flipping decision is based on the value of thing->health, which is randomized in Doom, since all damage done by weapons is already randomized. Once a monster is dead (i.e. thing->flags & MF_CORPSE), this value remains constant. Although probably harmless, this feature is also only available in single-player games.
* Fix different view frames for normal fullscreen mode and Crispy HUD.
* Fix a crash when attempting to test settings from crispy-doom-setup, merged from Chocolate Doom.
* Fix "fast doors make two closing sounds" and "fast doors reopening with wrong sound" engine bugs.

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.2.zip

Please test extensively and have a lot of fun!

- Fabian

Yay, more stuff!

fabian said:

** Fix slopes for bullets and missiles that would not have hit a target anyway. This means that missed shots will now go into the actual vertical direction looked into. However, auto-aim will still work and guide shots to their aim. This feature is only enabled in single-player games (though probably harmless).

Absolutely not harmless for MP or demos, since you could use it to hit a target that is too far away or too obscured for auto-aim to lock on to, and not on the same vertical level as you are. The obvious example is Doom 2 MAP30, where if you aim down slightly from the top of the lift you can hit the BossBrain with rockets. But you went with a conservative default already, so no problem.

* Monster death sprites and corpses are now flipped randomly. While the idea is stolen from Doom Retro, the implementation is completely different. The flipping decision is based on the value of thing->health, which is randomized in Doom, since all damage done by weapons is already randomized. Once a monster is dead (i.e. thing->flags & MF_CORPSE), this value remains constant. Although probably harmless, this feature is also only available in single-player games.

Hm, that one should be fine, but you would know more about it than I would.

(edit: As clever as that method for choosing whether to flip corpses is, it does have one flaw. Some weapons, notably the fists and chainsaw, will always deal damage in even numbers, meaning enemies killed with these weapons will always fall to the same side. This is easy enough to verify on MAP01 of Doom 2 if you grab the chainsaw and saw your way through the level.)

Anyhow speaking of demos and safe features, I just recorded a demo with the GIT build of Crispy 1.1 from the bug tracker, and it's desyncing. I'm 99% sure that it's not Crispy Doom at fault, since it plays back with the same desync in PrBoom+, Chocolate Doom, and Crispy Doom, and I know demo desyncs happen sometimes. But I thought I'd mention it anyways.

Anyhow will check this out more thoroughly soon, for now I'll say that having coloured blood and now flipped corpses in a vanilla-ish port is really great, I think it adds a lot to the visual presentation.

plums said:

The obvious example is Doom 2 MAP30, where if you aim down slightly from the top of the lift you can hit the BossBrain with rockets.

o_O Indeed! This is so obvious that I didn't even think about it.

Anyway, my motivation was that I considered it stupid to be able to look at the roof but still be restricted to shoot at the wall at the same time. It somehow felt unnatural to me.

plums said:

Some weapons, notably the fists and chainsaw, will always deal damage in even numbers, meaning enemies killed with these weapons will always fall to the same side.

Hm, maybe I will have to additionally mangle x- and y-coordinates into the decision somehow.

fabian said:

Anyway, my motivation was that I considered it stupid to be able to look at the roof but still be restricted to shoot at the wall at the same time. It somehow felt unnatural to me.

It has another consequence, in MAP16. In the building just south of your starting point, there are two small shootable niches in the wall (WOODGARG eyes to the north, and FIREMAG3 hole to the east). Without manual aiming, you need to use the red torch to raise a wall, then activate the "tables" to lower them like lift, climb on them, and wait to be back up to have the correct height to shoot them. (There's two tables, one below the wall you've raised with the torch, the other holding four shotgun cells.)

With manual vertical aiming, you can skip that puzzle-like part and just shoot at the targets directly.

(It's actually possible to skip that puzzle by exploiting the SSG's vertical spread, but then you have to waste a lot of shells and since it can take several tries, you're not really saving any time compared to doing the puzzle.)

fabian said:

Hm, maybe I will have to additionally mangle x- and y-coordinates into the decision somehow.

Don't. Contrarily to hit points after death, the X and Y coordinates are not fixed. Corpses slide around (in some circumstances, like falling down stairs, they can be sliding for a long while) and having that factor in their mirroring could make sliding corpses dance. Which would be funny, but would definitely look like a bug.

Instead, you may try to divide the hit points by two and then look at whether the result is odd or even. You should still get an even distribution (e.g., -5 and -4 will both divide to -2, -3 and -2 will both divide to -1). The problem then comes from whether there are weapons that only deal damage by multiples of 4...

The setup program doesn't allow setting inverse mouse, but it works if I set mouse_acceleration_y to a negative value from the config file..

Jump height is good, allowing player to get on top of the 64 crates.

Idea for the crosshair/laser pointer highlight: white when pointing nothing.. green when pointing at a healthy monster (100% - 67%), yellow when pointing at a medium damaged monster (66% - 34%), red when pointing at an almost dead monster (33% - 1%).

Gez said:

It has another consequence

Hm, now this is starting to scare me. Maybe I should separate the free look from the free aim options eventually.

you may try to divide the hit points by two and then look at whether the result is odd or even. You should still get an even distribution (e.g., -5 and -4 will both divide to -2, -3 and -2 will both divide to -1).

I could as well check the second LSB via (thing->health & 2), right? Thanks for that hint, I will definitely try it!

Jimi said:

The setup program doesn't allow setting inverse mouse, but it works if I set mouse_acceleration_y to a negative value from the config file..

I wouldn't have guessed someone actually plays with inverse mouse. :p It should also work if you set mouse_sensitivity_y to a negative value, does it?

Jump height is good, allowing player to get on top of the 64 crates.

I have just ported over the jumping code from Hexen. Good to know it fits well, but I haven't decided over the height myself. ;)

Idea for the crosshair/laser pointer highlight: white when pointing nothing.. green when pointing at a healthy monster (100% - 67%), yellow when pointing at a medium damaged monster (66% - 34%), red when pointing at an almost dead monster (33% - 1%).

Hm, wouldn't that tell a bit much about your opponent then? However, my original plan is for the laser pointer to become a real projection of a light point at the opposing wall, but I will have to introduce an extra sprite for that and thus I am hesitating to implement it.

fabian said:

Hm, now this is starting to scare me. Maybe I should separate the free look from the free aim options eventually.

I think most people that play with vertical aiming know/accept that they can do things that the original Doom engine didn't allow. Jumping is no different, really. But yes, separating aim from freelook might be desired by some people.

I could as well check the second LSB via (thing->health & 2), right? Thanks for that hint, I will definitely try it!

I actually thought that doing a binary AND with 130 (?) might be good, since that would also add some randomness to hits from berserk punches (multiples of 20, up to 200) and direct BFG blasts (multiples of 100).

BTW any reason the Cyberdemon (and only the Cyberdemon) is excluded from flipped deaths?

I have just ported over the jumping code from Hexen. Good to know it fits well, but I haven't decided over the height myself. ;)

I feel like 64 is too high personally. It was less in Crispy 1.1 right? Perhaps I'm just used to ZDoom's height.

Off to add some ideas to the issue tracker, playing last night gave me some ideas.

plums said:

BTW any reason the Cyberdemon (and only the Cyberdemon) is excluded from flipped deaths?

Asymmetrical monster design. It'd be odd if the cyber leg changed side when it died.

To a lesser extent, the zombies (and Wolfenstein dude) could be excluded from flipped death too, but the weapon changing side as they fall is less odd than a cyberleg changing side.

Gez said:

To a lesser extent, the zombies (and Wolfenstein dude) could be excluded from flipped death too, but the weapon changing side as they fall is less odd than a cyberleg changing side.

They already (mostly) flip sides due to mirroring in their normal sprite set.

I do wonder if, instead of programming an exception for the cyberdemon, it might be a better idea to only do the death mirroring if the monster has at least one manually mirrored sprite? This would add the chaingunner and the SS to the exceptions, but it would provide reasonable assurance that such oddities won't occur in mods that change the sprites.

mouse_sensitivity_y with a negative value disabled the up/down looking.

"64 + few units" tall jumps makes it less necessary to use noclip... so it feels more useful between 24 unit steps and noclip.

I saw something strange on the weapon graphics when the border is used, there's odd out of place pixels showing up around them when you're standing still, but only with the border. Otherwise this is a nifty little package that's nice for what it is, especially the subtle blood color integration, I couldn't do that outside of a ZDoom based port.

I can confirm what Cyanosis sees. Bug added to tracker.

plums said:

I actually thought that doing a binary AND with 130 (?) might be good, since that would also add some randomness to hits from berserk punches (multiples of 20, up to 200) and direct BFG blasts (multiples of 100).

I still have to find the one adequate bit mask that provides an even distribution for all kinds of weapon damage.

I feel like 64 is too high personally. It was less in Crispy 1.1 right? Perhaps I'm just used to ZDoom's height.

Actually, you do not directly adjust the height of the jump. Instead, you add vertical momentum to the player. In Crispy Doom 1.2 that is 9*FRACUNIT, which is the same value as in Crispy Doom 1.1, Chocolate Hexen and ZDoom. ;)

Jimi said:

mouse_sensitivity_y with a negative value disabled the up/down looking.

There is now a separate config item for "invert mouse".

Cyanosis said:

I saw something strange on the weapon graphics when the border is used, there's odd out of place pixels showing up around them when you're standing still, but only with the border.

Wow, it is incredible what you guys can see! I have literally stared at the weapon sprite for hours already and never noticed. Anyway, I am not sure what this could be and how it could be fixed.

fabian said:

Actually, you do not directly adjust the height of the jump. Instead, you add vertical momentum to the player. In Crispy Doom 1.2 that is 9*FRACUNIT, which is the same value as in Crispy Doom 1.1, Chocolate Hexen and ZDoom. ;)

ZDoom actually uses 8 for the Doom, Heretic, Strife and Chex players. The three Hexen classes do use 9. (Also, Heretic's chickens have 1, and Hexen's pigs have 6.)

Gez said:

ZDoom actually uses 8 for the Doom, Heretic, Strife and Chex players. The three Hexen classes do use 9. (Also, Heretic's chickens have 1, and Hexen's pigs have 6.)

Gosh, then I looked it up in the wrong place. Sorry! Should I change this to 8 or are you people comfortable with 9?

While I would prefer 8 for consistency (I think most Doom ports that have jumping don't let you jump up 64 units), I don't feel too strongly either way, and am fine with 9.

You could always make jumping speed a user variable and let people choose anything from 0 (disabling jumping altogether) to 16 or 32 or whatever arbitrary max value you want.

tbh I'd rather a fixed jump height, even one that I personally thought was "too high," than a variable one. If one were to design a map that accommodates jumping it would be better to have a known jumping height, even if there's a bit of variance between ports.

XCOPY said:

freelook should work like glboom+ - you are able to aim up and down, but you cannot lead your rockets, plasma shots, bfg shots nor hitscanner shots, working just as an extension of your z view. By the way,

Free aiming will probably be optional in the next release.

BFG aimed to the ground is kinda op. :)

Try with a rocket. :p

I'm afraid the jump and freelook in it's current form might break/desync the game for chocolate-doom users.

I am not exactly sure what you mean here. Jumping is a disruptive change anyway. Currently I am just torn between momz = 8 as in Strife and ZDoom for non-Hexen games and momz = 9 as in Hexen.

If by "break the game" you mean demo desyncing, that has been taken care of. All of the disruptive changes are disabled during demo recording and playback.