Crispy Doom 6.0 (Update: Mar 31, 2023)

You need to use the Unity version of the IWADs.

https://bethesda.net/en/game/doom-widescreen-mods

You will need Slade3 to convert the PNGs to standard Doom graphics, and to create your own PWADs. Should you need further help, ask in the Doom Editing subforum.

13 hours ago, Master O said:

 

how do you get colors to display while using code?

By using one of the options (e.g. CSS) that offer syntax highlighting.

On 1/27/2021 at 2:46 PM, chungy said:

You need to use the Unity version of the IWADs.

I tried using the unity wads but didn't notice a difference. I might just try to use slade3.

I have an issue where the music skips/repeats for a moment a few seconds after looping (using an .OGG music pack), present in both an old build I was using and a fresh install of the latest build. Everything else seems to function properly, and I haven't found this issue with other source ports. Is this more likely to be a problem with the port/how I've set it up, or with my PC/Windows?

On 2/11/2021 at 12:19 AM, Jakura said:

I have an issue where the music skips/repeats for a moment a few seconds after looping (using an .OGG music pack), present in both an old build I was using and a fresh install of the latest build. Everything else seems to function properly, and I haven't found this issue with other source ports. Is this more likely to be a problem with the port/how I've set it up, or with my PC/Windows?

Don't worry, it's not your setup. This is a known issue with Choco/Crispy. It bothered me too, so I decided to poke around the code to see what it would take to fix it. I found that the best way to do so was to add native support for the the ZDOOM-style looping tags to SDL_Mixer. Some time ago I submitted this as a patch to SDL_Mixer and it was accepted. Whenever there's a new official release of SDL_mixer (it has been a while!) this issue can be fixed. 

How difficult is it to actually configure that Timidity?

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)

On 2/13/2021 at 11:44 AM, mikeday said:

Don't worry, it's not your setup. This is a known issue with Choco/Crispy. It bothered me too, so I decided to poke around the code to see what it would take to fix it. I found that the best way to do so was to add native support for the the ZDOOM-style looping tags to SDL_Mixer. Some time ago I submitted this as a patch to SDL_Mixer and it was accepted. Whenever there's a new official release of SDL_mixer (it has been a while!) this issue can be fixed. 

Thanks for the reply. I think I might've caught wind of that while doing my own research, so I'm glad to have it confirmed. I'm not an expert when it comes to configuration, so I never found my own solution.

I don't know if this is a known bug, but when I play with uncapped framerate enabled the archvile's flame doesn't render properly; most of its frames get skipped and it's thus mostly not visible for most of its duration.

2 hours ago, StupidBunny said:

I don't know if this is a known bug, but when I play with uncapped framerate enabled the archvile's flame doesn't render properly; most of its frames get skipped and it's thus mostly not visible for most of its duration.

You have been bitten by this:

https://doomwiki.org/wiki/Arch-Vile_fire_spawned_at_the_wrong_location

The Ass-Vile's fire is spawned in the wrong sector and then its vertical position is adjusted between its (invalid) spawn sector's floor and ceiling and the player's z coordinate during alternating tics. However, instead of being present either "here" (i.e. between the sector's bounds) or "there" (i.e. on the player's height) vertically, the uncapped framerate code attempts to interpolate its position and thus it is always somewhere in between.

I once had a fix for this in the port, but it lead to demos desyncing (8 out of ~9500 that were tested) and was thus removed once again:

https://github.com/fabiangreffrath/crispy-doom/issues/484

https://github.com/fabiangreffrath/crispy-doom/issues/318

IIRC I seem to recall axdoomer supposedly managed to find a way to fix it without breaking demos, but no idea what happened with it since.

'ass-vile' lol

On 1/18/2021 at 5:24 PM, maxmanium said:

Doesn't even have to be BEX -- here's a vanilla-format .deh patch with just those changes. Just happens in Crispy -- it probably has to do with the code handling the bobbing-while-firing settings.

I just fixed this, thanks for the report!

I registered here to ask this question. I couldn’t find an answer anywhere so i hope to find a solution this way.

it seems Crispy has to autoload nerve.wad and/or masterlevels.wad when running Doom2.wad.

So when you run the game, you get the option to choose between these ‘episodes’ in the main menu. Before selecting the difficulty.

I cannot get this done. I have nerve/masterlevels.wad in the same folder as doom2.wad & use the latest Crispy version.

Does anyone know how to fix this?

I love this sourceport and i think it is the best out there!.

23 minutes ago, Timmer83 said:

I registered here to ask this question. I couldn’t find an answer anywhere so i hope to find a solution this way.

 

it seems Crispy has to autoload nerve.wad and/or masterlevels.wad when running Doom2.wad.

So when you run the game, you get the option to choose between these ‘episodes’ in the main menu. Before selecting the difficulty.

 

I cannot get this done. I have nerve/masterlevels.wad in the same folder as doom2.wad & use the latest Crispy version.

 

Does anyone know how to fix this?

 

I love this sourceport and i think it is the best out there!.

 

 

 

The Episodes thing for Doom 2 only happens when wads named NERVE.wad or MASTERLEVELS.wad are in the same folder as the DOOM2.wad loaded into Crispy Doom. Either move the wads to a different folder or just rename them.

I decided to build the Truecolor variants of Crispy Doom in case anyone wanted to try them out.

Based on commit 2c4ad31

truecolor-crispy-doom-5.10.0-win64.zip

truecolor-crispy-doom-5.10.0-win32.zip

Just moving this into the Crispy thread since it's more relevant here, didn't want to derail the Marshmallow thread!

On 2/21/2021 at 3:26 PM, Lollie said:

20 hours ago, fabian said:

Ah, this! Yes, I re-introduced this bug because the "fix" wouldn't let me use Win+Left/Right on my Doom windows anymore. I'll try to find a better solution.

...I was totally unaware of this Windows shortcut for pinning windows to the corners of the screen, and now I see the problem that the new behavior causes. When pinning the window to the screen corner, Marshmallow tries to recalculate its window size based on the chosen aspect ratio, and it resizes itself beyond the current monitor's screen boundaries. In comparison, Crispy correctly pins itself to the screen corners. That's a fun trick, Windows.

One idea that comes to mind (assuming Windows doesn't break this): Maybe one of Crispy's window dimensions could be forced to be always consistent when it's resizing itself, and then you do a test between three things:

• The current monitor's screen resolution
• Crispy's window position on the current monitor
• Crispy's new calculated window size

If Crispy's new window size extends outside the current monitor's screen boundaries, bump Crispy's window position so that it fits back inside the screen. (And then, if Crispy's window simply won't fit the monitor's resolution, forcibly resize the larger dimension until the window fits)

10 hours ago, T.Will said:

The Episodes thing for Doom 2 only happens when wads named NERVE.wad or MASTERLEVELS.wad are in the same folder as the DOOM2.wad loaded into Crispy Doom. Either move the wads to a different folder or just rename them.

OK now it works out! Many thanks :-)

4 hours ago, Lollie said:

One idea that comes to mind (assuming Windows doesn't break this): Maybe one of Crispy's window dimensions could be forced to be always consistent when it's resizing itself,

This is more or less exactly what I added just yesterday: ;)

https://github.com/fabiangreffrath/crispy-doom/commit/2c4ad31e9a04bd67abbbc8a98f61c9d87cc858e1

15 hours ago, T.Will said:

I decided to build the Truecolor variants of Crispy Doom in case anyone wanted to try them out.

This reminded me I never did get around to testing the Heretic style smooth map line code in truecolor mode. Whoops!

Fortunately it was an easy enough fix.

That automap screenshot actually looks kinda creepy. It's almost like an eye staring into you.

I WANT IT!

Quick question, does this source port support multiplayer and how bad/good is it?

1 minute ago, Kool Belzero said:

Quick question, does this source port support multiplayer and how bad/good is it?

It does support multiplayer. It's basically like the one in the original Doom, although I'd guess that it functions under modern standards. We used to record demos together with a friend, and while there was some sort of input delay during the first second or so of gameplay, I'd say it was a decent experience, although keep in mind that I personally don't have the greatest ping, and we live far away from each other, and I repeat, this was for demo recording, not casual gameplay.

1 minute ago, Alaux said:

It does support multiplayer. It's basically like the one in the original Doom, although I'd guess that it functions under modern standards. We used to record demos together with a friend, and while there was some sort of input delay during the first second or so of gameplay, I'd say it was a decent experience, although keep in mind that I personally don't have the greatest ping, and we live far away from each other, and I repeat, this was for demo recording, not casual gameplay.

Good to know, can you point me towards a tutorial on how to set things up?

1 minute ago, Kool Belzero said:

Good to know, can you point me towards a tutorial on how to set things up?

https://www.chocolate-doom.org/wiki/index.php/Multiplayer

This should apply just fine to Crispy, since it is a fork of Chocolate after all. In my case, where I wasn't the host, all I had to do was use the -connect parameter, and that's about all. When I tried hosting, however, I did go through issues with port forwarding, but leaving that aside I'd assume it's also as simple as connecting.

@fabian I tried the last build and there is still a graphical bug with a status bar background. There is also an earnest request to replace the "High Resolution Rendering" option (really, who needs "off" for that there is Chocolate Doom) with another "Aspect Ratio Correct" option with the values 4:3, 16:10 and "off", because when toggling "Widescreen Aspect Ratio" setting I get this. And you won't need to go into the config to set the pixel perfect aspect ratio.

On 2/23/2021 at 3:03 AM, T.Will said:

I decided to build the Truecolor variants of Crispy Doom in case anyone wanted to try them out.

 

Based on commit 2c4ad31

truecolor-crispy-doom-5.10.0-win64.zip

 

truecolor-crispy-doom-5.10.0-win32.zip

Man, thanks a lot! This is exactly what I need - truecolor and no image tearing when you turn the camera quickly! @fabian Please include these fixes in the new release!

9 hours ago, MAJ said:

@fabian I tried the last build and there is still a graphical bug with a status bar background.

This is a part of the bezel that surrounds the player view for all other screen sizes. People have asked to specifically add this back for consistency reasons. 

Quote

There is also an earnest request to replace the "High Resolution Rendering" option (really, who needs "off" for that there is Chocolate Doom)

This is a joke, right? 

Quote

with another "Aspect Ratio Correct" option with the values 4:3, 16:10 and "off", because when toggling "Widescreen Aspect Ratio" setting I get this. And you won't need to go into the config to set the pixel perfect aspect ratio.

You won't get widescreen rendering without aspect ratio correction. Because without it, Doom isn't rendered in widescreen, but just plain wrongly. 

5 hours ago, MAJ said:

Man, thanks a lot! This is exactly what I need - truecolor and no image tearing when you turn the camera quickly! @fabian Please include these fixes in the new release!

There is no fix applied. These variants have just been created using different non-standard build time options. Screen tearing should be mitigated by enabling Vsync, which is already available for the 8-bit renderer and even enabled by default. 

15 hours ago, MAJ said:

There is also an earnest request to replace the "High Resolution Rendering" option (really, who needs "off" for that there is Chocolate Doom) with another "Aspect Ratio Correct" option with the values 4:3, 16:10 and "off", because when toggling "Widescreen Aspect Ratio" setting I get this. And you won't need to go into the config to set the pixel perfect aspect ratio.

Regarding the screenshot, what were you expecting to see after toggling Widescreen Aspect Ratio? Do you want the status bar to be scaled up so that it fills the width of the screen?

Also, why would you need a second option for aspect ratio? Are you talking about the window's aspect ratio (4:3, widescreen, etc)? Or are you talking about pixel aspect ratio (force Crispy to render tall pixels)?