Crispy Doom 6.0 (Update: Mar 31, 2023)

[LincolnPark96]

@Charlie Love How can i disable the episode names? Every time i delete the folders and reinstall crispy doom, still show me the episodes.

[Charlie Love]

16 minutes ago, LincolnPark96 said:

@Charlie Love How can i disable the episode names? Every time i delete the folders and reinstall crispy doom, still show me the episodes.

If you aren't using the -episodemode parameter my crispy-doom.exe won't do anything. Are you talking about No Rest for the Living and The Master Levels? Those pop up when the corresponding wads are found in the same directory as Doom2.wad which already an automatic feature of Crispy before I fulled around with it.

Edited October 6, 2020 by Charlie Love

[LincolnPark96]

Yeah, still show me NRFTL and Master levels, even if i use pwads like Epic 2, wich is very annoying. I´m using DOOMWADDIR and DOOMWADPATH, so i don´t have to copy my wads in every source port´s folder.

[Charlie Love]

30 minutes ago, LincolnPark96 said:

Yeah, still show me NRFTL and Master levels, even if i use pwads like Epic 2, wich is very annoying. I´m using DOOMWADDIR and DOOMWADPATH, so i don´t have to copy my wads in every source port´s folder.

I personally solve this by having a wad friendly isolation folder with secondary copies of Doom, Doom2, TNT, and Plutonia in it. I then select the (Demo/WAD) friendly versions through ZDL or ZDL script when using other PWADs (or TNT and Plutionia, because I don't like that they grab NRFTL and ML at all).

Edited October 6, 2020 by Charlie Love

[braders1986]

Is it possible to have the border edge visible by default, like other source ports ? 

I actually think the edge looks more vanilla than the abrupt cut-off in Crispy. The recent Unity wrapped DOOM keeps it, and it does make everything look a little cleaner.

 

Crispy

 

GZdoom and others

[fabian]

19 hours ago, Coincident said:

However, at the moment of this writing, Crispy Doom does not seem to do this. The removal/insertion of the Map07 intermission screen is the culprit when it comes to desyncs of course. 

 

Both PrBoom+ and Crispy are supposed to behave *exactly* like Vanilla Doom when recording or playing back demos. This includes ommitting of all special casing regarding map transition and placement of finale text screens between maps (this is why all the `singleplayer` checks were introduced in the first place). If Vanilla would show the text screen before MAP07 and Crispy does the same but PrBoom+ doesn't, than I'd say the bug is in the latter.

 

[Keyboard_Doomer]

Hello,

a member of DSDA team joining in since we discussed this issue before Coincident posted here.

I don't think the argument really holds up when it comes to NRFTL. It is a limit-removing wad so the vanilla (i.e. doom(2).exe) behavior is to crash. As far as NRFTL goes the vanilla (i.e. "unaltered") behavior is the executable which it came with in which there's no intermission text screen before MAP07.

 

Additionally, if you want to insist that during demo recording/playback the behavior should be exactly as vanilla, while this is not the requirement while not recording, that means the secret exit in MAP04 can freely go to MAP09 while not recoding (as it already does in Crispy and PrBoom+) but must go to MAP05 while recording. Same issue with the MAP09 exit going to either MAP05 or MAP10. That seems like a ridiculous and confusing side effect from following a requirement that doesn't even make sense to apply in the context.

 

As an aside, it was funny to read who is credited with adding the code that removes the text screen in PrBoom+ :D https://github.com/coelckers/prboom-plus/commit/7068da99fe5b2db2b1a28b3bcf98acf4638e4fc1

 

 

edit: Well, turns out that the vanilla behavior for exiting through a secret exit outside of the designated maps is to just give up and go to MAP01 but the argument stays the same.
 

Edited October 7, 2020 by Keyboard_Doomer

[Taskster]

Is there a way to import the original instrumental Doom soundtrack into the game instead of using midi, fluidsynth, or other digital sounds effects?

[braders1986]

44 minutes ago, Taskster said:

Is there a way to import the original instrumental Doom soundtrack into the game instead of using midi, fluidsynth, or other digital sounds effects?

DOOM was composed on a Roland Sound Canvas 55.

The MIDI's ARE the original. Everything that come after is just a rendition.

 

If you mean the sound packs, then you can look here for them http://sc55.duke4.net/

 

Edited October 7, 2020 by braders1986

[fabian]

22 hours ago, Keyboard_Doomer said:

I don't think the argument really holds up when it comes to NRFTL. It is a limit-removing wad so the vanilla (i.e. doom(2).exe) behavior is to crash. As far as NRFTL goes the vanilla (i.e. "unaltered") behavior is the executable which it came with in which there's no intermission text screen before MAP07.

 

Following your argumentation it would make no sense either for PrBoom+ to enable the behaviour of MBF when playing e.g. Eviternity, because MBF.exe would also simply crash when loading some of its maps, but well...

 

22 hours ago, Keyboard_Doomer said:

Additionally, if you want to insist that during demo recording/playback the behavior should be exactly as vanilla, while this is not the requirement while not recording, that means the secret exit in MAP04 can freely go to MAP09 while not recoding (as it already does in Crispy and PrBoom+) but must go to MAP05 while recording. Same issue with the MAP09 exit going to either MAP05 or MAP10. That seems like a ridiculous and confusing side effect from following a requirement that doesn't even make sense to apply in the context.

 

Yes, it is already like this in both Crispy and Prboom+. The special map transition for NRFTL is simply ignored when recording or playing back demos, which is inconsistent and unfortunate, granted, but exactly what we agreed upon when implementing support for this episode in PrBoom+ back then.

 

22 hours ago, Keyboard_Doomer said:

As an aside, it was funny to read who is credited with adding the code that removes the text screen in PrBoom+ :D https://github.com/coelckers/prboom-plus/commit/7068da99fe5b2db2b1a28b3bcf98acf4638e4fc1

 

Indeed! But this commit also shows that it was an oversight not to add another `singleplayer` check to the code. It is obvious that a text screen was meant to be shown after MAP08 *only* for NRFTL and only in singleplayer games (i.e. no demo recording, no demo playback, no network game) and as usual (including after MAP06) *else*.

 

Anyway, I have introduced this mistake more than 6 years ago and now it's there in the reference port for demo compatibility. I can only offer to either fix it in PrBoom+ now the way it was meant to be back then - or adjust Crispy to the same behaviour, although this would still be inconsistent with the way all the other special treatments for NRFTL are ommitted during demo recording and playback.

 

[Alaux]

Hey there. Is it possible to get Crispy to use a custom SF2/DLS file for MIDI playback with any of the Music types?

I'm pretty sure it isn't, and if so, how likely is it to implement this functionality? I have zero knowledge about this, but I'm thinking about some sort of switch between using the Windows GS Wavetable Synth (as it does currently I believe) and a custom playback device which allows custom soundfonts, in order to keep things working as they do now while also including this option for users like myself.

 

Whatever the case, great job with the port!

[Keyboard_Doomer]

3 hours ago, fabian said:

Following your argumentation it would make no sense either for PrBoom+ to enable the behaviour of MBF when playing e.g. Eviternity, because MBF.exe would also simply crash when loading some of its maps, but well...

I really shouldn't have even mentioned the part about crashing but really my point is that NRFTL is an official release that never was compatible with the original exes so there's no sensible reason to refuse special handling in favor of vanilla compatibility that never existed.
 

3 hours ago, fabian said:

The special map transition for NRFTL is simply ignored when recording or playing back demos, which is inconsistent and unfortunate, granted, but exactly what we agreed upon when implementing support for this episode in PrBoom+ back then.

I don't know what were the reasons that lead to such an agreement but it seems strange such a behavior would be chosen as preferable. As we discussed this among people involved with DSDA it was unanimous that there should be special handling for NRFTL that would also be active during demo recording/playback. The alternative is confusing behavior that also leads to the original wad being unusable for multi-level runs involving the secret map and requiring a patched wad just for this single purpose. I can't think of a practical benefit of avoiding the special handling of NRFTL. Such behavior seems outright broken.

 

As it is, it's true that the PrBoom+ behavior is inconsistent and should be fixed. It might need renewing the discussion among developers but taking these actions seems preferable for demo recording:

- MAP04 secret exit should lead to MAP09 and MAP09 exit should lead to MAP05. Both while recording and while not recording. This would need to be amended in both PrBoom+ and Crispy Doom.
- Showing or not showing the text screen before MAP07 should be consistent between the ports. Considering that not showing it is the original behavior it would be preferable if Crispy Doom removed it.
 

[plums]

7 hours ago, Alaux said:

Hey there. Is it possible to get Crispy to use a custom SF2/DLS file for MIDI playback with any of the Music types?

Doomkid wrote instructions on how to use soundfonts with Doom on Windows, by installing Virtual MIDI Synth:

https://www.doomworld.com/forum/topic/115541-tutorial-using-soundfonts-for-doom-midi-music/

 

Later in that thread I give instructions to do it in Linux by setting some SDL2 parameters:

https://www.doomworld.com/forum/post/2155763

The Linux method will also work for Windows in case you don't want to use Virtual MIDI Synth (I'll update them later today; basically it's the same except you need libfluidsynth.dll if you don't have it, and set SDL_SOUNDFONTS as an environment variable) but I'd recommend using VMS because it's a lot more flexible and doesn't have the problems that the SDL2 option has.

Edited October 8, 2020 by plums

[Charlie Love]

L/GZDoom's ability to grab virtual midi for audio levels is certainly a pretty nice feature. I wouldn't mind that becoming the standard in source ports. 

Edited October 8, 2020 by Charlie Love

[Charlie Love]

Good work on the widescreen asset update. I've made some wad patches from the widescreen assets iD released to the public for those that don't want to use the Unity versions of the iwads. The name of the zip is kind of misleading, because these allow you to go to 21:9.

Converted Unity Wads.zip

 

Edited October 9, 2020 by Charlie Love

[M_W]

5 minutes ago, Charlie Love said:

Good work on the widescreen asset update. I've made some wad patches from the widescreen assets iD released to the public for those that don't want to use the Unity versions of the iwads.

Converted Unity Wads.zip

You got it to work? I tried myself, but even with setting the offsets on the graphics I still got the whole thing confined to a 4:3 square in the middle of the screen...

[Charlie Love]

31 minutes ago, M_W said:

You got it to work? I tried myself, but even with setting the offsets on the graphics I still got the whole thing confined to a 4:3 square in the middle of the screen...

I've uploaded a compiled version of the latest code (it's a personal copy so also has the episode mode stuff too, but that's ignorable). It should just work.

Edit: Can confirm works with the widescreen updated wads from the Unity port as well.

 

crispy-doom - widescreen update.zip

Edited October 9, 2020 by Charlie Love

[Alaux]

@plums I had already watched Doomkid's video when it first came out, and I did try VMS but it just didn't convince me, albeit having barely any issues (although not being able to control music volume from Crispy itself is quite annoying), but looking back at it, it seems to be the best option.

 

Still, I want to try the "Linux" method to see how it goes. I think the only thing missing is the dll, of which I found two variants: "libfluidsynth64.dll" in GZ 4.4.0 and "libfluidsynth-2.dll" in a FluidSynth build I downloaded from GitHub. Would those work? If so, where exactly do I place them?

 

Thanks in advance.

[plums]

3 hours ago, Alaux said:

Still, I want to try the "Linux" method to see how it goes. I think the only thing missing is the dll, of which I found two variants: "libfluidsynth64.dll" in GZ 4.4.0 and "libfluidsynth-2.dll" in a FluidSynth build I downloaded from GitHub. Would those work? If so, where exactly do I place them?

libfluidsynth-2.dll might work, if not try getting PrBoom+UM from here and copying its lilbfluidsynth.dll. You put them in the same folder as the Crispy Doom exe. (Sorry I can't test this out myself right now.)

[braders1986]

Is there work on restoring controller input happening ?

 

Not sure how many controller/couch players there is (most likely a lot these days), but in my opinion, this is an issue that I would absolutely put as top priority to fix, before working on any other smaller fixes, or new implementations.

 

It's a make or break issue to a lot of players. Yes, you can just use an older version (very old) of Crispy, but then you would be better off using another port all together as you're missing a lot of new qol features and fixes.

Edited October 12, 2020 by braders1986

[M_W]

I'll admit it's not something I thought about much until I started playing with someone who has issues with pain on mouse and keyboard, and reading plenty of threads here on DW since, he seems to not be alone. Mapping a WASD to joystick in Doom is a miserable experience. Even building more advanced macros in antimicro that engage the run button after hitting a certain threshold is still barely playable.

[plums]

5 hours ago, braders1986 said:

Is there work on restoring controller input happening ?

 

Do you know if Chocolate Doom has the same issues? I assume it does and so that's where the fix needs to happen.

[M_W]

1 hour ago, plums said:

Do you know if Chocolate Doom has the same issues? I assume it does and so that's where the fix needs to happen.

It does. Someone mentioned its a bug inherited from SDL 2.0.9 and later, but I cannot confirm that, myself. The developer of RUDE (sorry I can't remember your name!) I think said something about compiling his port with 2.0.8 in the meantime. Again, cannot confirm any of this myself.

[drfrag]

I compile RUDE with 2.0.8 and controllers work, you can check for yourself.

https://github.com/drfrag666/RUDE/releases/download/3.1.0pre10c/RUDE-3.1.0pre10c-win32.zip

[M_W]

Thank you! Sorry I forgot your name :(

[Smite of Disrespect]

On 10/9/2020 at 11:43 AM, Charlie Love said:

crispy-doom - widescreen update.zip

I downloaded this and it doesn't work. I renamed my original Crispy executable as crispy-doom-bak as a backup, and put this new one in the folder and it doesn't work. I get this error message:
 

Spoiler

 

Edit: I thought maybe it's because it's looking for Doom.wad and nerve.wad for the episode selection but it still fails even with those wads in the folder

Edited October 13, 2020 by RonnieColeman

[Charlie Love]

1 hour ago, RonnieColeman said:

I downloaded this and it doesn't work. I renamed my original Crispy executable as crispy-doom-bak as a backup, and put this new one in the folder and it doesn't work. I get this error message:
 

  Reveal hidden contents

 

Edit: I thought maybe it's because it's looking for Doom.wad and nerve.wad for the episode selection but it still fails even with those wads in the folder

Only thing I can think of is maybe the other files are older. This is built off of 5.9.2 so there are some assumptions there. You could just try with the most up to date official release instead. It should have the widescreen update included now.
http://latest.chocolate-doom.org/

Edited October 13, 2020 by Charlie Love

[wrkq]

It may also be mix of 32-bit and 64-bit stuff.

[Charlie Love]

8 minutes ago, wrkq said:

It may also be mix of 32-bit and 64-bit stuff.

Ah, you're right didn't think of that. My stuff is compiled 32-bit so that could create issues. (I could have gone higher but I was having some issues getting MSYS2 to work properly)

Edited October 13, 2020 by Charlie Love

[invictius]

Why is this port taking up a fraction of my screen?  It doesn't come up in screenshots, the status bar is fine but the gameplay area takes 30-50% of the screen.