Crispy Doom 6.0 (Update: Mar 31, 2023)

[duh]

[fabian]

XCOPY said:

forgot to say i was talking about multiplayer, lol.

Multiplayer is treated equally to demo recording/playback: Potentially breaking changes are disbaled.

[plums]

fabian said:

Currently I am just torn between momz = 8 as in Strife and ZDoom for non-Hexen games and momz = 9 as in Hexen.

Might as well just leave it at 9 for now I guess, unless you personally would prefer 8.

[fabian]

plums said:

Might as well just leave it at 9 for now I guess, unless you personally would prefer 8.

I don't, that's the point. For Doom, 8 is just as arbitrary a value as 9, because there simply is no true or original value for Doom. I chose 9, because I knew it from Hexen - forgetting about Strife which uses 8 and furthermore uses a different algorithm to determine when the next jump is allowed after a previous jump.

Just as Jimi said, if jumping is allowed then it should be useful! You are cheating - well, controling the game in a way that it was not intended for, that is - if you are jumping, anyway. But then it should at least bring you up these crates, so you don't have to type IDCLIP again. ;)

[fabian]

fabian said:

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

My current approach is the following:

    if (singleplayer && thing->type != MT_CYBORG &&
        thing->flags & MF_CORPSE &&
        ((thing->health / 100) & 1 || // BFG main projectile
         (thing->health /  20) & 1 || // berserk, rocket launcher
          thing->health & 2))         // fist, chainsaw
    {
        flip = true;
    }

That is, I check if health is an odd or even multiple of 100 to cover damage done b the BFG main projectile, then I check if health is a odd or even multiple of 20 to cover berserk punches and direct rocket hits and finally if its an odd or even multiple of 2 to cover fist and chainsaw damage.

Another question: When using free look, would you prefer to center the view when you fall down a high ledge? "High" meaning high enough to trigger the "oof!" sound, this includes the ledge at the very start of MAP01 and even jumping. IMHO, I find it confusing to e.g. fall into a pit full of monsters while looking at the roof and still find myself looking upwards. PrBoom+, by the way, does not center the view anytime, not even when teleporting or dying.

[plums]

fabian said:

That is, I check if health is an odd or even multiple of 100 to cover damage done b the BFG main projectile, then I check if health is a odd or even multiple of 20 to cover berserk punches and direct rocket hits and finally if its an odd or even multiple of 2 to cover fist and chainsaw damage.

Does that factor in the target's initial health?

If not, a very hacky solution I thought up, since corpse flipping is SP-only, is to randomly do one extra damage to any unit that dies and then just check odd/even health. Pretty ugly idea :p
edit: Also, what about checking some other value? Angle? Thing number?

Another question: When using free look, would you prefer to center the view when you fall down a high ledge? "High" meaning high enough to trigger the "oof!" sound, this includes the ledge at the very start of MAP01 and even jumping. IMHO, I find it confusing to e.g. fall into a pit full of monsters while looking at the roof and still find myself looking upwards. PrBoom+, by the way, does not center the view anytime, not even when teleporting or dying.

Hmm, Heretic and Hexen do it this way, though they only have keyboard look. I don't know how I feel about it, in Crispy Doom I have a mouse button assigned to Free look and I find it easy enough to centre the view that way when I need to. Maybe as long as the Free look button is not being held down, then auto-centring when you oof is ok?

If "permanent mouse look" is enabled, I think the view should never centre automatically.

Which method do you use for looking up and down?


BTW I checked max jump height in a few other ports, Eternity is 56 and Doomsday is 64. So already there's no consensus. As I said before I don't care too much either way, and other people seem to prefer 64, so leaving it at 64 is probably good.

[fabian]

plums said:

Does that factor in the target's initial health?

No, only its health after death.

If not, a very hacky solution I thought up, since corpse flipping is SP-only, is to randomly do one extra damage to any unit that dies and then just check odd/even health. Pretty ugly idea :p
edit: Also, what about checking some other value? Angle? Thing number?

Hm, if (gametic&1) would be subtracted from health at the time of death, that could lead to an even distribution. I think that could even be considered demo/netgame save - the thing is dead anyway. Angle might be a valid candidate, too, as long as it remains constant once the thing has died. Not sure about thing numbers, though, are they evenly distributed?

If "permanent mouse look" is enabled, I think the view should never centre automatically.

That's an alternative I already considered: Do not center view after falling if (a) permanent mouse look is enabled or (b) the mouse look button is held down. That sounds good to me.

After teleporting, though, I think the view should be centered in any case.

BTW I checked max jump height in a few other ports, Eternity is 56 and Doomsday is 64. So already there's no consensus. As I said before I don't care too much either way, and other people seem to prefer 64, so leaving it at 64 is probably good.

Fine, so Crispy Doom plays in the Doomsday league. :) Is jump height in Crispy exactly 64 or 64+X?

[plums]

fabian said:

Is jump height in Crispy exactly 64 or 64+X?

I believe it's exactly 69 units high. I didn't test the other ports to more than multiples of 8, maybe I will later.

Doomsday and PrBoom+ are also 69, no surprise
ZDoom and Eternity are 60. Eternity is a unique case, it seems you can't gain forward momentum while in the air, making jumps above 58 units high quite difficult.

[TwinBeast]

I just tried.. player can jump up to a 69 unit tall obstacle, when standing right next to it. It's probably a good idea to have the few extra units, so jumping over 64 units obstacles isn't too difficult.

Auto centering for view could be an option?

The fullscreen HUD numbers could be closer to the bottom.

And the fullscreen HUD could be the next viewsize after the statbar.. and the no HUD would be the last viewsize.

[fabian]

Jimi said:

I just tried.. player can jump up to a 69 unit tall obstacle, when standing right next to it. It's probably a good idea to have the few extra units, so jumping over 64 units obstacles isn't too difficult.

Then it will stay like this.

I am not surprised that jumping height is the same in PrBoom+, the patch was from me. ;)

Auto centering for view could be an option?

There are already more options than I prefer. I am in favor of sensible defaults. And I think not centering view when falling if you are in full control of your view yourself (i.e. mouselook is active) is a good compromise.

The fullscreen HUD numbers could be closer to the bottom.

Nope, I want them at the exact same position as on the status bar.

And the fullscreen HUD could be the next viewsize after the statbar.. and the no HUD would be the last viewsize.

That would contradict common practice with every other Doom port that I know of.

[plums]

fabian said:

I am not surprised that jumping height is the same in PrBoom+, the patch was from me. ;)

Yeah I know :)

That would contradict common practice with every other Doom port that I know of.

ZDoom does it this way (statusbar -> hud -> nothing). However you are correct that many other ports do it the way Crispy does, and that also makes Chocolate Doom compatibility easier.

[fabian]

plums said:

ZDoom does it this way (statusbar -> hud -> nothing). However you are correct that many other ports do it the way Crispy does, and that also makes Chocolate Doom compatibility easier.

Exakt! BTW, I think I found a better / the final approach:

--- a/src/doom/p_inter.c
+++ b/src/doom/p_inter.c
@@ -737,7 +737,10 @@ P_KillMobj
    target->tics -= P_Random()&3;
 
     if (target->tics < 1)
        target->tics = 1;
+    else
+    if (singleplayer)
+        target->health -= target->tics;
                
     // I_StartSound (&actor->r, actor->info->deathsound);
 

[plums]

fabian said:

BTW, I think I found a better / the final approach:

That looks pretty good. Still a clever solution, which is important ;)

what is target->tics exactly? Could it ever be high enough ( > 40 or so) that you could gib an enemy from a non-gibbing weapon?

[fabian]

plums said:

Still a clever solution, which is important ;)

Indeed.

what is target->tics exactly?

It's the state tic counter. AFAIUI it counts how long the current state the object is in lasts before the next state is considered. In this specific case, it should kind of determine how long the monster dies.

Could it ever be high enough ( > 40 or so) that you could gib an enemy from a non-gibbing weapon?

I don't think so, but... how cool would that be? ;)

[FireFish]

What is the attraction or focus point of this source-port ?
In terms of target audience and gameplay, as all i know now is that its a limit removing form of chocolate at the moment.

i yet again might have to download this out of curiosity one day.

[fabian]

plums said:

Could it ever be high enough ( > 40 or so) that you could gib an enemy from a non-gibbing weapon?

Frankly, since I only check for the odd/even bit anyway, I will simply do

target->health -= target->tics & 1;

and that is even sign independent.

Edit: Honestly, I feel somehow tempted to add a slight gib chance to the SSG. What do you think?

[fabian]

FireFish said:

What is the attraction or focus point of this source-port ?
In terms of target audience and gameplay, as all i know now is that its a limit removing form of chocolate at the moment.

That was the sole purpose of the 1.0 release. Since then, Crispy Doom's aim has evolved to still remain as faithful to its Chocolate Doom code base and thus Vanilla Doom as possible, while adding some subtle (mostly graphical) improvements. Some of these are improvements that people got used to from Boom or ZDoom based ports, some others are exclusive to Crispy Doom. However, the overall objective is having fun with Doom! :)

FireFish said:

i yet again might have to download this out of curiosity one day.

Definitely! :)

[Blzut3]

fabian said:

I don't, that's the point. For Doom, 8 is just as arbitrary a value as 9, because there simply is no true or original value for Doom. I chose 9, because I knew it from Hexen - forgetting about Strife which uses 8 and furthermore uses a different algorithm to determine when the next jump is allowed after a previous jump.

If you want a less arbitrary argument. Do note that in both Hexen and Strife the jump height is roughly the height of the player itself (that is, Hexen's player classes are physically taller). ZDoom/EE's jump height of ~56 units follows this.

[plums]

FireFish said:

What is the attraction or focus point of this source-port ?
In terms of target audience and gameplay, as all i know now is that its a limit removing form of chocolate at the moment.

To me, Crispy Doom provides the feel of "authenticity" from Chocolate Doom while providing a bit more visibility, being compatible with more maps, and recently having some enhancements. (Obviously you may think that enhancements and authenticity are a contradiction, so that's a bit subjective. Still, most can be disabled.)

It's fairly minor, but I really like the HUD overlay and coloured blood Crispy Doom, and I think they add a lot to the game. Being able to jump and look around is nice too, sometimes.

Furthermore, work on Crispy Doom has resulted in improvements to the Chocolate Doom code base. While this is not something I can take any credit for, more users generally correlates to more coding being done. And I think fabian just enjoys tinkering with the Doom source ;)

fabian said:

Frankly, since I only check for the odd/even bit anyway, I will simply do

target->health -= target->tics & 1;

and that is even sign independent.

Edit: Honestly, I feel somehow tempted to add a slight gib chance to the SSG. What do you think?

Haha, sure, I'd be fine with that. How do you check for SSG specific damage though?


BTW, even though they are not being worked on anymore, are there still downloads for the other Crispy games?

[FireFish]

just played a few doom 2 iwad maps in crispy-doom (v 1.2).

So this is what i now see as the points of this engine ;
1 : old school cool looking keyboard, mouse, and gfx set-up program
2 : the sound seems to be more authentic then in ZD based ports.
4 : the graphics definitely, and still are, more authentic.
5 : optional : mouse look, jumping, secret revealed message

(not yet tested : limit removing wads)

so i would gues this is a port for people who like their high
resolutions, and also want more authentic graphics while having the
needs to play more modern PWADS without having to abandon the aforementioned.

[plums]

That's a pretty good summation of the port I'd say.

FireFish said:

(not yet tested : limit removing wads)

It's worth noting that Crispy Doom is only raised limits, not limit-removing. Complex or highly-detailed maps can still cause VPOs or other errors; a recent example is NOVA which has some later maps that don't work in Crispy Doom.

The limits were raised mainly because the higher resolution can result in a higher number of visplanes in some situations. They were raised to be in line with Doom+. So far I've resisted asking for even higher limits, though that may change at some point ;)

[Lila Feuer]

SSG gibbing would be awesome, nice subtle gore enhancement without new graphics.

[fabian]

FireFish said:

1 : old school cool looking keyboard, mouse, and gfx set-up program
2 : the sound seems to be more authentic then in ZD based ports.

This is all inherited from Chocolate Doom.

4 : the graphics definitely, and still are, more authentic.
5 : optional : mouse look, jumping, secret revealed message

Rendering is also inherited from Chocolate Doom. Crispy Doom specific enhancements are doubled horizontal and vertical resolutions, colored patches and sprites (blood), translucency and the options under point 5. Where is point 3, by the way?

so i would gues this is a port for people who like their high
resolutions, and also want more authentic graphics while having the
needs to play more modern PWADS without having to abandon the aforementioned.

Very nice summary, indeed.

plums said:

The limits were raised mainly because the higher resolution can result in a higher number of visplanes in some situations. They were raised to be in line with Doom+. So far I've resisted asking for even higher limits, though that may change at some point ;)

I dare you! ;)

Cyanosis said:

SSG gibbing would be awesome, nice subtle gore enhancement without new graphics.

It's in GIT:
https://github.com/fabiangreffrath/crispy-doom/commit/2a9f81154fe49d099908be0a207fc8020fededc6

Pretty well balanced already, if you are asking me. But please test yourself and share your opinions!

[plums]

fabian said:

I dare you! ;)

Heh heh. It's mostly a question of "how much more is necessary?" As we discussed in the issue tracker with NUTS.wad, there will always be some wads that won't run in Crispy Doom no matter how the limits are raised. So having some kind of baseline seems like a good idea to me, rather than just increasing limits by some amount.

OTOH maybe it would be nice to just double everything and see how many maps now work that didn't before?

NOVA is a recent limit-removing megawad I played that I really liked, that had several maps with too many VPOs for Crispy Doom. But a few of the maps are very detail-heavy and I suspect it would require much higher limits for everything to run.

[Archi]

Why don't you build a heretic version too?

[fabian]

Archi said:

Why don't you build a heretic version too?

Because the non-Doom games have fallen behind in terms of development and there were no significant changes since version 1.0, which is still available here:
http://greffrath.com/~fabian/crispy-doom_1.0.zip

[Archi]

fabian said:

Because the non-Doom games have fallen behind in terms of development and there were no significant changes since version 1.0, which is still available here:
http://greffrath.com/~fabian/crispy-doom_1.0.zip

That's sad. There's no non-dos Limit Removing ports for Heretic and Hexen with vanilla compatibility, IIRC.

[fabian]

Archi said:

That's sad. There's no non-dos Limit Removing ports for Heretic and Hexen with vanilla compatibility, IIRC.

Well, version 1.0 did actually have raised video resolution and raised static limits - but nothing else.

[fabian]

fabian said:

Pretty well balanced already, if you are asking me. But please test yourself and share your opinions:

http://www.greffrath.com/~fabian/crispy-doom-40b41e8687.exe

[plums]

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

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