Crispy Doom 6.0 (Update: Mar 31, 2023)

Frankly, I cannot see why this should be a bug? If you keep pressing the ESC key, you keep sending keydown events (in SDL speech) and thus keep triggering the action assigned to that key. This is pretty much expected, no?

fabian said:

Frankly, I cannot see why this should be a bug? If you keep pressing the ESC key, you keep sending keydown events (in SDL speech) and thus keep triggering the action assigned to that key. This is pretty much expected, no?

Source ports usually don't do that.

joe-ilya said:

Source ports usually don't do that.

I see. This seems to be because Choco does set SDL_EnableKeyRepeat() -- since nearly exactly 8 years:

https://github.com/fabiangreffrath/crispy-doom/commit/47ae7506fc1e286cbce74f1126fa016f31d71996

I am considering to remove that call. Does anyone know about any undesirable side-effects this might casue?

sector666 said:

When using the minimal hud is there any way to move the hud info there closer to the bottom?

Alternatively, how would you like if the empty space at the bottom got filled up by moving the messages line there?



Don't panic, this is just an experiment, not commited code! ;)

fabian said:

I see. This seems to be because Choco does set SDL_EnableKeyRepeat() -- since nearly exactly 8 years:

I am considering to remove that call. Does anyone know about any undesirable side-effects this might casue?

Would affect arrow keys in menus and menu sliders (e.g. sound effects volume) probably.

fabian said:

Alternatively, how would you like if the empty space at the bottom got filled up by moving the messages line there?

I think it's an interesting change, although I'm not sure if other people would like it or not.

Thinking about it a bit more I'm pretty sure what bugged me is I'm too used to Doom 64's minimal hud. The numbers there aren't fully opaque (probably about 25% transparent). It's subtle but that seems to make the floating numbers not stand out so much, while not impacting the readability too bad either. I don't know if you'd be willing to have an option for semi transparent numbers on the minimal hud.

plums said:

Would affect arrow keys in menus and menu sliders (e.g. sound effects volume) probably.

Indeed, it seems that only the menu itself is affected by this change. I could live with the fact that I have to tap sliders for every step instead of holding down a key (which is generally utterly imprecise, anyway). On the other hand, I could also live with the fact that the menu flickers when I keep holding ESC. However, I think the latter is more confusing and other source ports don't behave like this, so it's the lesser of two evils. Will be fixed in the next release.

sector666 said:

I think it's an interesting change, although I'm not sure if other people would like it or not.

A bit too disruptive, maybe. This is the patch, if you want to try it out:

--- a/hu_stuff.c
+++ b/hu_stuff.c
@@ -507,6 +507,12 @@ void HU_Drawer(void)
     if (crispy_translucency && screenblocks > CRISPY_HUD && !automapactive)
        dp_translucent = true;
 
+    // [crispy] move messages into the empty space below the status bar numbers
+    if (screenblocks >= CRISPY_HUD && !automapactive)
+       w_message.l->y = 200 - SHORT(hu_font[0]->height + 3);
+    else
+       w_message.l->y = HU_MSGY;
+
     V_ClearDPTranslation();
     HUlib_drawSText(&w_message);
     dp_translation = cr[CR_GOLD];

Thinking about it a bit more I'm pretty sure what bugged me is I'm too used to Doom 64's minimal hud. The numbers there aren't fully opaque (probably about 25% transparent). It's subtle but that seems to make the floating numbers not stand out so much, while not impacting the readability too bad either. I don't know if you'd be willing to have an option for semi transparent numbers on the minimal hud.

Translucent HUD is already implemented in GIT and will be part of the next release:

https://github.com/fabiangreffrath/crispy-doom/issues/39

:-)

Could there be some options for the colored blood? I like it on cacodemons and barons/knights.. but I'd like regular red blood on spectres and lost souls.

Also noticed the colored HUD numbers are not used with custom HUDs.

Jimi said:

Could there be some options for the colored blood? I like it on cacodemons and barons/knights.. but I'd like regular red blood on spectres and lost souls.

Phew, that would drift a bit too much into micro-managing. I prefer reasonable defaults (and I think they are in this case) and features either on or off over thousands of options for everything.

Also noticed the colored HUD numbers are not used with custom HUDs.

This has been reported:

https://github.com/fabiangreffrath/crispy-doom/issues/48

The main reason is that Crispy's color conversion is based on Boom's and that does only apply to the red range. However, any attempts to extend it to other color ranges lead to ugly results so far and were not worth the extra involement they caused.

Update 27 Oct 2014: Crispy Doom 2.0 "Back to the Roots" has been released!

Crispy Doom is a fork of Chocolate Doom that provides a higher display resolution, raises the static limits of the Doom engine and offers further optional visual, technical and gameplay-affecting enhancements while remaining entirely config file, savegame, netplay and demo compatibile with the original. .

This is a major Crispy Doom release, because it has merged the Chocolate Doom 2.1.0 release. Highlights of this release:

* Strict feature revision for more Vanilla Doom compatibility
* Support for BEX files and lumps
* Menu improvements
* Automap improvements
* Cheat improvements
* Color translation improvements
* Laser pointer improvements
* Transparent Crispy HUD
* 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_2.0.zip

Have a lot of fun!

- Fabian

Looking forward to playing around with the new release. Thanks. :)

"Features that are considered demo or netgame critical but are not user-visible enough to justify a dedicated switch, have been removed."

Can you clarify that? Multiplayer demos are one of the main reasons I use Crispy Doom.

Danfun64 said:

Can you clarify that? Multiplayer demos are one of the main reasons I use Crispy Doom.

Please find my rationale discussed in this issue:
https://github.com/fabiangreffrath/crispy-doom/issues/31

The new setup exes all crash for me without SDL output. The choco ones work fine, the old fines worked fine, too.

EDIT: Shouldn't that laz0r be a brighter red?

Got it compiled on Linux, had some confusion about it though.. it dropped the compiled binaries in /proc/somenumber

This engine is crispy as all hell.

Is there a way to adjust deadzone for axises on joysticks?

What do you mean dropped the binaries in /proc/somenumber? The install target should never touch that tree -- /proc/$PID is used for information about a specific process, is that what you're looking at?

VGA said:

The new setup exes all crash for me without SDL output. The choco ones work fine, the old fines worked fine, too.

That's on Windows, right? Sigh, I need someone who does some playtesting on that platform.

EDIT: Shouldn't that laz0r be a brighter red?

It is already rendered with the lightest colormap, i.e. the same you get with the night-vision goggles.

Mike.Reiner said:

Got it compiled on Linux, had some confusion about it though.. it dropped the compiled binaries in /proc/somenumber

You are supposed to pass the installation directory to the "make install" call with the DESTDIR variable.

This engine is crispy as all hell.

What should this mean?

Is there a way to adjust deadzone for axises on joysticks?

Not that I knew of, but I think there is already a bug report open against Chocolate Doom regarding improved Joystick handling. Maybe you could add your suggestions here:
https://github.com/chocolate-doom/chocolate-doom/issues/424

VGA said:

The new setup exes all crash for me without SDL output.

Confirmed, it is this bug:
https://github.com/chocolate-doom/chocolate-doom/issues/455

Expect a hot-fix soon.

Edit: If you run it via "USER=name crispy-doom-setup.exe" it should work.

fabian said:

What should this mean?

Just being sarcastic with a bad pun, I like your engine. Sorry if that didn't convey.

chungy said:

What do you mean dropped the binaries in /proc/somenumber? The install target should never touch that tree -- /proc/$PID is used for information about a specific process, is that what you're looking at?

fabian said:

You are supposed to pass the installation directory to the "make install" call with the DESTDIR variable.

I'm not a very experienced linux user, I just followed the guide here:
http://www.chocolate-doom.org/wiki/index.php/Crispy_Doom#Download

And that's what happened. I could not find the binary after the compile finished and I wasn't able to discern where it was placed looking through some of the terminal output.

I did a search of the entire file system and /proc/ is where the binaries ended up. I copied them over to /usr/share/games where chocolate-doom was placed after I compiled it, and it works fine now. I'll try DESTDIR next time.

fabian said:

Not that I knew of, but I think there is already a bug report open against Chocolate Doom regarding improved Joystick handling. Maybe you could add your suggestions here:
https://github.com/chocolate-doom/chocolate-doom/issues/424

Cool. Thanks.

Mike.Reiner said:

I'm not a very experienced linux user, I just followed the guide here:
http://www.chocolate-doom.org/wiki/index.php/Crispy_Doom#Download

And that's what happened. I could not find the binary after the compile finished and I wasn't able to discern where it was placed looking through some of the terminal output.

I did a search of the entire file system and /proc/ is where the binaries ended up. I copied them over to /usr/share/games where chocolate-doom was placed after I compiled it, and it works fine now. I'll try DESTDIR next time.

You might've seen the /proc/$PID/exe symlink pointing to the binary (and possibly copied the symlink to /usr/games, too). Try running simply "sudo make install"

Mike.Reiner said:

And that's what happened. I could not find the binary after the compile finished and I wasn't able to discern where it was placed looking through some of the terminal output.

After compilation, the binaries can be found in the src/ subdirectory of your source tree. Unless you run the compilation with root permissions (DO NOT!) there is no chance the binaries get automagically installed somewhere in the file system outside your own $HOME space.

Mike.Reiner said:

I did a search of the entire file system and /proc/ is where the binaries ended up. I copied them over to /usr/share/games where chocolate-doom was placed after I compiled it, and it works fine now. I'll try DESTDIR next time.

Chocolate Doom shouldn't be in /usr/share/games in the first place. The /usr/share file system space is reserved for architecture-independent files, e.g. Doom WAD files. Game binaries like Chocolate Doom are supposed to end up in /usr/games, though, so maybe you mixed these up.

You're right I mixed it up, those chocolate-doom binaries ended up in /usr/local/games, not share, whoops.

And yes, they are indeed in /src. I don't know how I missed that.

Thanks.

In my windows 7 partition of my (newer) laptop, crispy-doom-setup.exe crashes to desktop immediately.

http://pastebin.com/WzppvczR

I know. It's a bug inherited from Chocolate Doom 2.1 which has been fixed meanwhile. I should release a fixed version, soon. As an immediate fix, you may set an environment variable called USER to any value.

Update 12 Nov 2014: Crispy Doom 2.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.

This is mostly a bug fix release to treat a bug that reproducibly crashed the setup program on Windows systems. Further changes that have accumulated in the short time frame include:

* Color translation improvements
* Menu improvements
* More victims of the feature clean-up
* 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_2.1.zip

Have a lot of fun!

- Fabian

Very nice! Desperately needs widescreen support imo.

Also, why don't you leave the music default at native midi? It's much better than that ridiculous OPL stuff.

EDIT: How difficult is uncapped framerate for choco-based ports?

VGA said:

Very nice! Desperately needs widescreen support imo.

This is going to be tough. Choco's scaling and stretching algorithms are all hard-coded to work on the original framebuffer dimensions. They do not support arbitrary target resolutions and aspect ratios.

Also, why don't you leave the music default at native midi? It's much better than that ridiculous OPL stuff.

Hm, didn't I? I don't think I changed the music default.

EDIT: How difficult is uncapped framerate for choco-based ports?

Tough!

Thank you very much for your suggestions. However, I believe, such general improvements should not be specific to Crispy Doom. Instead, since Chocolate Doom would also benefit from these improvements (and Crispy regularly merges Choco's code base), I believe this request is better addressed there.

I've thought about features like those before, but they'd diverge too much from Vanilla gameplay for my liking. So I'm hitting that ball back into your court :)