Crispy Doom 6.0 (Update: Mar 31, 2023)

[Spectre01]

With the recent widescreen support, is there a particular reason to hold back on supporting native HD monitor resolutions?

[Noiser]

I have to be honest, Crispy Doom is my favorite port and part of the appeal for me is how it still preserves some retro look, while adding all the quality-of-life stuff. The majority of ports cover the HD crowd already. 

Most importantly, mappers who prefer this visual style can indicate Crispy for people who want to play their maps as the author intended.

Edited March 6, 2020 by Noiser

[chungy]

56 minutes ago, Spectre01 said:

With the recent widescreen support, is there a particular reason to hold back on supporting native HD monitor resolutions?

To make it run with reasonable performance, the game renderer would have to be swapped out in favor of an OpenGL or Vulkan renderer. Crispy as it is now only renders to a relatively low-res surface using the traditional software rendering, which then gets scaled via hardware acceleration (eg, on a GL surface).

[Spectre01]

Is there a difference between the Crispy and PRBoom+ software renderers? The latter supports high resolutions while still maintaining good performance on all but the craziest of maps (in which case GLBoom+ performs better).

[Grizzly]

3 hours ago, Spectre01 said:

With the recent widescreen support, is there a particular reason to hold back on supporting native HD monitor resolutions?

I'd like to point out that even Chocolate Doom natively supports HD monitor resolutions, it does all its upscaling magic in the program and outputs at your monitors native resolution :P

 

2 hours ago, Spectre01 said:

Is there a difference between the Crispy and PRBoom+ software renderers? The latter supports high resolutions while still maintaining good performance on all but the craziest of maps (in which case GLBoom+ performs better).

 

 

I found this highly dependant on the system I'm running it on. The PRBoom+ renderer is faster then Crispy Doom is at the same resolutions (or well, at 640*480, which is closest to Crispy Doom's internal one), even though that might just be down to PrBoom letting my drivers handle the upscaling rather then Crispy Doom's much neater upscaling. However, when you tell it to run at widescreen resolutions, it does slow down considerably. Moving from 640*480 to 720p cuts performance from 600 to 300 fps, and then from 720p to 1440p it cuts performance to 100 fps (using the Sigil demo as a testing bed here). This is, for most computers, still perfectly acceptable since its well above the 60fps mark (for me it isn't becuase I have a 144hz screen, but 720p+screen multiplication factor at 2 runs smooth as butter).

 

But that's on an AMD Ryzen 2600. My laptop, which runs a mobile Celeron variant from 2012, absolutely hitches when it tries to handle Prboom+ rendering at 1366*768, where performance oscilates between 30 and 60 fps. And annoyingly, Prboom+ doesn't actually support much lower 16:9 resolutions. I can try setting it to 1280*720 but that doesn't improve things much (if at all), and anything lower means I have to deal with black bars or tell Intel to stop bothering with aspect ratio correction. Meanwhile, Crispy Doom runs at more then 100 fps at all times. Why? Becuase Crispy only asks the processor to render at 640*400 (or whatever the internal resolution for widescreen rendering is) and then asks the iGpu to upscale it. PrBoom+ tells my processor to do all the work and it can't.

[VGA]

In other words Crispy renders at native or 2xnative, depending on your options and upscales to your native resolution. While when you set prboom+ to your resolution it renders at that (high) resolution and has low performance on some maps.

 

Also, prboom+ is the software renderer and scales badly as resolution increases. Glboom+ is the hardware renderer and is faster usually, even at high resolutions.

[seed]

5 hours ago, VGA said:

In other words Crispy renders at native or 2xnative, depending on your options and upscales to your native resolution. While when you set prboom+ to your resolution it renders at that (high) resolution and has low performance on some maps.

 

Also, prboom+ is the software renderer and scales badly as resolution increases. Glboom+ is the hardware renderer and is faster usually, even at high resolutions.

 

You can toggle between renders in GlBoom+.

 

At any rate, true high resolution support is something I would've loved to see in Crispy too.

Edited March 7, 2020 by seed : Can't type these days...

[Spectre01]

Regarding the performance discussion, I compared the bonus version of Hellbound map29 between Crispy and PR/GLBoom+ 2.5.1.7um. The version of the map in the main wad is already very demanding, and this optional one is a rather extreme case.

 

Spoiler

Note the FPS shown in the corners.

Crispy in low-resolution (widescreen) mode:

 

Crispy in "high resolution" (widescreen) rendering mode:

 

PRBoom+ at 720p (1366x768):

 

GLBoom+ at 720p (1366x768):

 

As you can see, PRBoom+ in software mode managed to achieve the highest FPS (77) while looking at the centre of this massive outdoor map. And that's with me running 2 forms of anti-aliasing (SMAA and FXAA) on it.

[VGA]

You didn't mention your hardware.

[fabian]

15 hours ago, Spectre01 said:

With the recent widescreen support, is there a particular reason to hold back on supporting native HD monitor resolutions?

Nope, there won't be any higher resolution rendering, sorry. 

[seed]

2 hours ago, VGA said:

You didn't mention your hardware.

 

I don't think it's even relevant here, they're both more simple engines that use GL 2.1.

 

@Spectre01 Now hold on a sec. PrBoom is faster than GlBoom running the SW render? Or is that the more extreme version of the map?

 

Also:

 

9 hours ago, Spectre01 said:

2.5.1.7

 

*sad noises*

[plums]

10 hours ago, Spectre01 said:

software mode

anti-aliasing

 

Unless I'm missing something, AA does nothing in software mode?

[Spectre01]

8 hours ago, VGA said:

You didn't mention your hardware.

Yeah, that might've been helpful to include. :P

GPU: nVidia 1060 (3GB) CPU: AMD 2600X RAM: 8GB

 

6 hours ago, seed said:

Now hold on a sec. PrBoom is faster than GlBoom running the SW render? Or is that the more extreme version of the map?

Yes, I was surprised too. All comparison's are on the more extreme version included in HBFM29.wad. I just checked 2.5.1.5, and GL mode is giving me ~75FPS in the same spot, compared to ~50 in 2.5.1.7, from the compiled version you posted. Software performance is identical though.

 

5 hours ago, plums said:

Unless I'm missing something, AA does nothing in software mode?

Correct, normally AA does not work but post-processing AA does. I used to apply FXAA through the nVidia options but currently run SMAA + FXAA through ReShade for the superior quality. This makes it possible to have software mode at native resolution while eliminating any geometrical and individual pixel aliasing 

[seed]

12 minutes ago, Spectre01 said:

Yes, I was surprised too. All comparison's are on the more extreme version included in HBFM29.wad. I just checked 2.5.1.5, and GL mode is giving me ~75FPS in the same spot, compared to ~50 in 2.5.1.7, from the compiled version you posted. Software performance is identical though.

 

:3.

 

That's roughly a 20% difference, and I think I know exactly what happened there.

 

Andrey's port was always compiled with an Intel compiler, which gave the port quite a bit of boost in terms of performance, particularly on Intel CPUs. Sadly though, none of us have access to the tool, which last I checked, is actually very expensive. As a result, UBoom will always be slightly slower compared to Andrey's, and I don't think there's anything to do to improve the situation here.

[Spectre01]

@seed Good news! It appears ReShade was the performance culprit in OpenGL, despite me turning off all features. I have extensively tested both versions and, on my end, performance in software and gl modes of 2.5.1.5 and 2.5.1.7 is almost identical when it comes to handling complex geometry. And with that, I can stop derailing this Crispy thread. :P And hopefully this cleared up any misconceptions about Software being too slow at higher resolutions, as PRBoom+ shows that it's not the case.

[VGA]

23 minutes ago, Spectre01 said:

@seed Good news! It appears ReShade was the performance culprit in OpenGL, despite me turning off all features. I have extensively tested both versions and, on my end, performance in software and gl modes of 2.5.1.5 and 2.5.1.7 is almost identical when it comes to handling complex geometry. And with that, I can stop derailing this Crispy thread. :P And hopefully this cleared up any misconceptions about Software being too slow at higher resolutions, as PRBoom+ shows that it's not the case.

You didn't test in a high resolutio,n though!

[Spectre01]

37 minutes ago, VGA said:

You didn't test in a high resolutio,n though!

I would if I could! But I like my budget 18.5" monitor from 2012. 720p is good enough for me! :P

[themaniacboy]

So, I just downloaded the latest version and when I play it something funny happened:

 

Anyways, any idea how I can fix this?

I already tried to mess with some settings and deleted everything to start over, but the results are still the same.

[seed]

Is that the cartoony sounds bug resurfacing?

 

Looks like this bug doesn't want to ever go away...

[themaniacboy]

5 minutes ago, seed said:

Is that the cartoony sounds bug resurfacing?

 

Looks like this bug doesn't want to ever go away...

Just searched this topic for others with the same issue under cartoon and you're right.

I changed use_libsamplerate to 0 in config file and the sounds are normal pitch but they're cut off.

Also, I just tried other levels and the mancubi have a funny sound when hit, go to 4:15 to hear it:

 

 

[fabian]

Please try the measures outlined in the Wiki: 

https://github.com/fabiangreffrath/crispy-doom/wiki/FAQ

[unerxai]

Found a minor bug about the status bar with colored numbers and the invulnerability. Thought it'd still be worth mentioning.

 

When you play with the fullscreen hud and grab the invulnerability, the health/armor numbers turn grey, then go back to normal once the effect fades away. That makes sense.

 

When you play with the status bar, the numbers don't turn grey. This may or may not be intentional. However, if you grab some health or check the automap, the numbers become grey, and remain that way even after the effect fades away. The only way the numbers go back to normal is by "refreshing" the status bar using one of the 2 methods previously mentioned.

 

 

 

[SoDOOManiac]

10 hours ago, seed said:

Is that the cartoony sounds bug resurfacing?

 

Looks like this bug doesn't want to ever go away...

 

10 hours ago, themaniacboy said:

Just searched this topic for others with the same issue under cartoon and you're right.

 

You can download the fix (older SDL2 DLLs) here.

Wiki description

[themaniacboy]

2 hours ago, Zodomaniac said:

 

 

You can download the fix (older SDL2 DLLs) here.

Wiki description

Thank you, this works great.

I couldn't figure out how to setup environment variables in Fabian's comment, so this is much appreciated!

[fabian]

@unerxai Fixed, thanks! Turns out this was due to an optimization which would only re-draw the status bar widgets if their values changed. Now they are also aware of their colorization.

[drfrag]

15 hours ago, fabian said:

Please try the measures outlined in the Wiki:  

https://github.com/fabiangreffrath/crispy-doom/wiki/FAQ

 I wonder why this works, my port didn't run when i linked against SDL 2.0.10 and then replaced the dll.

 But anyway wouldn't the real fix be adding a hint to use the DirectSound driver instead?

[unerxai]

@fabian Glad I could help :)

[seed]

But here's the question though - is it really an issue on SDL's side or something that was overlooked in Crispy?

 

When Eternity was updated to 2.0.10 it reportedly ran into a similar issue with 5.1 systems and above because some changes were not taken into account if I remember correctly, but Altaz addressed it very quickly - and without changing the API from WASAPI to DirectSound.

 

Maybe he can provide some insight regarding the cartoony sounds issue.

 

@Altazimuth

[Gaffer]

--

Edited May 27, 2023 by Gaffer

[fabian]

1 hour ago, Dobermann said:

May I ask if it would be possible to get the status bar back in widescreen mode?

 

Possible sure, but I won't work on this.