Crispy Doom 6.0 (Update: Mar 31, 2023)

[DoomedDude]

It could just be me. 

[DoomedDude]

I just tested it, it seems that in version 5.6 and before whenever I hit an exit switch in like in e1m1 for example, the game immediately does the melting effect and shows the level stats whereas in 5.6.1 there's like a half second delay before the melting effect happens. 

[Lord_Kane]

Ok I have a weird problem.

A very weird problem, whenever I run crispy doom there is no music but the sound effect chipmunk or play a much higher speed and pitch.

 

Edit: Happens on 5.6 as well

Does not happen with chocolate doom.

 

Edit2:

Does NOT occur on 5.5.2

Edited September 2, 2019 by Lord_Kane

[fabian]

Could you try the measures outlined in the wiki?

https://github.com/fabiangreffrath/crispy-doom/wiki/FAQ

[Lord_Kane]

17 minutes ago, fabian said:

Could you try the measures outlined in the wiki?

https://github.com/fabiangreffrath/crispy-doom/wiki/FAQ

 

Alright I tried 2 of those options since I am not programmer so compiling and all that stuff utterly confuses and mystifies me and I leave that the more experienced.

 

1. Changing the advanced tab in my speaker properties to CD quality produced no change.

 

2. setting use_libsamplerate to 0 "worked" in a sense but all effects where "clipped" and did not fully play to the end and setting "play sounds in full length" did not alleviate that issue.

Edited September 2, 2019 by Lord_Kane
general edit.

[Lord_Kane]

13 hours ago, fabian said:

Could you try the measures outlined in the wiki?

https://github.com/fabiangreffrath/crispy-doom/wiki/FAQ

 

I found a temp workaround but I want to know if its okay to do long term.

 

I took the SDL.dll's (SDL2.dll SDL_Mixer.dll and SDL_net.dll) from 5.5.2 and put them in the directory with 5.6.1 and the sound works as expected again, is this ok to do long term? Will I inhibit any function of crispy doom by doing this?

[fabian]

You may do it this way, but it shows once again that SDL on windows is a moving target. 

Edited September 3, 2019 by fabian

[Lord_Kane]

37 minutes ago, fabian said:

You may do it this way, but it shows once again that SDL on windows is a moving target. 

 

Yeah I have heard a few devs complain about it, thank you for the help, hopefully it resolves itself over time.

I recently switched from gzdoom to crispy and love crispy, I didnt want to switch back, I spent a few hours trying to resolve it.

[2mg]

On 8/22/2019 at 9:37 AM, fabian said:

I am afraid, there isn't much I can do about this. The feedback for playing with both uncapped framerate and vsync enabled is mostly "butter smooth" (also for me, though on Linux) - but there are always a few for which it lacks. The reason for this could be anywhere between your mouse's native resolution, your mouse driver or some setting, your Windows version, SDL or even the port itself - but I have no idea what exactly.

 

That's, uh, unfortunate. Is Crispy using two different tickers for engine and rendering when framerate is uncapped?

 

On 8/23/2019 at 7:53 PM, Get Phobo said:

Yes, there are many factors that can influence that. Apart from the mentioned above it can also be due to the 60 Hz setting itself. Doom is rendered internally at 35 fps, so, in theory, any multiple of that should be fine--60 fps is not a multiple of 35 fps, so there will always be some additional trade-off, including some amount of input and animation lag.

 

For reference, I couldn't notice it in Doom3BFG/Classic RBDOOM with Vsync aka swap_interval for OpenGL (although it's hard to notice since those are locked to 35hz), and neither in GZDoom with frame interpolation.

[fabian]

11 hours ago, 2mg said:

That's, uh, unfortunate. Is Crispy using two different tickers for engine and rendering when framerate is uncapped?

 

Yes, of course. The engine keeps "thinking" at 35FPS and the frames rendered in-between need to get interpolated.

[Get Phobo]

@2mg, I don't know. I can definitely see a difference.

 

70 fps is way smoother than 35 fps, even though the game "thinks" at 35 fps. Without rendering interpolation, the game becomes sluggish. Basic map rendering is already a lot smoother at 70 fps. Just try for yourself by strafing along a wall.

 

BTW, if you prefer playing w/o Vsync, I recommend capping the framerate at 140 fps instead.

Edited September 4, 2019 by Get Phobo

[maxmanium]

I think I found a minor sound bug, though I could be mistaken:

 

I have "play sounds in full length" disabled, but when reloading a save game, the chainsaw's rev-up sound always plays in full length, rather than being cut off by the idle sound. "Misc. sound fixes" does not seem to affect this.

[fabian]

This seems to be normal vanilla behavior. See the third paragraph in the Exception section:

https://doomwiki.org/wiki/Sound_cutoffs

[maxmanium]

4 hours ago, fabian said:

This seems to be normal vanilla behavior. See the third paragraph in the Exception section:

https://doomwiki.org/wiki/Sound_cutoffs

 

Are you referring to this?

 

Quote

If the chainsaw was the active weapon when the previous level ended, DSSAWUP is fully played at the end of the intermission sequence (except for console versions of Doom where this sound is not played at the start of the level).

 

If so, this isn't what I meant to say -- sorry for the confusion. I meant that when you reload a save game at any point, selecting the chainsaw plays its full rev-up sound every time -- not just when starting a level with it selected. I gave it a go in Chocolate Doom and this same behavior does not occur. I tested this by starting a new Doom II game and getting the chainsaw; in this instance, the sound is cut off normally. When I started a new Doom II game, saved, loaded that save, and then got the chainsaw, the sound is not cut off.

Edited September 8, 2019 by maxmanium

[Aurelius]

I had this interesting texture glitch while using ukiro's recently updated OTEX 1.0 texture pack in a limit-removing vanilla level that I tested with Crispy Doom. It was not present with any other source port that I tested it with (PrBoom+, Eternity or GZDoom).

 

When I open a door with an S action (like  63 SR Door Open Wait Close), for a brief moment another texture (OSWTCHK0 to be exact) appears below it (as if it was a middle texture) but disappears after a moment.

 

It reappears every time I open the door. Only the doors with S action have this glitch, however, and the D action doors remain unaffected.

 

I also experienced it with a regular switch, where the texture appears on top of the switch. 

 

Therefore it probably has something to do with the S linedef-actions.

 

ukiro suggested it could be the size of the pack, so I reduced the size from 68 MB to 26 MB, but included the glitching textures (patches OC0_11_0 to OC0_11_3). The glitch was still present, which means the size might not be a factor here.

 

Here's a small wad I made that demonstrates the effect. Needs to be run with Crispy along with OTEX_1.0.

 

[fabian]

@Aurelius Thanks for posting this here! I can't check the WAD out, currently, so (1) does this happen with Doom 1 or Doom 2 and (2) are you sure you are using Crispy doom 5.6.1 and not 5.6 (the 5.6 release mixed up the texture definitions with those if Sigil if the latter was auto-loaded).

[Aurelius]

 

@fabian I tested it with Doom 2. Quickly tested it with Ultimate Doom, and there seems to be no glitch there. And yes, I used the 5.6.1 version of Crispy Doom.

[2mg]

On 9/4/2019 at 11:18 AM, fabian said:

 

Yes, of course. The engine keeps "thinking" at 35FPS and the frames rendered in-between need to get interpolated.

 

On 9/4/2019 at 6:41 PM, Get Phobo said:

@2mg, I don't know. I can definitely see a difference.

 

70 fps is way smoother than 35 fps, even though the game "thinks" at 35 fps. Without rendering interpolation, the game becomes sluggish. Basic map rendering is already a lot smoother at 70 fps. Just try for yourself by strafing along a wall.

 

BTW, if you prefer playing w/o Vsync, I recommend capping the framerate at 140 fps instead.

 

Lemme just say that I'm not glorifying GZDoom here, but I just can't replicate input lag on it, no matter the setting, I'm using GZ to actually try to figure out why Choc/Crispy isn't behaving equally. Maybe I didn't notice the 35hz-on-60hz animation/behavior difference, but input lag? Gone (as in I can't feel it) on GZ. It does something differently, but what, well, I'm no sourceport dev...

 

Unfortunately I'm on a 60hz LCD, so I can't try anything else, I doubt 140 cap would help.

 

Thanks for trying to help though!

 

[Gez]

On mardi 3 septembre 2019 at 11:41 PM, 2mg said:

For reference, I couldn't notice it in Doom3BFG/Classic RBDOOM with Vsync aka swap_interval for OpenGL (although it's hard to notice since those are locked to 35hz), and neither in GZDoom with frame interpolation.

 

13 hours ago, 2mg said:

It does something differently, but what, well, I'm no sourceport dev...

 

The only thing I can think of that's in common to GZDoom and Classic RBDoom3-BFG but not in common with Choco, Crispy, PrBoom+, Eternity, etc. is that neither CRBD3BFG nor GZDoom use SDL on Windows.

[fabian]

Update September 13, 2019: Crispy Doom 5.6.2 is released!

Crispy Doom is a friendly fork of Chocolate Doom that provides a higher display resolution, removes the static limits of the Doom engine and offers further optional visual, tactical and physical enhancements while remaining entirely config file, savegame, netplay and demo compatible with the original.

 

Crispy Doom 5.6.2 has been released on September 13, 2019. The primary aim of this release is to fix the music-related bugs that surfaced in 5.6.1 and previous releases.

 

Please visit the Crispy Doom homepage for more information:
https://github.com/fabiangreffrath/crispy-doom/releases

Binaries for Windows (x86) are available here:
https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.6.2/crispy-doom-5.6.2-win32.zip

Have a lot of fun!

- Fabian

[Graf Zahl]

On 9/11/2019 at 3:40 PM, Gez said:

 

 

The only thing I can think of that's in common to GZDoom and Classic RBDoom3-BFG but not in common with Choco, Crispy, PrBoom+, Eternity, etc. is that neither CRBD3BFG nor GZDoom use SDL on Windows.

 

I have seen smooth VSync with SDL applications, so that cannot really be the problem. It's more likely that there's something different with the timer in the main loop.

 

[SoDOOManiac]

The Music Pack add-on for Crispy Doom returns, in the form of DLL fix pack!

You can enjoy the fluidsynth soundfont TimGM6mb.sf2 instead of standard MIDI again.

@Lord_Kane It includes the SDL2.dll v2.0.5 and SDL2_mixer.dll v2.0.1 that are linked to libfluidsynth-1.dll and libmodplug-1.dll
with all their respective dependencies and resolve the sound pitch bug present on Windows with SDL2 v2.0.10 and SDL2_mixer v2.0.4 in case of 5.1 speaker configuration.

 

crispy-doom-DLL-fix-pack.zip

Edited September 16, 2019 by Zodomaniac
Updated description and DLL fix pack

[fabian]

@maxmanium The bug you found is fixed in GIT. When restoring a savegame, all map object thinkers are re-created and so the connection between the player's map object and his "sound object" got lost.

 

@Aurelius I can point the bug you found to the OTEX texture pack, but I added a workaround in GIT anyway. The OTEX texture pack contains a SWITCHES lump which defines pairs of "on"/"off" textures for lines which act as switches. However, the "off" texture in one of the pairs is missing from the pack. In Crispy Doom, a missing texture means "no texture" and thus, if a switching linedef has *no* mid texture when it is *off*, it gets assigned the corresponding "on" texture as defined for the missing "off" texture in the SWITCHES lump.

 

These two were fun to fix, more of that! ;-)

[SoDOOManiac]

@Lord_Kane see my post above to fix your issue and get a bonus :)

[Lord_Kane]

5 hours ago, Zodomaniac said:

@Lord_Kane see my post above to fix your issue and get a bonus :)

 

wow thanks!

[SoDOOManiac]

On 9/1/2019 at 10:01 PM, Shon_RT said:

I just tested it, it seems that in version 5.6 and before whenever I hit an exit switch in like in e1m1 for example, the game immediately does the melting effect and shows the level stats whereas in 5.6.1 there's like a half second delay before the melting effect happens. 

Feel free to try my DLLs and see if this issue is mitigated.

[galileo31dos01]

I am experiencing the intercept overflow bug in a map I made while testing on Crispy 5.4. Later checked on 5.6.2. and it also happened a lot. The map seems to be very "defenseless" to the bug for some reason, and since I haven't seen said issue in quite a long time using crispy, I didn't have any proof of it, but now there is!

 

Here's the thread of the map: 

And in lirui1001's post there's the demo showing it. 

[fabian]

@galileo31dos01 What exactly am I supposed to do here? It's a Vanilla limitation that Crispy emulates, so...?

[SoDOOManiac]

4 hours ago, fabian said:

@galileo31dos01 What exactly am I supposed to do here? It's a Vanilla limitation that Crispy emulates, so...?

Well, Crispy is announced as limit-removing port, so shouldn't INTERCEPTS limit be removed?

[galileo31dos01]

7 hours ago, fabian said:

What exactly am I supposed to do here? It's a Vanilla limitation that Crispy emulates, so...?

 

Because it's said in the changes in 5.1 "The INTERCEPTS limit has been removed.", unless it got back in later releases or I misinterpreted what that meant, could you clear it up please?