Crispy Doom 6.0 (Update: Mar 31, 2023)

[kkaden]

Would it be feasible to implement a split-screen multiplayer feature?  Maybe 2 to 6 players, with individual controls like gamepads.

 

I know we have the recent Unity engine Doom with its decent Split-Screen, but that's only for Doom.  I'd like to see support for Heretic, Hexen, and Strife.

 

Hexen64 was so cool, but kinda limited by tech of the day.

[ASON-Z-]

Not sure if its universal or maybe its just me, but Crispy Doom seems to be much more quite compared to Woof,

even on the highest sound volume.

[rfomin]

17 minutes ago, ASON-Z- said:

Not sure if its universal or maybe its just me, but Crispy Doom seems to be much more quite compared to Woof,

even on the highest sound volume.

In the music department it should be the same, but Crispy's sound effects system is slightly different. There was a branch where we replaced the Woof sound system with Crispy, but some users liked the sound of Woof, so we keep it as is.

[Tycitron]

I have a question: What's the difference between "final" and "final2" when using the "-gameversion" command in a .bat? I know the other ones, but i can't find info on that one in particular. 

[fabian]

This emulates an alternate version of the Final Doom executable which fixed the demo4 crash in the demo loop and the teleport behavior. 

[El Juancho]

Im having a problem with music packs, I have downloaded doom and doom II midis in SC-55 in FLAC format and they sound correctly, the only problem is that every time I start a level after half a second the music starts again and it's a bit annoying, I can make a video if necessary. Am I doing something wrong?

[mikeday]

54 minutes ago, El juancho said:

Im having a problem with music packs, I have downloaded doom and doom II midis in SC-55 in FLAC format and they sound correctly, the only problem is that every time I start a level after half a second the music starts again and it's a bit annoying, I can make a video if necessary. Am I doing something wrong?

This is an SDL Mixer bug that is fixed in the newest version. Crispy/Choco haven't picked up SDL Mixer 2.6.1 yet but hopefully soon. In the meantime, I recommend using the OGG version of the music packs. OGG playback does not have the initial hiccup.

Edited August 6, 2022 by mikeday

[El Juancho]

3 hours ago, mikeday said:

This is an SDL Mixer bug that is fixed in the newest version. Crispy/Choco haven't picked up SDL Mixer 2.6.1 yet but hopefully soon. In the meantime, I recommend using the OGG version of the music packs. OGG playback does not have the initial hiccup.

Thank you for the information!

[Hellblazer]

Can Crispy Doom autodetect the IWADs' compatibility levels like PrBoom+? What's the default compatibility in Crispy?

[fabian]

1 hour ago, Hellblazer said:

Can Crispy Doom autodetect the IWADs' compatibility levels like PrBoom+? What's the default compatibility in Crispy?

 

Crispy Doom is always Vanilla Doom 1.9 compatible, but it distinguishes between Doom 2, Ultimate Doom and Final Doom based on the IWAD (or "-gameversion" parameter). So, in PrBoom+ term it supports complevels 2, 3 and 4. 

[Hellblazer]

Right, but what if I placed plutonia.wad in Crispy's directory and just ran the executable? Would it automatically emulate the teleporter bug or should I specifically set the game version to Final Doom in the command line?

[fabian]

If it chooses plutonia.wad as its IWAD, it will automatically emulate the Final Doom executable. 

[PKr]

4 hours ago, Hellblazer said:

Right, but what if I placed plutonia.wad in Crispy's directory and just ran the executable? Would it automatically emulate the teleporter bug or should I specifically set the game version to Final Doom in the command line?

Yes, by default it will emulate the bugged version of Final Doom. To emulate a fixed id anthology edition version of the game you'd need to provide a -gameversion final2 parameter (by default it's "final").

[Hellblazer]

Alright, thank you both for your time!

[bofu]

Quick question - is MBF21 Dehacked support (specifically the MBF21 Bits part, it looks like all the Codepointers and actions I want to use work fine as is) roadmapped at all? It's fine if not — it's just that Crispy Doom is one of the ports I'm targeting for a project, and this will affect whether I put something into it or not.

[fabian]

No, MBF21 support is not planned at all. 

[Zaratul]

Suggestion for native pixel size\1080p resolution. Is that even possible to implement in this port?

[fabian]

No, sorry. Possible, but won't happen. 

[mikeday]

On 8/31/2022 at 12:33 PM, Zaratul said:

Suggestion for native pixel size\1080p resolution. Is that even possible to implement in this port?

Extending the Crispy software renderer to support a 4x or 8x internal resolution would be a good exercise for any aspiring source port author looking to start their own fork. :)

Edited September 1, 2022 by mikeday

[fabian]

Update Sep 01, 2022: Crispy Doom 5.12.0 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.

 

Please visit the Crispy Doom homepage for more information:

https://github.com/fabiangreffrath/crispy-doom/releases/latest

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

https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.12.0/crispy-heretic-5.12.0-win32.zip

https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.12.0/crispy-hexen-5.12.0-win32.zip

 

https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.12.0/crispy-doom-5.12.0-win64.zip

https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.12.0/crispy-heretic-5.12.0-win64.zip

https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.12.0/crispy-hexen-5.12.0-win64.zip

Have a lot of fun!

- Fabian

[Garlichead]

Thanks for the release @fabian. Any chance the -shotdir variable can be added to the source port?

[s4f3s3x]

No MacOs? :(

[mikeday]

16 minutes ago, s4f3s3x said:

No MacOs? :(

I recommend getting Crispy Doom via Homebrew. Indeed, the new version is already pending.

[fran]

3 hours ago, mikeday said:

I recommend getting Crispy Doom via Homebrew. Indeed, the new version is already pending.

 

Meanwhile they can install with brew install --HEAD crispy-doom (but I recommend wait the bottle for 5.12.0)

 

Edit: the bottle for 5.12.0 is already avaible in Homebrew

Edited September 2, 2022 by fran

[PKr]

I always wanted to ask something regarding the automap panning... When in automap mode the panning shows completely different behavior depending on the follow mode. If follow mode is off, panning behaves like the vanilla Doom - it moves all the lines of the map "all at once" without a wobbling effect. If the follow mode is on the panning is wobbly.

 

What exactly is the reason behind this choice? Why can't automap panning behave the same way in follow mode as it does in non-follow mode?

 

P.S. Just to clarify, this is what I was referring to: https://youtu.be/xThKv_TyzyQ

Edited September 4, 2022 by PKr

[HackNeyed]

3 hours ago, PKr said:

I always wanted to ask something regarding the automap panning... When in automap mode the panning shows completely different behavior depending on the follow mode. If follow mode is off, panning behaves like the vanilla Doom - it moves all the lines of the map "all at once" without a wobbling effect. If the follow mode is on the panning is wobbly.

 

What exactly is the reason behind this choice? Why can't automap panning behave the same way in follow mode as it does in non-follow mode?

 

P.S. Just to clarify, this is what I was referring to: https://youtu.be/xThKv_TyzyQ

 

There may be more to it but from the video it looks like with Follow Mode on you are moving the Doomguy thus requiring the position of the map to update and therefore be redrawn with some up-scaling interpolation. So with Follow Mode off the map is stationary and it is the view that pans without having to redraw the position of the map within the "game world".

 

For me it seems to "wobble" in PrBoom-PlusUM/DSDA-Doom and Woof as well but is solid and jumpy/snappy in DosBox and Chocolate-Doom. The question is what kind of interpolation is PrBoom/DSDA/Cripsy/Woof using and is it necessary?

Edited September 5, 2022 by HackNeyed

[mikeday]

3 hours ago, PKr said:

I always wanted to ask something regarding the automap panning... When in automap mode the panning shows completely different behavior depending on the follow mode. If follow mode is off, panning behaves like the vanilla Doom - it moves all the lines of the map "all at once" without a wobbling effect. If the follow mode is on the panning is wobbly.

 

What exactly is the reason behind this choice? Why can't automap panning behave the same way in follow mode as it does in non-follow mode?

 

P.S. Just to clarify, this is what I was referring to: https://youtu.be/xThKv_TyzyQ

I would say this is a bug, not an intentional design decision. Fortunately the fix is pretty is pretty easy:

 

Spoiler

diff --git a/src/doom/am_map.c b/src/doom/am_map.c
index 4354aa6a..c32b52fc 100644
--- a/src/doom/am_map.c
+++ b/src/doom/am_map.c
@@ -1030,8 +1030,8 @@ void AM_changeWindowScale(void)
 void AM_doFollowPlayer(void)
 {
 
-       next_m_x = m_x = (viewx >> FRACTOMAPBITS) - m_w/2;
-       next_m_y = m_y = (viewy >> FRACTOMAPBITS) - m_h/2;
+       next_m_x = m_x = FTOM(MTOF(viewx >> FRACTOMAPBITS)) - m_w/2;
+       next_m_y = m_y = FTOM(MTOF(viewy >> FRACTOMAPBITS)) - m_h/2;
        m_x2 = m_x + m_w;
        m_y2 = m_y + m_h;
 

Good catch!

Edited September 5, 2022 by mikeday

[VoanHead]

Phenomenal work on the new release! These 64 save slots are gonna come in handy since I also make backup save files to the wads I play (you never know when your PC might inexplicably crash and corrupt the main save file, better safe than sorry!). I was also wondering, it's a tiny thing; will Crispy ever have that thing from Woof! where you can choose what specific color messages you wish to have? I don't mean when like you pick up any of the colored keys, I mean like changing the boring red color message from red to green, gold, brick, tan, etc.

[fabian]

3 hours ago, mikeday said:

I would say this is a bug, not an intentional design decision. Fortunately the fix is pretty is pretty easy:

 

Hm, but why does changing coordinate systems back and forth improve panning here? Especially if the change was introduced in a commit titled "Implement smooth automap scrolling":

https://github.com/fabiangreffrath/crispy-doom/commit/d587245e4b5ac8ae6f2cfaf0ae73a9becd4cb459

 

And why isn't Woof affected a well, doesn't it share the same code? 

[Julia Nechaevskaya]

I suspect this is how precise coord system works. Vanilla code "FTOM(MTOF(viewx >> FRACTOMAPBITS))" is preventing walls wobbling by drawing them with logics "one automap pixel is one screen size pixel" which is not really smooth, and also will bring back awful player arrow wobbling while movement. Have a look at Pr+ with 8-bit 640x400 screen resolution (most of interpolation code comes from it) - wobbling is absolutely same.

 

Can it be fixed or improved somehow? Would be nice to know, honestly. We still limited by 640x400 pixels, which is taking it's price: there is simply no way to draw "more pixels" on same zooming level for providing more smooth re-drawing.

 

Also, about "FTOM(MTOF(" have a look how it's drawing diagonal walls or walls in 45° rotate mode. It's really rough.

Edited September 5, 2022 by Julia Nechaevskaya