Crispy Doom 6.0 (Update: Mar 31, 2023)

[maxmanium]

44 minutes ago, seed said:

We might have a problem with "Smooth diminishing lightning" chief, it looks the same way it does when it's turned off in today's devbuild on my end.

 

Looks fine to me (although admittedly I do not normally use this feature):

 

Spoiler

OFF

 

 

ON

 

 

[seed]

I see the difference now, but it's minimal :( .

 

I thought the difference was meant to be more noticeable, but anyway, seems to work as intended then.

[fabian]

Same lighting gradient, but finer steps. The effect is meant to be unobtrusive!

 

Also @maxmanium I have fixed the weapon switching issue when using the IDCLEV cheat that you pointed out, thanks!

[maxmanium]

By the way, any chance we could also get the TNTAMMO/TNTAMO cheat? It would complement TNTWEAP well :)

[seed]

Does Crispy Doom fix/not "emulate" some of the bugs in the Xbox version of Ultimate Doom by any chance?

 

According to the wiki, Xbox Doom should display the E1 sky on all episodes thanks to the textures missing, but while playing through an Xbox IWAD earlier I noticed in the internal demo on E3 that it had the correct Inferno sky texture.

[maxmanium]

@seed, I'm assuming it's fixed -- it doesn't affect gameplay logic so I don't see why it wouldn't be.

[seed]

Well, that's a bit unfortunate, considering that I was looking for an accurate reproduction of its quirks, but hey, better than nothing at all.

 

Either way, thanks for supporting this IWAD fabian & co., seems to be the only port that supports it so far :) (I did a test run in GZDoom and PrBoom too after chungy told me Crispy supports it for sure, and although the secret exit on E1M1 technically worked in them, both took me incorrectly to Military Base instead of Sewers (Task failed successfully).

 

[chungy]

6 hours ago, seed said:

According to the wiki, Xbox Doom should display the E1 sky on all episodes thanks to the textures missing

The wiki is wrong. The IWAD has all the resources, but the engine has a bug. This same bug actually exists in Linux Doom (the source code released by id), where all episode use the episode 1 sky instead of the appropriate ones.

[fabian]

On 10/17/2019 at 4:19 AM, maxmanium said:

By the way, any chance we could also get the TNTAMMO/TNTAMO cheat? It would complement TNTWEAP well :)

 

I have introduced this cheat mostly for the ability to use the SSG in Doom 1. I consider it rather useless apart from this, not to speak of its TNTAMMO pendant.

[SoDOOManiac]

On 10/17/2019 at 5:19 AM, maxmanium said:

By the way, any chance we could also get the TNTAMMO/TNTAMO cheat? It would complement TNTWEAP well :)

I will implement that in So Doom , my fork of Crispy Doom :)

[Linguica]

I encountered a bug when playing D4V in Crispy Doom:

 

 

If you download and then do -merge D4V.wad -deh D4V.deh 4_HAR.deh the HAR (weapon 4) will never stop firing when you try to fire it. This does not occur in Chocolate Doom.

 

[SoDOOManiac]

2 hours ago, Linguica said:

I encountered a bug when playing D4V in Crispy Doom:

If you download and then do -merge D4V.wad -deh D4V.deh 4_HAR.deh the HAR (weapon 4) will never stop firing when you try to fire it. This does not occur in Chocolate Doom.

 

This happens because for this command line in Chocolate Doom the DEHACKED lump inside D4V.WAD isn't loaded (you have to pass -dehlump to load the deh lump inside a WAD after its name), and thus D4V.deh is loaded once. In Crispy Doom the DEHACKED lumps inside WADs are loaded while merging WADs, so what you're experiencing is the DeHackEd lump loaded twice. For Crispy Doom the equivalent command line would be  

crispy-doom -merge D4V.wad -nodeh -deh D4V.deh 4_HAR.deh

 

[seed]

Out of curiosity, is there uh... any way to change the music playback speed?

[SoDOOManiac]

2 minutes ago, seed said:

Out of curiosity, is there uh... any way to change the music playback speed?

Try changing snd_samplerate in the config.

[seed]

1 minute ago, Zodomaniac said:

Try changing snd_samplerate in the config.

 

Heh, interesting.

 

Now the next question is: What value would be fitting for "four beats slower"? I was planning on doing this for a let's of the original Xbox Doom 2 IWAD, and the music is slowed down there (I want to get the experience pretty close to how it is there).

[SoDOOManiac]

23 minutes ago, seed said:

Heh, interesting.

Sorry, I tried it myself, didn't work. I said that based on the fact that 32 kHz sampled OGGs played faster for me as my sample rate was 44.1 kHz.

[seed]

13 hours ago, Zodomaniac said:

Sorry, I tried it myself, didn't work. I said that based on the fact that 32 kHz sampled OGGs played faster for me as my sample rate was 44.1 kHz.

 

That sucks. Oh well.

 

Meanwhile, watching the video I linked above I noticed something: Betray has a par time ("SUCKS") on the real hardware, but shows up as ":00" in Crispy. It's the same for Sewers, but this one seems to actually have a :00 par time on the real hardware. Think you can do something about Betray lads?

[fabian]

This should have been fixed in Choco, I supposed, but

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/doom/g_game.c#L1463

[seed]

14 minutes ago, fabian said:

This should have been fixed in Choco, I supposed, but

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/doom/g_game.c#L1463

 

"Has no official time" ?

 

Well, one thing's for sure, it kinda has one apparently, but I don't know if the exact time can be figured, all I know is that it shows up as "SUCKS" on the real hardware, according to the video I posted above, rather than :00.

[wallabra]

Shouldn't it be anything >= 33 instead of just == 33?  ^{(psst, PWADs)}

[UndeadRyker]

This is a wonderful source port. It's exactly what I was looking for, I always wanted to make sure Doom physics were intact and compatible with original savegames/demos while looking much better and performing better without having to fool around with so many settings! The settings blending nicely into the game itself is a charming touch. It serves as either a nice bridge into more complex source ports like PrBoom+, or it can be your cozy medium-sized log-cabin compared to Chocolate/DOS's small cabin and the artificial fancy mansions like GZDoom. I love the design philosophy on this. And since I want to see it improved and developed further, I have a few suggestions!

1. The statusbar face would be a nice addition to the Crispy HUD. The face grinning at you and looking around is what makes Doom "Doom" for me. It also serves as a very important indicator for where you're getting hit from since there's no "damage arrows" or dynamic pain flashes (one side of the screen being more red than the other).
2. This might be too much: A way to change movement bobbing intensity that would be visual-only (while still remaining demo compatible). Motion sickness really sucks sometimes especially if you want to pass the time when you're sick. Maybe we can enter a value or choose from several options. The 25% reduction in movement bobbing straight out of the BFG Edition Doom Engine would be a welcome addition, and then the option of no view bobbing at all.
3. An FPS limiter that can be used as an alternative to VSync. Capping the game at various framerates like 30, 35, 60, 70, 75, etc.
4. True widescreen support while also keeping the chunky feel would be amazing. It could be called a "letterbox" option. When it's off, it would "extend" the game window to true widescreen with a resolution of 711x400 for the classic Crispy Doom resolution, and then 356x200 for the classic Doom resolution so we can see what's behind those bars while keeping the pixelated feel intact. That's just an idea off the top of my head. It would probably be needed to be implemented in Crispy Doom Setup.
5. A Mac download would be amazing. I'm extremely new to compiling programs especially for other OSes (I'm Windows), and I would like to play with someone using a Mac with this sourceport in netplay. Currently, we're using Chocolate Doom. I'm totally new at this sort of stuff.

And a bug I noticed using the Vanilla Doom smooth weapons dehacked file by fraggle:

• The chainsaw jerks around a lot when you walk with it. This doesn't happen in Chocolate Doom.

Anyway, that's it! I love the work put into it, it's great!

[chungy]

50 minutes ago, UndeadRyker said:

The statusbar face would be a nice addition to the Crispy HUD. The face grinning at you and looking around is what makes Doom "Doom" for me. It also serves as a very important indicator for where you're getting hit from since there's no "damage arrows" or dynamic pain flashes (one side of the screen being more red than the other). 

The picture this puts in my head is something like how Quake 3's HUD looks like. Sounds like a pretty solid idea to me :)

[maxmanium]

1 hour ago, UndeadRyker said:

The statusbar face would be a nice addition to the Crispy HUD. The face grinning at you and looking around is what makes Doom "Doom" for me. It also serves as a very important indicator for where you're getting hit from since there's no "damage arrows" or dynamic pain flashes (one side of the screen being more red than the other).

 

This would be a really nice feature. The lack of the statusbar face in fullscreen huds is the main reason I stick to the statusbar.

[fabian]

On 10/20/2019 at 5:58 PM, Gustavo6046 said:

Shouldn't it be anything >= 33 instead of just == 33?  ^{(psst, PWADs)}

 

Not necessarily, because at this point you are already reading beyond the bounds of the cpars[] array and the bytes found there and interpreted as INTs do not necessarily result in numbers > 59*61 (which is the limit for the SUCKS message). But, if you like, you could test for dummy maps up to, say, MAP40 (or up to the point where DOOM.EXE crashes) and report the results here.

[fabian]

On 10/25/2019 at 10:06 PM, UndeadRyker said:

This is a wonderful source port. It's exactly what I was looking for,

 

Thank you for your kind words!

 

On 10/25/2019 at 10:06 PM, UndeadRyker said:

1. The statusbar face would be a nice addition to the Crispy HUD.

 

I have tried this back and forth, i.e. the minimal HUD with the status bar face and I simply don't like it. The face blends into the weapon sprite and this looks like crap to me. But, as this has been requested many times before, I'll probably add an "intermediate Crispy HUD" with the status bar face. But, there won't be a translucent variant for this,  I am afraid.

 

On 10/25/2019 at 10:06 PM, UndeadRyker said:

1. A way to change movement bobbing intensity 

 

This should be possible, I already have something similar for the attacking weapon sprite. 

 

On 10/25/2019 at 10:06 PM, UndeadRyker said:

1. An FPS limiter that can be used as an alternative to VSync

 

Been there, done that. But that was in times before SDL2 when VSync was simply not available. This gets requested over and over again and I simply fail to understand why people believe that the game plays any smoother if the rate that the game content gets rendered to screen is neither in sync with the screen refresh rate itself nor wit hthe game's own 35FPS thinking rate.

 

On 10/25/2019 at 10:06 PM, UndeadRyker said:

1. True widescreen support while also keeping the chunky feel would be amazing. 

 

Yes, I am also dreaming of this and there is already an issue opened in the tracker at Github. However, this would be another *major* rewrite of some crucial parts of the renderer and I currently lack the time and energy to tackle a massive project like this.

 

On 10/25/2019 at 10:06 PM, UndeadRyker said:

1. A Mac download would be amazing. 

 

Sorry, I don't own any Mac hardware. But I am sure someone from the community would be able to volunteer and provide binaries for this system, right?

 

On 10/25/2019 at 10:06 PM, UndeadRyker said:

And a bug I noticed using the Vanilla Doom smooth weapons dehacked file by fraggle:

• The chainsaw jerks around a lot when you walk with it. This doesn't happen in Chocolate Doom.

 

That's probably because I animate the chainsaw movement during each frame and not only during each 4th. I'll have a look at it.

 

On 10/25/2019 at 10:06 PM, UndeadRyker said:

Anyway, that's it! I love the work put into it, it's great!

 

Thanks again!

[seed]

1 hour ago, fabian said:

Been there, done that. But that was in times before SDL2 when VSync was simply not available. This gets requested over and over again and I simply fail to understand why people believe that the game plays any smoother if the rate that the game content gets rendered to screen is neither in sync with the screen refresh rate itself nor wit hthe game's own 35FPS thinking rate.

 

It's not so much about being smoother as much as turning VSync off makes the game feel more responsive and with (some much) less input lag.

 

VSync, in most SDL-based ports (even Quake ports, which is profoundly depressing) causes input lag when coupled with uncapped framerate, but not when it's capped. Screen tearing, as long as it's not brutal on one's end, is a small price to pay for a more responsive and lag-free experience.

[fabian]

Re status bar face: How about adding the colored multiplayer background to the face widget so that it doesn't blend with the weapon sprite?

[maxmanium]

4 hours ago, fabian said:

Re status bar face: How about adding the colored multiplayer background to the face widget so that it doesn't blend with the weapon sprite?

 

I was actually wondering how the status bar face would look in coop/deathmatch. Sounds like a good solution to me.

[MaXelL]

@fabianI don't know if it goes against Crispy/Choco Doom principles, but could something like the HXRTC HUD be implemented in Crispy Doom?

[drfrag]

Well it's high time to clarify the intercepts mess.

@Zodomaniac: while i thank you to give me credit as i stated the code was already in Crispy for the laser aiming so you'd have credited fabian instead.

I've revisited the subject and i've decided to remove the limit, the guards and the emulation. I know fabian said checking them was a performance killer but increasing the limit with lines is something very hard to do even in intercepts.wad.

 I cherry-picked 'remove INTERCEPTS limit' from Crispy and then i did this: https://github.com/drfrag666/chocolate-doom/commit/5d28f6cf44c70c81bc5d7227fab3e25a7a67315e

 There i did the same as fabian (again) for other limits to show the count and removed the overflow guards and calls to the emulation function. That's becouse else you can't shoot anything beyond the intercepts.