Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

Crispy Doom 5.10.1 (Update: Mar 24, 2021)

Recommended Posts

8 hours ago, chungy said:

Because without aspect correction enabled, it's assumed the primary purpose is to fill the entire monitor the player is using. We had way more requests for doing that compared to forcing a 16:10 aspect ratio. The latter can still be done by disabling aspect correction and enabling integer scaling.

 

With aspect ratio correction, the only intent is to display Doom as the developers intended it to be displayed, as in 4:3, which causes pillarboxing or letterboxing on monitors that aren't 4:3 (usually pillarboxes as monitors are more often wider than 4:3 rather than taller).

 

Catering to a wrong aspect ratio is not a goal of Chocolate Doom.

But... At the very least, the old behavior results in a less wrong aspect ratio. Compared to this new behavior, which foregoes all forms of aspect ratio by stretching the output to fill whatever resolution is thrown at it.

 

Oh well. I play with the corrected pixel aspect ratio anyway, the original behavior still exists, nothing is actually lost here. Just very weird to make this behavior the one that is available via the setup tool, while the old behavior is stuck behind config-editing.

Share this post


Link to post

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 :(.

Share this post


Link to post
Posted (edited)
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.

Share this post


Link to post
Posted (edited)

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

Edited by VoanHead

Share this post


Link to post

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:

cmake.PNG.7d0ecf64f8e80df79929ed997eb7ecf1.PNG

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)

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

Edited by fabian

Share this post


Link to post
Posted (edited)
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.

Share this post


Link to post

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? 

 

Share this post


Link to post
Posted (edited)
8 hours ago, fabian said:

 

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

 

Edited by Nymz3r : more thoughts

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post
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!

Share this post


Link to post
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!

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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!.

Share this post


Link to post
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?

Share this post


Link to post
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. ;)

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post

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. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×