Crispy Doom 6.0 (Update: Mar 31, 2023)

[fabian]

5 hours ago, Zodomaniac said:

@fabian, are you going to implement the narrow HUD for widescreen rendering in Crispy, or let this suggestion be So Doomed?

Honestly, I'd rather prefer a pull request for this (that was fun this afternoon, he?).

 

Guys, please, I need a break from this. It works fine for me and I feel low incentive to implement another micro-feature that I am not going to use myself. Also, will this be another single "screen size" mode, or will this be available with and without status bar face and also translucently?

[SoDOOManiac]

11 hours ago, fabian said:

Honestly, I'd rather prefer a pull request for this (that was fun this afternoon, he?).

I've created a new branch :) Hell yeah, it was fun! ;)

 

11 hours ago, fabian said:

Guys, please, I need a break from this.

Of course, take all the time you feel you need!

 

11 hours ago, fabian said:

Also, will this be another single "screen size" mode, or will this be available with and without status bar face and also translucently?

In my branch it's a single screen size mode for crispy->widescreen == 1 && screenSize == 7, to look as @Juza suggested.

I don't think there should be a "+status bar face" or translucent mode, as this is a widescreen version of the status-barred HUD, just without the status bar and face.

 

 

Edited February 27, 2020 by Zodomaniac

[Grizzly]

On 2/24/2020 at 8:42 AM, fabian said:

 

Oh, that's in automap rotate mode, right?

Nope, it's in the static mode as well. Opened a github issue with a video of it in action.

 

Widescreen mode is *absolutely* great though, thank you and congrats for including it!

 

now all we need is to make the game multithreaded so my uncapped framerate isn't limited by my CPU's single thread performance

[fabian]

3 hours ago, Grizzly said:

Nope, it's in the static mode as well. Opened a github issue with a video of it in action.

 

This has already been fixed and will be part of 5.7.1, thanks!

 

3 hours ago, Grizzly said:

Widescreen mode is *absolutely* great though, thank you and congrats for including it!

 

Thank you!

[Hansen79]

I'm playing Congestion1024 with Crispy Doom 5.7 and at the start of map04 the doors don't open (but i can hear the sound of the doors opening)

The level works with GZDoom

[VGA]

Don't test against GZDoom, test against Chocolate Doom!

[ketmar]

yeah. GZDoom is not The Authority. while it is mostly compatible with Vanilla, it still does many things differently (at least in its default configuration). test against Choco, Choco does it all exactly like Vanilla. if it works in Choco, but not in Crispy, then it is possibly a bug in Crispy.

[seed]

PrBoom and Eternity could also be used for reference I daresay since they're both more vanilla.

[Hansen79]

Sorry, my mistake, 1024.txt says: "Advanced engine needed: Zdoom based ports and PrBoom.", so i guess it's normal it doesn't work with crispy-doom

I run 1024.wad with PrBoom and it works properly

[Redneckerz]

18 minutes ago, Hansen79 said:

Sorry, my mistake, 1024.txt says: "Advanced engine needed: Zdoom based ports and PrBoom.", so i guess it's normal it doesn't work with crispy-doom

I run 1024.wad with PrBoom and it works properly

And this is why you always need to read the text file before posting :P

 

The only exception on this are WADS and TC's that rely on their own custom engines (and use Source based modifications, essentially exclusive proto-source ports).

 

However this practice was only common at the end of the 90s and beginning of the 00's, so don't sweat it :)

[fabian]

2 hours ago, seed said:

PrBoom and Eternity could also be used for reference I daresay since they're both more vanilla.

 

But they are both Boom ports and thus unsuitable to find out if a bug is specific to Crispy or merely an unsupported generalized linedef. 

[seed]

41 minutes ago, fabian said:

But they are both Boom ports and thus unsuitable to find out if a bug is specific to Crispy or merely an unsupported generalized linedef. 

 

Not even when playing vanilla/limit-removing wads :p ?

[Grizzly]

17 hours ago, seed said:

 

Not even when playing vanilla/limit-removing wads :p ?

Yes totally. Boom has quite a few default settings that deviate from Vanilla doom, you have to override them in both ports by using special command line settings. Unless you specifically tell it otherwise, Eternity and PrBoom do their own thing, much like GZDoom.

 

Crispy Doom is a lot closer to vanilla by default (Except for the settings in the crispness menu and stuff that crashes vanilla).

 

And, err, *none* of these are closer to vanilla then Chocolate Doom, which literally does what the DOS exe does and nothing else (well, aside from running on modern operating systems without requiring DOSBox, but y'know).

 

... did you seriously want to say that PrBoom is closer to vanilla then Choco?

Edited February 28, 2020 by Grizzly

[SoDOOManiac]

20 minutes ago, Grizzly said:

... did you seriously want to say that PrBoom is closer to vanilla then Choco?

No, I guess @seed's point was 'closer to Vanilla than GZDoom'.

[seed]

35 minutes ago, Zodomaniac said:

No, I guess @seed's point was 'closer to Vanilla than GZDoom'.

 

Yes, and more vanilla accurate than it, so they could be used for referencing a thing or two, maybe.

 

56 minutes ago, Grizzly said:

Yes totally. Boom has quite a few default settings that deviate from Vanilla doom, you have to override them in both ports by using special command line settings. Unless you specifically tell it otherwise, Eternity and PrBoom do their own thing, much like GZDoom.

 

I know, I'm not new to using ports...

[Noiser]

Boom ports are far from vanilla accuracy. Not even the RNG table is the same iirc.

Edited February 28, 2020 by Noiser

[seed]

10 minutes ago, Noiser said:

Boom ports are far from vanilla accuracy. Not even the RNG table is the same iirc.

 

Depends on the complevel. In complevel 2-3-4 the original values are used.

[Spectre01]

PRBoom+ is just as accurate as any vanilla port regarding gameplay mechanics when using the proper complevel. Hence why it plays back those demos with no problems.

[Noiser]

That's kinda the point. If you say PrBoom can be used as a reference many people will use the default settings and not bother with complevels. That and other issues that may happen, so I'm not sure how reliable these ports can be. I'm not an expert though, just giving my two cents.

Edited February 29, 2020 by Noiser

[Grizzly]

9 hours ago, seed said:

I know, I'm not new to using ports...

Sorry, got confused: I thought you were replying to Ketmar's suggestion of using choco

[VGA]

42 minutes ago, Noiser said:

That's kinda the point. If you say PrBoom can be used as a reference many people will use the default settings and not bother with complevels. That and other issues that may happen, so I'm not sure how reliable these ports can be. I'm not an expert though, just giving my two cents.

OK then ... prBoom+ with the author-recommended complevel should be used to compare.

 

Are there known bugs/inconsistencies of prboom+ vanilla compatibility?

[Noiser]

I confess I rarely stick with complevel 2 (I did it more when I had to test my mod) because I prefer to use prBoom with boom maps. So far Chocolate and Crispy are the ports I have trusted the most for vanilla\limit-removing testing, but maybe that's just ignorance of mine.

Edited February 29, 2020 by Noiser

[VGA]

I'm pretty sure you can trust prboom+ vanilla compat mode unless there is some extreme Dehacked fuckery going on.

[Noiser]

That's great to know, thanks.

[fabian]

Update Mar 03, 2020: Crispy Doom 5.7.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.7.1 has been released on March 03, 2020 to fix some bugs related to widescreen rendering.

 

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.7.1/crispy-doom-5.7.1-win32.zip

Have a lot of fun!

- Fabian

[Grizzly]

Hurray for working automaps!

 

I noticed a small issue wrt sigil_shreds.wad and music packs

When the Crispy Doom soundcard is set to OPL3, the program will still load files from music-packs (which seems counter-intuitive since the midi/ogg/flac/mp3 option is right there) and play them as normal.

However, if you then try to play Sigil through the autoload method (ie Sigil and Sigil_shreds in the same folder as crispy doom), the music in Sigil does not play at all.

 

I'm not entirely sure what the expected behaviour here is, but I would expect the OPL3 option to either load all music packs or none of them.

[Grizzly]

This has been bugging me for a while but I've neglected reporting on it for now.

 

The dot crosshair is not a dot.

It is in fact a rectangle, but the rectangle is offset slightly to the left, and the left pixel of the rectangle is translucent whilst the right one is not.

 

It's a bit weird.

 

[SoDOOManiac]

1 minute ago, Grizzly said:

The dot crosshair is not a dot.

As resource-wise Crispy is limited to IWADs (except the baked-in crisps background texture), it uses symbols of an IWAD font as crosshairs: ^ for chevron, + for cross, X is not used as it looks like a rectangle at that scale, and period is the dot that does look so imperfect in that font, yeah.

[SoDOOManiac]

On 2/22/2020 at 7:46 AM, Juza said:

Suggestion: make an alternative for the widescreen HUD to make the status bar info closer together, about the same as it is without widescreen. To me, they're too far apart, making my eyes take a bit more time to gather all the info, compared to the non-widescreen alternative HUD. The difference is quite noticeable in gameplay, for me.

 

Quick photoshop to serve as picture of my suggestion:

The 'compact HUD' for widescreen rendering has already been introduced in Crispy and has made its way into the freshest So Doom release :)

[fabian]

On 3/4/2020 at 10:12 AM, Grizzly said:

I'm not entirely sure what the expected behaviour here is, but I would expect the OPL3 option to either load all music packs or none of them.

 

Loading a "music pack" is quite different from loading a music WAD. If you load a music pack, you tell the engine about an alternative location where it can find music files. So, it's up to the engine to decide whether to play music from one of the files it finds there or play the music lump. If you load a music WAD, however, you override the music lumps without providing an alternative. And if you have set the engine to play OPL3 music and you have overridden the music lumps with MP3 data, which OPL3 emulation cannot play back, then you'll have to enjoy the silence.

 

33 minutes ago, Grizzly said:

The dot crosshair is not a dot.

 

As @Zodomaniac has already pointed out, the "dot" crosshair is the period glyph of the HUD font - just as the "cross" is the plus glyph of that font and the "chevron" is the circumflex.