Crispy Doom 6.0 (Update: Mar 31, 2023)

6 minutes ago, VoanHead said:

So I realize this might come off as a stupid question, but how come Crispy doesn't display the endoom screen? I tried going into the setup executable to see if there's an option to turn it on but there's nothing, tried going into the crispness menu ingame also nothing at all. I understand why you (idk if it's the one guy or small team working on this so I'll say guys) guys might've turned it off, it'll get annoying seeing that pop up and having to manually close it after you finish a session of doom, but I always liked em b/c I'm weird like that :(.

In the Setup exe, click Configure Display, then hit the Advanced tab at the bottom. You can then deselect "Show ENDOOM screen on exit." Same thing in Chocolate Doom.

Ah alright, thank u, now I just feel silly for not looking at that in the first place instead of skimming thru it.

Question for the folks who are building Crispy/Chocolate from source using VS2019. Is it really as simple as using the embedded CMake and passing the library paths through -D command line arguments? It seems like it's working, but I want to make sure I'm not overlooking something.

From the CMake settings dialog:

Hello, I'm new to ports and hope this is the right place. I downloaded Crispy and I noticed only 10 possible options in the "Additional mouse buttons" menu. Is it possible to have more actions be set with mouse buttons?

Also, I noticed that when I hold Strafe On my mouse can move my character left or right. Can you disable this at all? I know I can disable vertical, just not sure if there is a way to disable the horizontal mouse movement with Strafe On though.

Update Mar 24, 2021: Crispy Doom 5.10.1 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.10.1 is released on Mar 24, 2021. It is a minor release containing the accumulated fixes of the past weeks.

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.10.1/crispy-doom-5.10.1-win32.zip

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

Have a lot of fun!

- Fabian

On 2/15/2021 at 7:20 PM, northivanastan said:

I'm on Debian GNU/Linux 10 with Crispy Doom 5.10 (compiled from source), and I can't seem to figure out how to use a custom soundfont. I've so far tried:

• Using a timidity.cfg file with "soundfont /path/to/soundfont" (no music)
• Adding "soundfont /path/to/soundfont" to the existing timidity.cfg file, and using that (music had missing instruments and was from the wrong soundfont)
• Setting the SDL_SOUNDFONTS environment variable to the full path to my soundfont, no Timidity configuration file (no effect, still uses default soundfont)

 

Update over a month later: I've given up on trying to configure Crispy Doom to use a custom soundfont in any "proper" way. I uninstalled the Fluid soundfont, and then copied the SC-55 soundfont to /usr/share/sounds/sf2/FluidR3_GM.sf2. So, when it loads the default soundfont, it loads SC-55 instead of Fluid. It's an ugly solution, but at least Crispy Doom and Eternity Engine are using the SC-55 soundfont now :).

Actually, I think the reason this was such a dealbreaker is because there's something wrong with either my Fluidsynth configuration or the version of the soundfont that I was using. One or two of the instruments sounded way louder than the others, and this didn't happen on my other PC with Fedora which I think also used Fluid. I should probably investigate further, and consider reporting that as a bug if I can find the source.

straight the best port ever!

however when i record demos its behaving wierdly ( strange waving when i turn my mouse ) 

its a total shame and it makes me sad .. forced to use another port to record demos

maybe somebody experiences the same issue? 

33 minutes ago, Nymz3r said:

straight the best port ever!

however when i record demos its behaving wierdly ( strange waving when i turn my mouse ) 

its a total shame and it makes me sad .. forced to use another port to record demos

maybe somebody experiences the same issue? 

 

https://doomwiki.org/wiki/Turning_resolution_is_lowered_when_recording_demos

8 hours ago, fabian said:

 

https://doomwiki.org/wiki/Turning_resolution_is_lowered_when_recording_demos

this explains alot...

arigato

"PrBoom plus additionally has an option to play with reduced turning resolution while not recording, so speedrunners can practice advanced tricks without requiring a demo recording all the time." 

this option seems to be ON by default with PrBoom+ i cant tell the diff when recording or not.

anyway i guess ill get used to it

You can add the "-longtics" parameter while recording to get the full mouse resolution. The demos it outputs aren't vanilla-compatible, but it might serve you well enough.

I have a demo that was formerly recorded in glboom+ on cl-2 which runs perfectly fine in it, but desyncs in crispy for some reason. It's from this wad, a huge resource-intensive limit-removing map and because of performance lag in crispy (or prb's software renderer) I had to use glb+ instead, though the map is 100% playable in crispy. 

The demo in question: 5L1C_01.zip

In crispy, the desync is at 0:47 seconds, a pinky that originally died in three shots doesn't die here so doomguy gets confused and proceeds to hump walls. 

Not sure if this could be a problem in crispy, or the demo itself, or something between crispy and prboom, but I know it's the first time I encountered an issue like this one, since I've always could run crispy demos in prboom (admittedly I never tried to run a vanilla prb demo in crispy...). Is there anything I can do here?

On 3/31/2021 at 10:04 AM, northivanastan said:

Update over a month later: I've given up on trying to configure Crispy Doom to use a custom soundfont in any "proper" way. I uninstalled the Fluid soundfont, and then copied the SC-55 soundfont to /usr/share/sounds/sf2/FluidR3_GM.sf2. So, when it loads the default soundfont, it loads SC-55 instead of Fluid. It's an ugly solution, but at least Crispy Doom and Eternity Engine are using the SC-55 soundfont now :).

 

Actually, I think the reason this was such a dealbreaker is because there's something wrong with either my Fluidsynth configuration or the version of the soundfont that I was using. One or two of the instruments sounded way louder than the others, and this didn't happen on my other PC with Fedora which I think also used Fluid. I should probably investigate further, and consider reporting that as a bug if I can find the source.

I encountered the very same problem on Ubuntu. In addition to setting SDL_SOUNDFONTS to the path to your .sf2 file, you also need to set the environment variable SDL_FORCE_SOUNDFONTS to 1. SDL Mixer will otherwise have Fluidsynth use a default soundfont as you have noted. Apparently the Debian/Ubuntu libsdl2-mixer package is configured with a hard-coded default soundfont path which takes precedence over the SDL_SOUNDFONTS path.

1 hour ago, mikeday said:

 

I encountered the very same problem on Ubuntu. In addition to setting SDL_SOUNDFONTS to the path to your .sf2 file, you also need to set the environment variable SDL_FORCE_SOUNDFONTS to 1. SDL Mixer will otherwise have Fluidsynth use a default soundfont as you have noted. Apparently the Debian/Ubuntu libsdl2-mixer package is configured with a hard-coded default soundfont path which takes precedence over the SDL_SOUNDFONTS path.

Thanks, this seems to have done the trick!

17 hours ago, galileo31dos01 said:

Not sure if this could be a problem in crispy, or the demo itself, or something between crispy and prboom, but I know it's the first time I encountered an issue like this one, since I've always could run crispy demos in prboom (admittedly I never tried to run a vanilla prb demo in crispy...). Is there anything I can do here?

The desync was due to a subtle difference in the BLOCKMAP creation algorithms used by PrBoom+ and Crispy. Thanks for reporting!

A new Truecolor build of Crispy Doom. Based on commit c028707.

TRUECOLOR_crispy-doom-5.10.1-win64.zip

TRUECOLOR_crispy-doom-5.10.1-win32.zip

4 hours ago, fabian said:

 

The desync was due to a subtle difference in the BLOCKMAP creation algorithms used by PrBoom+ and Crispy. Thanks for reporting!

Which one is correct?

11 hours ago, kraflab said:

Which one is correct?

I don't know which is correct, but MBF's version is faster and Eternity uses it for demo_version >= 203.

15 hours ago, kraflab said:

Which one is correct?

I would say, neither one is strictly correct. I mean, if a map comes without a BLOCKMAP lump at all, how do you decide which is the correctly generated one? It is just different algorithms attempting to achieve the same goal, i.e. create a BLOCKMAP lump for a Doom format map.

To provide some historical background:

Some releases ago, I shipped Crispy Doom with a modified copy of id software's original BLOCKMAP building algorithm from the doombsp release, which I extended to remove the BLOCKMAP limit, add support for flipped levels and provide some BLOCKMAP compression. However, since the licensing situation for this code was pretty unclear (and I believe it still is), it became necessary to revert back to using the GPL-licensed algorithm from MBF to allow for Crispy's inclusion into Debian. Apart from the more welcoming license of the MBF code, it also turned out to be factor ~10 faster than id's original implementation. Anyway, when comparing both algorithms I found that I could produce near-identical results with the MBF implementation if I adjusted the blockmap boundaries a little bit just as is done in id's implementation - at least for IWAD maps.

So, I ended up with an implementation in Crispy based on the MBF code but modified to produce results as close as possible to the original doombsp code. However, it wasn't identical to the MBF code anymore. PrBoom+, on the other hand, only uses Boom's algorithm - even for complevel 11 - which isn't identical to MBF's implementation either, but produces near-identical results. Anyway, since everything that PrBoom+ does is considered the-right-thing [tm] nowadays, I bit the bullet and reverted my closer-to-Vanilla change. I will probably even follow suit and replace the MBF algorithm with the implementation from Boom - as was already done in Woof!.

5 hours ago, fabian said:

Anyway, since everything that PrBoom+ does is considered the-right-thing [tm] nowadays, I bit the bullet and reverted my closer-to-Vanilla change. I will probably even follow suit and replace the MBF algorithm with the implementation from Boom - as was already done in Woof!.

Maybe I'm reading this wrong, but wouldn't being vanilla accurate be "the-right-thing [tm]" for a project like this? If the demo desyncs in vanilla, then wouldn't PrBoom+ have to adjust and not Crispy?

4 minutes ago, T.Will said:

Maybe I'm reading this wrong, but wouldn't being vanilla accurate be "the-right-thing [tm]" for a project like this? If the demo desyncs in vanilla, then wouldn't PrBoom+ have to adjust and not Crispy?

This is all about maps that wouldn't even load in Vanilla, because they are missing the BLOCKMAP lump - thus one would have to get generated. Now the question is how, and there isn't only one correct algorithm available for that. But since PrBoom+ is considered to be the de-facto standard for everything beyond Vanilla, it's better to follow suit and do what it does. 

If a demo desyncs between PrBoom+ and your port, people will consider this as a bug in your port. Exactly what has happened here. I can show you complevel 11 demos that desync in MBF but run through in PrBoom+, but who is to blame the latter? Better accept this as a given fact. ;)

I cant seem to be able to alt-tab in fullscreen with the latest Crispy Doom build. when it worked fine in 5.10.0.

12 hours ago, fabian said:

 

This is all about maps that wouldn't even load in Vanilla, because they are missing the BLOCKMAP lump - thus one would have to get generated.

 

That is generally correct, but the WAD that prompted this discussion (5L1C) does have a BLOCKMAP lump, albeit one that's >64K and thus liable to crash vanilla outright or cause weird behavior like the player and monsters noclipping. The WAD does have zero-size SEGS, SSECTORS and REJECT lumps, the last of which I thought was the reason the prb+ demo desynced in Crispy. prb+ has a -set overrun_reject_emulate option for such cases, and the demo linked above was recorded with that option enabled (see the demo footer). So is this really about BLOCKMAP?

Right. So, the map in question has an invalid BLOCKMAP that needs to be rebuilt. Regarding the REJECT lump, Choco and thus Crispy also feature an overflow emulation. 

With the little change in Crispy's BLOCKMAP generation code, the demo runs through - at least beyond the critical point after about 47 seconds. I haven't checked if there are still other issues towards the end, though. 

thank you for continuing with heretic support. i hope some intrepid soul can step into the breach and help out with hexen also. 

Shipping maps without a blockmap and relying on ports to generate a valid one that is to be used for demo playback is an accident waiting to happen.

Boom added bugs to the blockmap handling, so for all prictical purposes one needs to know what port the demo was recorded in to know how to play it back correctly.

It should be noted that blockmaps larger than 65536 bytes ('64'k) are valid in doom 1.9, with some restrictions. Block Rocking Bytes contains an example map with such a blockmap. The size alone should never be used for any assumptions about the blockmap format.

does anyone have experience getting crispy hexen to work on linux? im trying to build it from source and i got hexen to work but i cant compile the binaries to create a setup program for it so i can not change the settings and the vanilla controls make the game unplayable for me anyone who knows how to do it? or is it not supported?

Does it help to rename (or copy) crispy-setup to crispy-hexen-setup?

10 minutes ago, fabian said:

Does it help to rename (or copy) crispy-setup to crispy-hexen-setup?

it worked thanks

I just wanna share this:

(In other words, I made a thing!)

Yay! (Sorry, but it's "Crispness": https://en.wikipedia.org/wiki/Crispiness#Other_meanings_of_crispness_but_not_crispiness)