fabian Posted March 18, 2016 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 0 Share this post Link to post
Danfun64 Posted March 18, 2016 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. 0 Share this post Link to post
fabian Posted March 19, 2016 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. 0 Share this post Link to post
MugMonster Posted March 19, 2016 hooray, time to see my suggestion in action and this is just lovely 0 Share this post Link to post
Gez Posted March 19, 2016 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. 0 Share this post Link to post
MugMonster Posted March 19, 2016 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! 0 Share this post Link to post
LexiMax Posted March 20, 2016 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? 0 Share this post Link to post
Danfun64 Posted March 20, 2016 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. 0 Share this post Link to post
Jon Posted March 20, 2016 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. 0 Share this post Link to post
Megamur Posted March 21, 2016 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. 0 Share this post Link to post
fabian Posted March 23, 2016 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". 0 Share this post Link to post
fabian Posted March 23, 2016 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! 0 Share this post Link to post
LexiMax Posted March 24, 2016 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. 0 Share this post Link to post
Megamur Posted March 24, 2016 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. 0 Share this post Link to post
fabian Posted March 24, 2016 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. :/ 0 Share this post Link to post
kb1 Posted March 24, 2016 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. 0 Share this post Link to post
Linguica Posted March 24, 2016 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. 0 Share this post Link to post
Megamur Posted March 25, 2016 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. 0 Share this post Link to post
buvk Posted March 26, 2016 i noticed that if you change the framerate, the arch vile's attack doesn't display properly. 0 Share this post Link to post
vadrig4r Posted March 26, 2016 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? 0 Share this post Link to post
buvk Posted March 26, 2016 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. 0 Share this post Link to post
vadrig4r Posted March 26, 2016 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. 0 Share this post Link to post
Linguica Posted March 26, 2016 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 0 Share this post Link to post
vadrig4r Posted March 26, 2016 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? 0 Share this post Link to post
Gez Posted March 26, 2016 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. 0 Share this post Link to post
fabian Posted March 29, 2016 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? 0 Share this post Link to post
fabian Posted March 30, 2016 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? ;) 0 Share this post Link to post
kb1 Posted March 30, 2016 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? 0 Share this post Link to post
jeff-d Posted March 31, 2016 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. 0 Share this post Link to post
kb1 Posted March 31, 2016 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. 0 Share this post Link to post