Crispy Doom 6.0 (Update: Mar 31, 2023)

[Linguica]

DSSLOP gets played when the archvile revives something so it can be confusing if e.g. a closing door squishing a corpse makes the same noise.

[jmickle66666666]

I guess if it's not going to get boom support I can't really use this port :/

I hate working with limit-removing and vanilla, and most of the wads I like to play aren't limit removing/vanilla either.

I guess its good that you are sticking with your project goals though!

[Megamur]

Great to hear about all the new fixes! :)

fabian said:

- Playing dsslop when monsters are crushed. Hm, people are very sensitive regarding sounds and playing sounds where they don't belong is usually frowned upon. If you say it is actually played in the PSX port that may be a different thing, but i am still not sure. (One thing is sure: there won't be a switch for this! ;) )

I'd leave it out, then. I'd rather have new features that run contrary to vanilla/Chocolate Doom being optional, or not there at all. Thanks for considering it, though.

[Megamur]

To clarify what I wrote before, I think adding totally new, non-optional features isn't a great idea. However, non-optional bugfixes are fine, as long as they don't mess with the gameplay. (Messing with the gameplay, for example, would be like ZDoom's decision to make lost souls focus on targets, instead of striking once and then forgetting their target like they were originally designed to do.)

With that in mind, I'd also like to suggest taking another page from ZDoom and make it that "open wait close" doors that are already opened play their close/open sound effects when activated. In vanilla, if the door is already open, pressing the use key on it again, no matter how many times you do it, won't cause the door to play any sound effects. Only when it automatically closes and is reopened will it play sounds again.

I don't believe this would have any significant effect on the gameplay, aside from perhaps making things a little noisier when enemies get stuck on doortracks. And you already fixed the "blazing doors make double-closing sounds" error, so this seems like it would just be an extension of that.

[fabian]

Megamur said:

With that in mind, I'd also like to suggest taking another page from ZDoom and make it that "open wait close" doors that are already opened play their close/open sound effects when activated. In vanilla, if the door is already open, pressing the use key on it again, no matter how many times you do it, won't cause the door to play any sound effects. Only when it automatically closes and is reopened will it play sounds again.

I am not quite sure what you are talking about. Is this bug documented anywhere in the Doomwiki or fixed in any other port than ZDoom?

[vesperas]

I've found what appears to be a bug in NERVE map 1, it should be pretty straightforward to trigger:

All ok


All ok


The grate on the ceiling disappears


Please ask if you need further assistance.

[fabian]

Hi vesperas,

thank you very much for reporting this bug!

vesperas said:

I've found what appears to be a bug in NERVE map 1, it should be pretty straightforward to trigger:

Actually, the bug is not in the map, but in the renderer. It is "caused" by the following code from MBF which I added in the course of implementing the WiggleFix and which is supposed to avoid overflows caused by mid-textures with extreme vertical coordinates.

	    // [crispy] apply Killough's int64 sprtopscreen overflow fix
	    // from winmbf/Source/r_segs.c:174-191
	    // killough 3/2/98:
	    //
	    // This calculation used to overflow and cause crashes in Doom:
	    //
	    // sprtopscreen = centeryfrac - FixedMul(dc_texturemid, spryscale);
	    //
	    // This code fixes it, by using double-precision intermediate
	    // arithmetic and by skipping the drawing of 2s normals whose
	    // mapping to screen coordinates is totally out of range:

	    {
		int64_t t = ((int64_t) centeryfrac << FRACBITS) -
		             (int64_t) dc_texturemid * spryscale;

		if (t + (int64_t) textureheight[texnum] * spryscale < 0 ||
		    t > (int64_t) SCREENHEIGHT << FRACBITS*2)
			continue; // skip if the texture is out of screen's range

		sprtopscreen = (int64_t)(t >> FRACBITS); // [crispy] WiggleFix
	    }

The actual code, however, does not seem to be wrong. The logic seems legit to me and other ports that have this code render just fine, e.g. PrBoom+, Doom Retro and WinMBF. Anyway, if I inject this code into Chocolate Doom, the same rendering artifacts occur, so it isn't caused by code changes introduced by Crispy.

It seems to me that the "srpyscale" variable has a different meaning in MBF-based ports...

Please ask if you need further assistance.

Thank you, but the bug is impossible to "unsee" and I am after it! ;)

Edit: Well, of course not. As it turned out, in the MBF code the "spryscale += rw_scalestep;" increment has been moved into the iterator of the for-loop. In the Vanilla code it was at the end of the loop and thus skipped by the "continue;" instruction. This resulted in the whole texture being skipped for rendering as soon as one part of it was out of screen range.

Needless to express my sentiment about such kind of code changes...

Fixed in GIT, thank you again for reporting!

[vesperas]

Thank you for the thorough explanation!

[fabian]

Say, do you play in low-resolution mode?

[vesperas]

I play in low-res when I'm on my 1366x768 laptop, and in high-res on the 1920x1080 desktop ;)

[fabian]

Update 03 Nov 2015: Crispy Doom 3.1 has been released!

Crispy Doom is a 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 compatibile with the original.

Highlights of this release include:

* Colorized Status Bar numbers and HUD texts can now be enabled separately
* Optional Look Spring has been implemented for both keyboard and mouse look
* A Direct Vertical Aiming mode (i.e. without auto-aim) has been added
* It is now possible to enable Translucency separately for Missiles and Items
* Screenshots in PNG format are now saved with the same dimensions as the rendered game
* Music lumps are now properly checked for being MP3 files
* Many bugs and rendering glitches fixed
* etc...

Please visit the Crispy Doom homepage for more information:
http://fabiangreffrath.github.io/crispy-doom

The Crispy Doom source code is available at GitHub:
https://github.com/fabiangreffrath/crispy-doom

Binaries for Windows (x86) are available here:
http://www.greffrath.com/~fabian/crispy-doom_3.1.zip

Have a lot of fun!

- Fabian

[soner du]

Crispy Doom 3.1 is less portable than 3.0...

I'm trying it at work (just a quick break) on Windows 7.

I can run crispy-doom.exe OK, but not crispy-doom-setup.exe which now requires administrator rights.

[fabian]

soner du said:

I can run crispy-doom.exe OK, but not crispy-doom-setup.exe which now requires administrator rights.

Hm, this seems to be Windows panic whenever you run a file with "setup" in its name. Did you run the file from a user-writable directory? Will e.g. chocolate-doom-setup.exe run from this directory without administrtor rights? Will crispy-doom-setup.exe from the 3.0 release run from this directory without administrator rights?

I know there is a src/setup/setup-manifest.xml file that is supposed to take care of this non-sense, but I don't know what to do with it...

[RestlessRodent]

fabian said:

Hm, this seems to be Windows panic whenever you run a file with "setup" in its name. Did you run the file from a user-writable directory? Will e.g. chocolate-doom-setup.exe run from this directory without administrtor rights? Will crispy-doom-setup.exe from the 3.0 release run from this directory without administrator rights?

I know there is a src/setup/setup-manifest.xml file that is supposed to take care of this non-sense, but I don't know what to do with it...

I believe this was fixed in Chocolate Doom long ago, it requires that a manifest be included in the setup program to show that it is not an installer program which requires admin powers.

The manifest must be included in the resource object for the binary (where icons go and such).

[soner du]

fabian said:

Did you run the file from a user-writable directory? Will e.g. chocolate-doom-setup.exe run from this directory without administrtor rights?

I'm running everything from an USB key. chocolate-doom-setup.exe will not run anywhere without administrator rights

fabian said:

Will crispy-doom-setup.exe from the 3.0 release run from this directory without administrator rights?

All previous versions of crispy-doom-setup.exe worked without administrator rights, including 3.0

[chungy]

That's odd. The only change manifest had in the meantime was support for Windows 10 -- earlier versions shouldn't be affected. Would you mind seeing if Chocolate Doom 2.2.1 exhibits this behavior? If it doesn't, something might have gone wrong with the Crispy build system.

[fabian]

It seems I have shot myself in the foot with this commit addressed at the detection of the windres tool

https://github.com/chocolate-doom/chocolate-doom/commit/26524bf56324364ceb1f9fad6e1efec55315d73d

by querying the $host variable without calling AC_CANONICAL_HOST before. This bug affected both Choco and Crispy, but only if building on Windows with either MinGW or Cygwin. Fixed in Choco, merged in Crispy. ;)

Before I push another point release because of this, could someone please check if the other (new) features work as intended? Thanks! ;)

[soner du]

chungy said:

Would you mind seeing if Chocolate Doom 2.2.1 exhibits this behavior? If it doesn't, something might have gone wrong with the Crispy build system.

I've tried all Crispy Doom releases so far, and 3.1 is the first and only one for which chocolate-doom-setup.exe requires administrator rights.

fabian said:

Before I push another point release because of this, could someone please check if the other (new) features work as intended? Thanks! ;)

I've not crushed any Barons or Cacos, but other features (vertical aiming, transclucent stuff...) look good !

[fabian]

Update 04 Nov 2015: Crispy Doom 3.2 has been released!

Crispy Doom is a 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 compatibile with the original.

Crispy Doom 3.2 is merely a bug-fix release to fix some nasty bugs (missing icons in executables and crispy-*-setup.exe requiring admin rights) in the Windows version of Crispy Doom 3.1.

Highlights of the 3.1 release include:

* Colorized Status Bar numbers and HUD texts can now be enabled separately
* Optional Look Spring has been implemented for both keyboard and mouse look
* A Direct Vertical Aiming mode (i.e. without auto-aim) has been added
* It is now possible to enable Translucency separately for Missiles and Items
* Screenshots in PNG format are now saved with the same dimensions as the rendered game
* Music lumps are now properly checked for being MP3 files
* Many bugs and rendering glitches fixed
* etc...

Please visit the Crispy Doom homepage for more information:
http://fabiangreffrath.github.io/crispy-doom

The Crispy Doom source code is available at GitHub:
https://github.com/fabiangreffrath/crispy-doom

Binaries for Windows (x86) are available here:
http://www.greffrath.com/~fabian/crispy-doom_3.2.zip

Have a lot of fun!

- Fabian

[MugMonster]

I have kind of a weird idea and I don't know if it's even possible, but I figure if you can change the colors of specific crushed corpses and randomly mirror corpses then it might be: could you randomly change the colors of the space marine corpse objects to the various multiplayer colors? to like, give off the impression that the marines have more than just green shirts and they were killed in the invasion too?

[fabian]

Mr.Unsmiley said:

could you randomly change the colors of the space marine corpse objects to the various multiplayer colors? to like, give off the impression that the marines have more than just green shirts and they were killed in the invasion too?

This is a very nice idea that fits particularly well to Crispy Doom's feature set. Thank you for this suggestion, I'll see how to implement this ASAP.

[Linguica]

I would do something like take the thing's X/Y values, concatenate them, run the result through a simple hashing function, and then take the 2 least significant bits and color the thing 1 of the 4 possible values based on it. That way the variation would be "random" but would always results in the same coloration for each one.

[fabian]

Well, there is already this "random value" normalized to 4 in P_SpawnMobj() that I will take:

    mobj->lastlook = P_Random () % MAXPLAYERS;

I will disable this feature in netgames, where it will only cause confusion.

[fabian]

Done, thanks!

https://github.com/fabiangreffrath/crispy-doom/commit/7ffb47982362198b5cbcba1ad89fb3410d48ea7a

[MugMonster]

fabian said:

This is a very nice idea that fits particularly well to Crispy Doom's feature set. Thank you for this suggestion, I'll see how to implement this ASAP.

hooray, my "overthinking the barely existent doom lore" has finally paid off

[Lila Feuer]

The volume in-game seems awfully low, even when I jack it all the way up. I have to turn my system sound way up to hear anything, which results in me forgetting I did that and getting my ears blown out in something else.

Edit: Not sure what I did, but it seems to have somewhat resolved itself.

[fabian]

Strange, you are the second one to report a sound issue under Windows that cures itself this week. Did you ever experience the same with Chocolate Doom? Both ports share the same sound code.

[Doomer1999]

Hello,

I just registered here. Anyway i wonder if Crispy Doom can support the regular DOOM2.WAD (or basically any other version of the DOOM2.WAD, like Xbox360/PS3/XBLA etc.) together with NERVE.WAD form the BFG edition in the same folder? Then one could Play Doom 2 with "No Rest for the Living" while having all the uncensored content.

[VGA]

Doomer1999 said:

Hello,

I just registered here. Anyway i wonder if Crispy Doom can support the regular DOOM2.WAD (or basically any other version of the DOOM2.WAD, like Xbox360/PS3/XBLA etc.) together with NERVE.WAD form the BFG edition in the same folder? Then one could Play Doom 2 with "No Rest for the Living" while having all the uncensored content.

I just loaded NERVE.WAD along with the normal doom2.wad and I warped to map 31 and therre are nazis. Also, the health items are the normal/original ones.

[fabian]

Yes, you can load NERVE.WAD with any DOOM2.WAD you like [1]. Crispy Doom will recognize NERVE.WAD and play the game with the correct map names, music, par times etc. However, in order to display the Episode Selection menu in the New Game menu, you need an IWAD that contains these menu graphics lumps, which is generally only the DOOM2.WAD files that are shipped with the BFG Editions.

[1] "crispy-doom -iwad DOOM2.WAD -file NERVE.WAD" that is.