Crispy Doom 6.0 (Update: Mar 31, 2023)

@randomgamerguy1997 here, archived. i believe that it is not warez per se. i hope. ;-)

On 2/15/2020 at 5:55 AM, Lollie said:

Out of curiosity: Would you consider a second-window automap?

 

Thank you for the suggestion! However, I hope you understand I don't feel any incentive to implement a feature that I would never use myself [*]. The only dual screen setup that I have available is at work and, well, you guess it. I would like to review a pull request implementing this, though. ;) In the meantime, if you would like to have a continuous overview of the surroundings during playing, I can recommend the automap overlay mode (press 'O' while the automap is active).

[*] The issues with proper sizing and scaling of the external automap window that you mentioned do not really add to raise my interest in implementing this.

On 2/17/2020 at 6:23 PM, fabian said:

I would like to review a pull request implementing this, though. ;)

My kingdom for sufficient knowledge of C, lol. I only know enough to be dangerous! Better that you don't get pull requests from me.

I've attempted hacking together an external automap for my own use once before: by adding a custom view to the "three screen mode" code in d_net.c (basically, a drone that looks straight ahead and mirrors the player's view), and altering automap behavior so that it doesn't force-close upon death if the custom view is active. Turns out that forcing the automap to stay open like that can cause a desync in a solo-net session, who knew. 😅

18 hours ago, ketmar said:

@randomgamerguy1997 here, archived. i believe that it is not warez per se. i hope. ;-)

thanks I'll give it a try

Update Feb 21, 2020: Crispy Doom 5.7 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 has been released on February 21, 2020. This release brings proper widescreen rendering as well as other improvements requested by the speed-running community.

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

Have a lot of fun!

- Fabian

Awesome stuff as always! Installed it as soon as I saw the update. Really appreciate the effort and all the fine-tuning.

About this request:

On 1/3/2020 at 3:30 PM, Looper said:

Requesting a feature that can be enabled or disabled from a key even during a gameplay:

Everytime the use key is pressed, it prints the time that it was pressed on. So if you hold use key between the frames 74-80, it would only print the time from the 74th frame. Useful, for example in Doom 1 E1M1, when running for the first door and every frame counts. You want to know if you opened the very first door (meaning hit the use key) on the 71st, 72nd, 73rd or 74th frame. The time would be printed for like a second or two, maybe adjustable from the setup, in the center of the screen, somewhere where it is very eays to see.

 

As far as I know, this is not a TAS feature, since you can achieve the same by using the Advanced HUD (introduced in prboom+), and binding "screenshot" and "use" key on the same button, and then just read the exact time from the screenshot.

 

Edit for one tiny thing: once you reset a demo from the reset level/demo button, it doesn't reset the timer even though it should, imo.

I think this kind of thing could just show the "last time USE key was pressed" into the AdvancedHUD. For example:

K 5/10

I 0/38

S 0/3

T 3.97 (this would only refresh everytime the use key is pressed)

However if someone presses the use key down for 10 frames in a row, it would only show the time from the 1st frame the use key was pressed down. Only non consecutive "use commands" could refresh the timer again.

Oh my god the widescreen is so good. Now I can finally play the alternative universe "Dos Doom but it was made in an era where 16:9 was the norm"

now all it needs is OpenAL implementation

4 hours ago, fabian said:

This release brings proper widescreen rendering

Oh Hell yeah!!!!

Hi fabian, looks great!

Is it intentional that the statusbar is disabled with widescreen rendering on? (The HUD works fine.)

11 minutes ago, plums said:

Is it intentional that the statusbar is disabled with widescreen rendering on? (The HUD works fine.)

Yes, it is, and even the screen size slider has different values: from 0 (no HUD) to 3 (translucent HUD).

What does it mean by lump?

4 minutes ago, Shon_RT said:

What does it mean by lump?

https://doomwiki.org/wiki/Lump

Great news! I've always wanted widescreen in Crispy Doom.

I do wish the status bar was available though, but since I mostly play with the fullscreen hud I guess it's no big deal.

Doesn't seem to be in the ubuntu repositories yet

Quote

widescreen

The widescreen rendering is amazing! Thanks for the update.

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:

--

Bug: In widescreen mode, automap level text for maps with dehacked map names has extra vertical space. Problem goes away if I turn widescreen mode off.

Here's a funny bug: When toggling widescreen on and off in Windowed mode, window size calculation seems to alternate between width and height, which results in the screen getting progressively smaller with each toggle.

Requesting that the resizing be based on window height, so that the widescreen toggle makes the window expand/retract from the left and sides!

now with widescreen rendering being a thing, any chance for any FOV options?

the default FOV is perfectly fine in 4:3, but going to 16:9 its just low enough to make me slightly uncomfortable when playing for 1 hour+

My favourite source port got even better. Amazing update Fabian!

Here's some ultra-wide Crispyness in action:

Which mod is that?

It's from Rowdy Rudy II, a community project by Doomkid. 

Map in question is my submission, which I happened to be tweaking when I noticed the new Crispy update came out.

I found another widescreen related bug. Map markers don't register were the player is.

On 2/22/2020 at 10:24 AM, plums said:

Bug: In widescreen mode, automap level text for maps with dehacked map names has extra vertical space. Problem goes away if I turn widescreen mode off.

 

Ew, I have seen this before but was sure to have fixed it. Anyway, I think the additional line has to go in widescreen mode, it will clash with the HUD in automap overlay mode.

On 2/22/2020 at 1:13 PM, Lollie said:

Here's a funny bug: When toggling widescreen on and off in Windowed mode, window size calculation seems to alternate between width and height, which results in the screen getting progressively smaller with each toggle.

I wouldn't call it a bug. Each time you change the resolution, the new window has to fit *inside* the old one. Else you'll risk to enlarge the window outside the screen dimensions.

19 hours ago, unerxai said:

I found another widescreen related bug. Map markers don't register were the player is.

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

3 hours ago, fabian said:

I wouldn't call it a bug. Each time you change the resolution, the new window has to fit *inside* the old one. Else you'll risk to enlarge the window outside the screen dimensions.

What risk? It's not like the user's monitor resolution would be progressively shrinking with the window. :B

At the very least, when toggling widescreen off, the window should return to its original size. There's no good reason for it to keep getting smaller like that - all that does is force the user to quit out, open setup, and fix the resolution.

50 minutes ago, Lollie said:

force the user to quit out, open setup, and fix the resolution.

Or, you just resize the windows back to your liking?

Also, the windows only resizes itself until it has reached its minimum size which is identical to the framebuffer resolution. So, there is no risk that it will resize itself until it suddenly vanishes.

@plums I have removed the obtrusive extra line of information from the widescreen automap view. @unerxai I have fixed the horizontal coordinate for the automap markers, thanks

13 minutes ago, fabian said:

Or, you just resize the windows back to your liking?

 

Also, the windows only resizes itself until it has reached its minimum size which is identical to the framebuffer resolution. So, there is no risk that it will resize itself until it suddenly vanishes.

I noticed it can only get so small, that's in the gif example that I posted.

What I'm trying to say is that it would make more sense if the widescreen toggle simply switched between two resolutions, as that's how a toggle is expected to work.

https://imgur.com/PhK9o2M

Why can't I switch to the weapons I want with E, F and C? Ingame? I've set the keys there.

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.

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