Crispy Doom 6.0 (Update: Mar 31, 2023)

I think the level reversal feature is interesting, but how can I turn it off? Aside from switching the date, of course.

Heh heh, I was getting ready to file a bug report last night before I realized the date. Anyhow you can use the -fliplevels switch for today, which is what normally activates that feature.

It's amazing just how wrong everything feels flipped.

I think a configuration switch "never flip levels even on April 1st" should be added. Either that or disable level flipping when recording demos, as it limits demo viewing to Crispy.

Danfun64 said:

I think a configuration switch "never flip levels even on April 1st" should be added. Either that or disable level flipping when recording demos, as it limits demo viewing to Crispy.

Are the demo inputs not flipped/corrected too? Sounds like a bugfix waiting to happen :)

When using "-longtics -record" the level was still flipped. Ditto playing in multiplayer mode. Playing back a "normal" demo resulted in obvious desyncs.

That doesn't sound very crispy!!

kb1 said:

..or: check out my fix - it's easy to implement, and requires no changes to your sound system.

Erm, I don't remember you proposing an actual fix at all?

One idea is to fix it visually by maintaining a mobj viewx/viewy/viewz, but let the actual mobj be positioned using vanilla logic. You do this anyway for interpolation, right?

Yes, sure, but the interpolated position that is used for rendering is of course regularly synced with the mobj's actual position.

jeff-d said:

This seems to be an addition at some point as the original code did not stop sounds when the mobj was removed.

Wow, that's interesting!

Actually, I was just playing around with this code and blew up some rockets and barrels:

--- a/src/doom/p_mobj.c
+++ b/src/doom/p_mobj.c
@@ -626,7 +626,10 @@ void P_RemoveMobj (mobj_t* mobj)
     P_UnsetThingPosition (mobj);
     
     // stop any playing sound
+    if (!(mobj->type == MT_ROCKET || mobj->type == MT_BARREL))
+    {
     S_StopSound (mobj);
+    }
     
     // free block
     P_RemoveThinker ((thinker_t*)mobj);

kb1 said:

I think the original code points to an mobj that no longer exists, which is ok for DOS, sorta, but not so good on protected memory OSes.

Are you sure that the sound-emitting mobj is still needed at all if a sound just stops because it has finished playing?

Jon said:

Are the demo inputs not flipped/corrected too? Sounds like a bugfix waiting to happen :)

Linguica said:

That doesn't sound very crispy!!

Guys, "-fliplevels" was meant as a joke in the first place. Getting the inputs flipped is trivial, I am about to commit this fix ASAP. But demos will still desync, because of the way the flipped BLOCKMAP is processed within the game. Though, "-nomonsters" demos should work fine. ;)

fabian said:

Guys, "-fliplevels" was meant as a joke in the first place. Getting the inputs flipped is trivial, I am about to commit this fix ASAP. But demos will still desync, because of the way the flipped BLOCKMAP is processed within the game. Though, "-nomonsters" demos should work fine. ;)

I gathered that; thank you for taking the trouble, it's a fun joke :)

fabian said:

Erm, I don't remember you proposing an actual fix at all?

Yes, sure, but the interpolated position that is used for rendering is of course regularly synced with the mobj's actual position.

Wow, that's interesting!

Actually, I was just playing around with this code and blew up some rockets and barrels:

--- a/src/doom/p_mobj.c
+++ b/src/doom/p_mobj.c
@@ -626,7 +626,10 @@ void P_RemoveMobj (mobj_t* mobj)
     P_UnsetThingPosition (mobj);
     
     // stop any playing sound
+    if (!(mobj->type == MT_ROCKET || mobj->type == MT_BARREL))
+    {
     S_StopSound (mobj);
+    }
     
     // free block
     P_RemoveThinker ((thinker_t*)mobj);

And, the sounds play very long, it almost sounds like an echo. Honestly, I don't remember Doom ever sounded like that. :/

Are you sure that the sound-emitting mobj is still needed at all if a sound just stops because it has finished playing?

Honestly I haven't looked at vanilla - I was just going by memory, but, I'm sure at least my code accounts for sound volume based on the player's distance to the mobj, and handles sound balance (left vs. right) based on player's angle to the sound-emitting mobj. That's done by repeatedly calling S_UpdateSounds, if I recall correctly. I also seem to remember that it must have a mobj to position the sound, or a door cast as an mobj (which sounds weird - no pun intended). I guess I need to look at that code now :)

But that's why you kill the sound when the mobj disappears, otherwise S_UpdateSounds references Z_Freed memory.

I never presented a code fix, just an idea.

Could be wrong though, check it out to be sure. If so, that's a difficult crash-level bug waiting to happen.

As a quick fix you could just zero the pointer in the sound control block to the mobj as S_UpdateSounds checks first for a non-null pointer. That way the sounds can continue. If you need the sound to still change position as the player moves then you'd need a more complex solution.

jeff-d said:

As a quick fix you could just zero the pointer in the sound control block to the mobj as S_UpdateSounds checks first for a non-null pointer. That way the sounds can continue. If you need the sound to still change position as the player moves then you'd need a more complex solution.

This is a very welcome advice, thank you!

In Crispy Doom, all thinks that are removed from the map when they are destroyed -- e.g. Barrels, Missiles or Pain Elementals -- are turned translucent before disappearing. I have played around with the following code lately, but as I am very conservative regarding changes to sounds, I am still hesitating to commit it.

--- a/src/doom/p_mobj.c
+++ b/src/doom/p_mobj.c
@@ -626,6 +626,10 @@ void P_RemoveMobj (mobj_t* mobj)
     P_UnsetThingPosition (mobj);
     
     // stop any playing sound
+    if (mobj->flags & MF_TRANSLUCENT)
+    {
+	S_UnlinkSound(mobj);
+    }
     S_StopSound (mobj);
     
     // free block
--- a/src/doom/s_sound.c
+++ b/src/doom/s_sound.c
@@ -308,6 +308,20 @@ void S_StopSound(mobj_t *origin)
     }
 }
 
+void S_UnlinkSound(mobj_t *origin)
+{
+    int cnum;
+
+    for (cnum=0 ; cnum<snd_channels ; cnum++)
+    {
+        if (channels[cnum].sfxinfo && channels[cnum].origin == origin)
+        {
+            channels[cnum].sfxinfo = NULL;
+            break;
+        }
+    }
+}
+
 //
 // S_GetChannel :
 //   If none available, return -1.  Otherwise channel #.

fabian said:

channels[cnum].sfxinfo = NULL;

No, it should be:

channels[cnum].origin = NULL

If you want a more complex solution you can make a dummy mobj to link to

This is my solution.

1st you need a mobj type of structure which is basically the first part of a mobj:
(Your port may differ, I haven't looked!)

static degenmobj_t*	sound_origin;

  sound_origin = (degenmobj_t *) Z_Malloc (snd_channels*sizeof(degenmobj_t), PU_STATIC, 0);

void S_UnlinkSound(mobj_t *origin)
{
    int cnum;
    mobj_t* mobj;
    degenmobj_t * sorigin;

    for (cnum=0 ; cnum < snd_channels ; cnum++)
    {
	if (channels[cnum].sfxinfo && channels[cnum].origin == origin)
	{
	    sorigin = &sound_origin [cnum];
	    sorigin -> x = origin -> x;
	    sorigin -> y = origin -> y;
	    sorigin -> z = origin -> z;
	    channels[cnum].origin = (mobj_t *) sorigin;
	    break;
	}
    }
}

jeff-d said:

This is my solution.

Looks reasonable to me. It is desirable to maintain the disappearing mobj's x/y (and z) coordinates to allow left/right pan, and distance calculations to continue to work, even for the split second after the mobj disappears, before the sound stops. That way, things don't go weird when the player angle changes.

Then again, if you think about it, except for a possible Doppler effect, it's kinda goofy to hear sound from something that has visually disappeared anyway :)

jeff-d said:

No, it should be:

channels[cnum].origin = NULL

Ah, right. This way the sound at least gets to the I_SoundIsPlaying() check and has a chance to get properly stopped.

I also like the other more complex solution that you posted. But I am also with kb1, that it's possibly not worth the effort given the split seconds that a sound resumes after its object disappears -- and I prefer smart and simple solutions whenever possible. ;)

Linguica said:

I bet I know why: the archvile flame sometimes has its position set to the wrong z-height and then is repositioned, and the interpolation code isn't taking this into account and is trying to draw the flame at some in-between point. More discussion: https://www.doomworld.com/vb/post/1297927

I have fixed this now following Quasar's excellent analysis in the quoted posting by updating the fire sprite's floorz and ceilingz values each time it follows the player's map object.

Usually, this is one of the glitches I would have left intact, since its original fix requires to change the initial position of the fire map object in a probably different vector, which must be considered demo-critical (although I have checked some demos with this fix and they didn't desync).

However, this glitch was severely emphasized by uncapped rendering and I consider the fix that Quasar pointed out (and which I finally applied) as harmless.

Gez said:

I remember this was exploited by at least one vanilla mod and caused problems in ZDoom.

I have implemented this fix based on jeff-d's original idea, thanks again! The more I tested it, I got used to the rocket explosion sounds playing to finish and especially the plasma gun projectiles sounded so great in full length that I simply couldn't un-hear anymore when they are cut off in Choco.

Although I am bit afraid of the compatibility issue that Gez pointed out, I nevertheless decided to keep it in without an additional Crispness switch.

Question for fabian, but also for anybody in this thread who uses Crispy Doom on the regular. Have you had any player complaints that the mouse felt laggy when using uncapped framerate?

The reason I ask is because the way ZDoom handles mouse control of the camera uses no interpolation - instead it immediately modifies the angle of the camera straight from the event handler. That kind of seemed...inelegant to me, so I never implemented it, but if "mouse lag" is something some of your users experience, I'm more than happy to take another look at the problem.

To be clear, I know that there is lag when capped framerate interpolation is used - there is only a question of if it is noticeable to users.

I noticed a slight difference in mouse feel when I started using the uncapped framerate option, but not really enough to be bothered by it, and it didn't take long at all for me to get used to.

I also just realized that it does not appear that vertical mouselook is properly interpolated in the first place - so if nothing else I could fix that.

I will complain about it, I guess. I see no downside to polling the mouse and changing the angle of the player view every frame, while I guess maintaining a buffer to do the "real" turn movement at 35hz.

I noticed that mouselook up/down still works even when the game is paused/in a menu

@AlexMax Hey Alex, thank you very much for your offer to work further on this. I have to admit, I don't play with uncapped framerate too often and I am not that sensible to issues like lagging mouse. But I am sure there are other like linguica who feel what you describe. So, yes, please, any PR is welcome. ;)

I noticed that mouselook up/down still works even when the game is paused/in a menu

Oh, this for sure isn't right. I should only update the lookdir variable once per tic. I am about to change that soon. Thanks for noticing!

Fabian, a question I've been wondering a bit: which Crispy features do you/don't you use? Just curious :)

I think I use pretty much everything, apart from the crosshair/laser pointer, and weapon recoil.

plums said:

Just curious :)

No problem. ;)

I usually play with capped 35 FPS framerate or one of the 60/70 FPS modes. Apart from this, I have all "visual" features enabled. Regarding "tactical" features, I play with a projected crosshair and locked mouse look (bound to the right mouse key), everything else is also enabled, except for recoil pitch. The "physical" features are all enabled, except for recoil thrust, with jumping set to low.

Jon said:

I noticed that mouselook up/down still works even when the game is paused/in a menu

This is fixed now, thanks!

Gez said:

Or you could load them from a PWAD, I suppose.

I tired that, and it didn't work. So i figured it isn't supported.

fabian said:

Erm, no, it isn't implemented this way. It identifies the BFG Edition IWADs by other lumps and then concludes that they must also include the additional menu graphics lumps. But I could do it the way you suggest, sure.

It would be great if loading the menu graphic lumps form a PWAD could be supported. As long as it doesn't cause too much hassle.

Doomer1999 said:

It would be great if loading the menu graphic lumps form a PWAD could be supported. As long as it doesn't cause too much hassle.

Alright, this has been requested before, so I changed it in GIT and it will be available in the next release. It will now be possible to provide the New Game menu graphics lumps in a PWAD, but NERVE.WAD must still be available for the menu to appear, of course. Please note that things may look weird if you load another PWAD along, e.g. a MegaWAD with its own title screen and menu font.

fabian said:

Alright, this has been requested before, so I changed it in GIT and it will be available in the next release. It will now be possible to provide the New Game menu graphics lumps in a PWAD, but NERVE.WAD must still be available for the menu to appear, of course. Please note that things may look weird if you load another PWAD along, e.g. a MegaWAD with its own title screen and menu font.

Ouch! The problem is that even the Vanilla DOOM2.WAD contains the original menu graphics from Doom 1. So, all the necessary lumps will be there, the menu will show up, but the episodes will be the ones from Doom 1.

This means I will have to check if the menu graphics lumps are either *really* from a PWAD or, if they are from the IWAD, if the latter is *really* the DOOM2.WAD from the BFG Edition. This, or I will simply revert this change again...

First off, gotta say I fucking love Crispy Doom. My #1 choice for vanilla and limrem stuff.

Some small things I noticed:

• The ceiling height change lines on the map are VERY close in colour to the solid ones, very hard to make out at a glance, and should probably be tweaked.
  
• The map colours are not very well suited for overlay mode in most cases, since they are rather midtone colours and get easily lost.
  
• Maybe have a way to switch to classic map colours in the crispness options.
  
• Since you are removing smaller bugs like the "ouch face" one and similar things, I think maybe removing the bullet puffs not showing in outside areas bug would be cool, since that is a purely visual thing that should also not cause sync issues (I would hope)
  
• It would be nice if you could go through the sections of the crispness menu by using the page down and page up keys.