Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

Crispy Doom 6.0 (Update: Mar 31, 2023)

Recommended Posts

I have just uploaded a fixed Music Pack:

Crispy Doom Music Pack 2

* Fix a typo in crispy-doom-music-pack.bat
* Add fixed SDL_mixer.dll for FLAC and MikMod support
(libSDL_mixer-1-2-0.dll 1.2.12-4 from MSYS2 renamed
to SDL_mixer.dll, overwrite SDL_mixer.dll bundled
with Crispy Doom with this file)
* Add libvorbisfile-3.dll for OGG Vorbis support
* Add libmikmod-3.dll and libopenal-1.dll for
MOD, STM, S3M, MTM, XM and it support

http://www.greffrath.com/~fabian/crispy-doom-music-pack_2.zip

Share this post


Link to post

Music Pack 2 shares the same problems that my unofficial Music Pack provided. Mainly music not looping and stuff not at the right sample rate going too fast or too slow.

Share this post


Link to post
Danfun64 said:

Mainly music not looping and stuff not at the right sample rate going too fast or too slow.

I cannot tell what's wrong with the looping, but it's a well-known limitation of SDL_mixer that it cannot on-the-fly adapt samplerates of the music it is playing.

Edit: From a private mail exchange with Zodomaniac on 17 Nov 2015:

> It doesn't matter how you launch the MAP02 in Crispy, either way
> DoomMetalVol4 music is played with higher frequency and faster tempo
> (multiplied by about 1.33, resulting in about +5 semitones pitch
> shift). As I already said, music is played correctly after extracting
> from the WAD in foobar2000, or when playing the WAD with Zandronum
> engine.

[...]

I think the reason is the following:

$ file d_runnin.ogg d_stalks.ogg
d_runnin.ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~64000 bps, created by: Xiph.Org libVorbis I
d_stalks.ogg: Ogg data, Vorbis audio, stereo, 32000 Hz, ~64000 bps, created by: Xiph.Org libVorbis I

d_runnin.ogg is the song played during MAP01 and d_stalks.ogg is the
song played during MAP02. Note how both songs have different sample
rates! The samplerates used during playing are hard-coded in both
Chocolate and Crispy Doom by the snd_samplerate variable, which is set
to 44100 by default. You may want to try to set it to e.g. 32000 in
crispy-doom.cfg and see if the song in MAP02 is played back with the
correct pitch, then. However, all the other songs with the 44100
samplerate will sound odd, then.

It appears that the SDL_mixer1.2 library used in both Chocolate and
Crispy Doom is unable to adapt the samplerates of the music it is
playing. Zandronum is based on ZDoom and thus uses FMOD instead of
SDL_mixer for music playback. I hope that the situation improves once
we switch the Choco code base to use SDL2.

Share this post


Link to post

Random colors for marine corpses, and colored crushed gibs?

I think I like these colored crushed gibs more than ZDoom's, where everything changes color. Here the green and blue gibs retain chunks of pink meat.

Share this post


Link to post
Gez said:

I think I like these colored crushed gibs more than ZDoom's, where everything changes color. Here the green and blue gibs retain chunks of pink meat.


they were solid color in the previous version, the pink meat is a new feature (taken from Boom according to the patch notes)

and yeah the colored marine corpses was an idea I suggested (not knowing if it was even doable, but apparently it was very easy). my only contribution to the Doom community as a total nobody!

Share this post


Link to post

I just tried to join a chocolate doom server with Crispy and it gave me D_InitNetGame: Failed to Connect.

I was under the impression that Crispy was netcode-compatible with Chocolate - am I wrong?

Share this post


Link to post

Try again, but use the latest git build for both crispy and chocolate.

Crispy Doom often has releases months after the latest stable chocolate build. Crispy tries to sync with whatever the latest chocolate git build is, and sometimes chocolate's git changes desync with chocolate's latest stable build.

Share this post


Link to post
fabian said:

It appears that the SDL_mixer1.2 library used in both Chocolate and
Crispy Doom is unable to adapt the samplerates of the music it is
playing. Zandronum is based on ZDoom and thus uses FMOD instead of
SDL_mixer for music playback. I hope that the situation improves once
we switch the Choco code base to use SDL2.


We do sample rate normalisation for sound effects already; we may have to re-use that code for music too. I'm not sure but I doubt SDL2_Music will handle this for us.

Share this post


Link to post

This port is virtually perfect. It does almost everything I want it to do (aside from being able to play the OGG sound effects I imported from Doom 3 and, oddly, the WAV sound effects from the PSX Doom TC's sound library. Those are minor things, however).

Only other things I can suggest at the moment:

-Consider darkening the blood color of hell nobles. Compare their crushed gibs (when blood color correction is on) to the blood pooling under their normal dead body sprite, and the crushed sprite has a much brighter blood color, too similar to the crazy neon green blood in the GBA Doom games. I'm not sure how this engine calculates color values, but at least when doing custom blood colors in ZDoom, a value of 10 50 10 seems almost perfect for hell noble blood.

-Consider doing like the other limit-removing source ports and have it that death sound effects don't cut out when the actor they're associated with disappears. This would mean explosion sounds would continue to play in full even after a projectile's explosion animation is complete, instead of the sound suddenly stopping once the last frame of animation is over. I have a hard time imagining this would break compatibility with anything, and it seems like a genuine fix instead of something that would significantly alter the intent of the original game's audio/visual experience, but I won't pretend I'd know for sure.

-Do you think hanging/impaled corpses should be affected by corpse mirroring? Or is that overstepping bounds too much? I suppose that could present problems if you're playing a DeHackEd patch that uses the frames of those decorations for other things. However, a DEH patch might also use potentially-mirrored enemy/player corpse frames for other things anyway, so it might just be a bad idea to use mirroring at all with DEH patches, which means it might be fine to mirror hanging/impaled corpses. I'm really not sure, but I'll throw the idea out there.

Those things aside (and very trivial issues they are), this is an amazing port and pretty much my preferred way to play vanilla these days.

Share this post


Link to post
AlexMax said:

I just tried to join a chocolate doom server with Crispy and it gave me D_InitNetGame: Failed to Connect.

I was under the impression that Crispy was netcode-compatible with Chocolate - am I wrong?


Yes, Crispy does maintain netcode-compatibility with Chocolate Doom. However, you are currently only able to join a Crispy server with a Choco client, not the other way round.

I could change this, biu I am not sure if it will be considered "correct" for Crispy Doom to identify itself as Chocolate Doom towards servers?

Danfun64 said:

Crispy Doom often has releases months after the latest stable chocolate build. Crispy tries to sync with whatever the latest chocolate git build is, and sometimes chocolate's git changes desync with chocolate's latest stable build.


Erm, no, that's really not the reason. The reason as given above is that Choco servers currently only accept clients that identify themselves as "Chocolate Doom 2.2.1" and nothing else, whereas Crispy servers accept clients that identify themselves as either "Chocolate Doom 2.2.1" or "Crispy Doom 3.3".

Share this post


Link to post
Megamur said:

This port is virtually perfect. It does almost everything I want it to do


Thank you!

-Consider darkening the blood color of hell nobles.


No, sorry. It is using the original Boom color translation tables to convert the shades of red of the blood pools into the shades of green that can be found in Doom's palette.

-Consider doing like the other limit-removing source ports and have it that death sound effects don't cut out when the actor they're associated with disappears.

"the other limit-revoming ports" sounds more like "ZDoom" to me. ;)

Could you please point me to any other non-ZDoom port that does it the way you prefer?

- Do you think hanging/impaled corpses should be affected by corpse mirroring?

Hm, sure, why not. But as you stated yourself, these hanging corpses are often replaced by custom content, so randomly flipping them might look inconsistent.

Anyway, a nice idea to consider.


Thanks again!

Share this post


Link to post
fabian said:

Erm, no, that's really not the reason. The reason as given above is that Choco servers currently only accept clients that identify themselves as "Chocolate Doom 2.2.1" and nothing else, whereas Crispy servers accept clients that identify themselves as either "Chocolate Doom 2.2.1" or "Crispy Doom 3.3".


The correct behavior is if (and only if) you are 100% compatible with Chocolate Doom 2.2.1 is to identify yourself as Chocolate Doom 2.2.1, regardless of the fact that you're actually Crispy Doom. The version string is acting like a "netcode version" that is common in other netcode protocols. I know both Odamex and Zandronum have one.

As an example, Zandronum and the Zandronum Community Client are two distinct projects, but they both claim to be Zandronum 2.1.2 when speaking the network protocol. This is not considered bad form or impolite, it's just a fact of the protocol - as long as you can speak the protocol properly, the server doesn't and shouldn't care.

I don't know exactly how Chocolate version strings are handled, but if there is a hypothetical VERSION_STRING define that is used everywhere including as the network protocol identifier, and you have to introduce a separate NET_VERSION_STRING that just holds the version string used as the network identifier, then do it.

Something you might also want to consider is that if you ever add features that are netcode-incompatible with Chocolate, enabling said features would then be the proper point to identify yourself as Crispy Doom.

Share this post


Link to post
fabian said:

No, sorry. It is using the original Boom color translation tables to convert the shades of red of the blood pools into the shades of green that can be found in Doom's palette.

So it's impossible to make a new, more-accurate translation table that wouldn't make the green blood so bright?

"the other limit-revoming ports" sounds more like "ZDoom" to me. ;)

Could you please point me to any other non-ZDoom port that does it the way you prefer?

I thought PrBoom-plus did this, but I was mistaken. Doomsday does it, though.

Share this post


Link to post
AlexMax said:

The correct behavior is if (and only if) you are 100% compatible with Chocolate Doom 2.2.1 is to identify yourself as Chocolate Doom 2.2.1, regardless of the fact that you're actually Crispy Doom.


Alright, I'll consider this for ther next release -- unless someone asks me not to, that is.

The version string is acting like a "netcode version" that is common in other netcode protocols. I know both Odamex and Zandronum have one.


Actually, we should really implement something like this (i.e. a network protocol version) for Choco and compatible ports.

[...] if you ever add features that are netcode-incompatible with Chocolate, [...]

This won't happen. There are already some netcode or demo breaking features in Crispy, but they are strictly disabled in network games and during demo recording and playback.

Megamur said:

So it's impossible to make a new, more-accurate translation table that wouldn't make the green blood so bright?


Actually, what we have now is already an improved color translation table. Check here for a comparison with the looks before I reverted back to the original Boom tables:

https://github.com/fabiangreffrath/crispy-doom/issues/97#issuecomment-197026309

I would never say it's "impossible", but I am very convinced of the current color translation results and I am certainly not going to nit-pick about which shade of green fits better to which shade of red. Please no.

I thought PrBoom-plus did this, but I was mistaken. Doomsday does it, though.


Could you maybe give me an example of a situation in which this effects becomes absolutely apparent? I am still not entirely sure I understand what you mean here. :/

Share this post


Link to post
fabian said:

Could you maybe give me an example of a situation in which this effects becomes absolutely apparent? I am still not entirely sure I understand what you mean here. :/

Fabien, I think the issue is that sometimes a mobj is destroyed after having started to play a sound, but before that sound is finished, causing the sound to be truncated 'follows' the dying mobj, and plays the mobj's "final speech".

If I remember correctly, I don't always do it this way, ,cause it's not always appropriate to keep playing the sound. Some examples of when you want to the sound to cut off are archvile resurrection (maybe), and crush to gibs. Probably others too.

Share this post


Link to post

The easiest way to notice it is to fire some rockets and listen to the explosion, and then blow up a barrel and listen to the explosion.

Share this post


Link to post

Right. Rocket explosion sound effects are cut off at the end because the sound effect only plays for as long as the explosion graphics are visible. Once the animation is completed and the sprite disappears from the game, so does the sound. By comparison, ZDoom plays the explosion sound and all other projectile "death" sounds in their entirety, even after the graphic disappears.

Share this post


Link to post

i noticed that if you change the framerate, the arch vile's attack doesn't display properly.

Share this post


Link to post
buvk said:

i noticed that if you change the framerate, the arch vile's attack doesn't display properly.

Can you specify how it's displaying incorrectly? I just tested and it seems roughly the same to me. What version of Crispy are you using and which framerates (uncapped/60/70) do you see the problem?

Share this post


Link to post
vadrig4r said:

Can you specify how it's displaying incorrectly? I just tested and it seems roughly the same to me. What version of Crispy are you using and which framerates (uncapped/60/70) do you see the problem?


testing with the arch vile in doom2 map11, sometimes the flames are not displayed at all and sometimes they are barely/faintly displayed. i replicated this with 60, 70 and uncapped fps. 35 fps has no issues.

interestingly enough, i tested this with a different arch vile, and did not experience the same issue.

Share this post


Link to post
buvk said:

testing with the arch vile in doom2 map11, sometimes the flames are not displayed at all and sometimes they are barely/faintly displayed. i replicated this with 60, 70 and uncapped fps. 35 fps has no issues.

interestingly enough, i tested this with a different arch vile, and did not experience the same issue.

Ahh that explains it. I'd made a custom map to test.

Examining the MAP11 Arch-vile it's clear that, for whatever reason, even on 35 FPS the animation is not normal. It appears to be sped up or has missing frames (can't tell which). This is present in both Chocolate Doom and the original DOOM2.EXE in Dosbox. Crispy Doom's uncapped and raised framerates seem to merely make it more noticeable (as one would expect).

I have no idea why this Arch-vile (or MAP11?) seems to behave this way, maybe someone else could enlighten us. For reference PrBoom+ seems to render the MAP11 Arch-vile animation the same as any other Arch-vile, on capped or uncapped framerate.

Share this post


Link to post
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

Ha, brilliant! I tried searching for a reference to this but to no end. So those 'lost frames' are getting drawn, just at some completely wrong location?

Share this post


Link to post
Megamur said:

Right. Rocket explosion sound effects are cut off at the end because the sound effect only plays for as long as the explosion graphics are visible. Once the animation is completed and the sprite disappears from the game, so does the sound. By comparison, ZDoom plays the explosion sound and all other projectile "death" sounds in their entirety, even after the graphic disappears.

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

Share this post


Link to post
Megamur said:

Right. Rocket explosion sound effects are cut off at the end because the sound effect only plays for as long as the explosion graphics are visible. Once the animation is completed and the sprite disappears from the game, so does the sound. By comparison, ZDoom plays the explosion sound and all other projectile "death" sounds in their entirety, even after the graphic disappears.


Sounds like it would require to make the call to "S_StopSound (mobj)" in "P_RemoveMobj()" conditional depending on the type of "mobj". I'll test this and check how it sounds and if it collides with other sounds. Not sure if I'll consider it if it requires further modifications to the sound stack like e.g. increasing the number of sound channels.

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


Thank you very much for this insightful information!

I knew about the Archvile's attack fire sprite positioning bug, but I had not idea about its further implications. Seems like I have two choices to mitigate this visual glitch with interpolated uncapped rendering: Either I exclude the fire sprite from interpolations (booh!) or I fix the underlying sprite positioning bug and hope check that it doesn't break demo and netgame compatibility. I very much prefer the latter.

Is it already known if this is merely a visual glitch or if fixing it has further possibly demo-breaking effects?

Share this post


Link to post
fabian said:

Is it already known if this is merely a visual glitch or if fixing it has further possibly demo-breaking effects?

Just checked, and fixing the Archville attack fire sprite position does *not* desync a Plutonie 30 UVmax demo. So what else could it possibly desync? ;)

Share this post


Link to post
fabian said:

Sounds like it would require to make the call to "S_StopSound (mobj)" in "P_RemoveMobj()" conditional depending on the type of "mobj". I'll test this and check how it sounds and if it collides with other sounds. Not sure if I'll consider it if it requires further modifications to the sound stack like e.g. increasing the number of sound channels.

Thank you very much for this insightful information!

Don't forget:

kb1 said:

(a workable fix...)

The sound's position is determined by the mobj, isn't it? So you'd have to somehow set a flag that says "this sound is no longer at mobj.x, mobj.y, mobj.z anymore (since that mobj no longer exists). Instead, render this sound at a cached positionm of where the mobj used to be.

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

fabian said:

I knew about the Archvile's attack fire sprite positioning bug, but I had not idea about its further implications. Seems like I have two choices to mitigate this visual glitch with interpolated uncapped rendering: Either I exclude the fire sprite from interpolations (booh!) or I fix the underlying sprite positioning bug and hope check that it doesn't break demo and netgame compatibility. I very much prefer the latter.


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?

fabian said:

Is it already known if this is merely a visual glitch or if fixing it has further possibly demo-breaking effects?

Share this post


Link to post
fabian said:

Sounds like it would require to make the call to "S_StopSound (mobj)" in "P_RemoveMobj()" conditional depending on the type of "mobj".


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

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×