Crispy Doom 6.0 (Update: Mar 31, 2023)

[fabian]

clarry said:

Here's my fix:

Classy patch, thank you very much clarry! I have applied it in GIT, though a bit reformatted to keep the interdiff with Choco smaller.

[clarry]

Thanks for applying the fix.

I've found another thing that irks me, it's the vertical mouse motion.. it's still jerky and at times feels like playing with a dirty old ball mouse where the rollers don't always spin as they should. For a second I thought it's due to framerate or bad tracking from my mouse, but it's actually a code feature.

The problem is that the mouse y delta is scaled down by 1/8, i.e. the low three bits are discarded. So if you're moving the mouse really slow, it's actually possible to drag it all the way across the pad without changing lookdir at all (delta on every tic is less than 8). This mostly affects aiming when you're carefully adjusting on to a far-away target, but all the discarded bits do have an effect on the mouse even during fast motion.

I just hacked around this by moving the division into the rendering & slope calculations and scaling all the constants up by 8, although this is a bit more intrusive than I like. Maybe it'd be better to retain the current scale of lookdir and instead stash the remainder of the original division somewhere (player2_t? static variable in the function that does the division?). But I think you'd be better to decide which way is best. In any case, here's my hack (which does indeed make the mouse action butter smooth for me).

diff -uNp doom.old/g_game.c doom/g_game.c
--- doom.old/g_game.c   Mon Jul  7 19:36:20 2014
+++ doom/g_game.c       Mon Jul  7 19:38:06 2014
@@ -620,13 +620,13 @@ void G_BuildTiccmd (ticcmd_t* cmd, int maketic) 
          crispy_mouselook)
     {
         players2[consoleplayer].lookdir +=
-            (mouse_y_invert ? -mousey : mousey) / 8;
+            (mouse_y_invert ? -mousey : mousey);
 
-        if (players2[consoleplayer].lookdir > 90)
-            players2[consoleplayer].lookdir = 90;
+        if (players2[consoleplayer].lookdir > 90 * 8)
+            players2[consoleplayer].lookdir = 90 * 8;
         else
-        if (players2[consoleplayer].lookdir < -110)
-            players2[consoleplayer].lookdir = -110;
+        if (players2[consoleplayer].lookdir < -110 * 8)
+            players2[consoleplayer].lookdir = -110 * 8;
     }
     else
     if (!novert)
diff -uNp doom.old/p_mobj.c doom/p_mobj.c
--- doom.old/p_mobj.c   Mon Jul  7 19:36:20 2014
+++ doom/p_mobj.c       Mon Jul  7 19:20:09 2014
@@ -1038,7 +1038,7 @@ P_SpawnPlayerMissile
        {
            an = source->angle;
            if (singleplayer && crispy_freeaim)
-               slope = ((p2fromp(source->player)->lookdir) << FRACBITS) / 173;
+               slope = ((p2fromp(source->player)->lookdir / 8) << FRACBITS) / 173;
            else
            slope = 0;
        }
diff -uNp doom.old/p_pspr.c doom/p_pspr.c
--- doom.old/p_pspr.c   Mon Jul  7 19:36:20 2014
+++ doom/p_pspr.c       Mon Jul  7 19:20:19 2014
@@ -637,7 +637,7 @@ void P_BulletSlope (mobj_t* mo)
            if (!linetarget && singleplayer && crispy_freeaim)
            {
                an = mo->angle;
-               bulletslope = ((p2fromp(mo->player)->lookdir) << FRACBITS) / 173;
+               bulletslope = ((p2fromp(mo->player)->lookdir / 8) << FRACBITS) / 173;
            }
        }
     }
diff -uNp doom.old/p_user.c doom/p_user.c
--- doom.old/p_user.c   Mon Jul  7 19:36:20 2014
+++ doom/p_user.c       Mon Jul  7 19:25:06 2014
@@ -184,10 +184,10 @@ void P_MovePlayer (player_t* player)
         }
         else
         {
-            player2->lookdir += 5 * look;
-            if (player2->lookdir > 90 || player2->lookdir < -110)
+            player2->lookdir += 8 * 5 * look;
+            if (player2->lookdir > 90 * 8 || player2->lookdir < -110 * 8)
             {
-                player2->lookdir -= 5 * look;
+                player2->lookdir -= 8 * 5 * look;
             }
         }
     }
@@ -195,13 +195,13 @@ void P_MovePlayer (player_t* player)
     {
         if (player2->lookdir > 0)
         {
-            player2->lookdir -= 8;
+            player2->lookdir -= 8 * 8;
         }
         else if (player2->lookdir < 0)
         {
-            player2->lookdir += 8;
+            player2->lookdir += 8 * 8;
         }
-        if (abs(player2->lookdir) < 8)
+        if (abs(player2->lookdir) < 8 * 8)
         {
             player2->lookdir = 0;
             player2->centering = false;
@@ -233,11 +233,11 @@ void P_DeathThink (player_t* player)
     if (player->viewheight < 6*FRACUNIT)
        player->viewheight = 6*FRACUNIT;
 
-    if (player2->lookdir >  8)
-        player2->lookdir -= 8;
+    if (player2->lookdir >  8 * 8)
+        player2->lookdir -= 8 * 8;
     else
-    if (player2->lookdir < -8)
-        player2->lookdir += 8;
+    if (player2->lookdir < -8 * 8)
+        player2->lookdir += 8 * 8;
     else
     if (player2->lookdir)
         player2->lookdir = 0;
diff -uNp doom.old/r_main.c doom/r_main.c
--- doom.old/r_main.c   Mon Jul  7 19:36:20 2014
+++ doom/r_main.c       Mon Jul  7 19:14:44 2014
@@ -840,7 +840,7 @@ void R_SetupFrame (player_t* player)
 
     viewz = player->viewz;
 
-    tempCentery = viewheight / 2 + ((player2->lookdir) << (hires && !detailshift)) * (screenblocks < 11 ? screenblocks : 11) / 10;
+    tempCentery = viewheight / 2 + ((player2->lookdir / 8) << (hires && !detailshift)) * (screenblocks < 11 ? screenblocks : 11) / 10;
     if (centery != tempCentery)
     {
         centery = tempCentery;

[fabian]

I admit, that division by factor 8 was an arbitrary measure to keep vertical mouse movement "on a reasonable scale". It never came to my mind to adjust the scale itself instead of that value and, of course, at first I was hesitant to spread that arbitrary factor all across the code. But then I found "butter smooth mouse action" too convincing. ;)

I have named the factor MLOOKUNIT by means of a #define, so it doesn't get lost in the code should I ever find a less intrisuve solution. This will get commited shortly.

Thank you very much again, this is highly appreciated!

[plums]

Hey fabian, do you compile the Windows builds with cygwin, or do you just cross-compile in Linux?

[fabian]

plums said:

Hey fabian, do you compile the Windows builds with cygwin, or do you just cross-compile in Linux?

It's a native build with MinGW.

[plums]

Thanks, I'll try setting that up. I tried getting Chocolate Doom to build in Windows a while ago with Cygwin but ran into some problems and haven't been up to trying to get it to work since.

[Gagert]

Hi. I'm new here at Doomworld, so this is my very first post here.

I have tried various ports of Doom previously, including those with 3D-models, better textures and better sound etc. Somehow the original Doom-feel disappeared once the all those graphic enhancements got put together, and I wanted to experience the dark, gritty feel of the original DOS-Doom once again.

Later on I tried Prboom+, can't put my finger on it, but I just didn't like the in-game feeling of it. Something just felt wrong with that port.

Then I tried Chocolate Doom, and damn that felt good. Just like Doom on a DOS-machine. The dark, gritty feel of the original Doom was back, and even the low resolution made a return.

Even then I felt something was missing. The resolution was in fact a tad too low, and I remember how much I enjoyed playing the demo version of Doom 95 once upon a time. I wanted Chocolate Doom, but with double the resolution.

Not long ago I found this fork of Chocolate Doom, and I'm impressed. But still there is one thing I miss with this excellent port.


When I'm in my couch in front of my big-screen TV, I like to have a Xbox 360 controller in my hand while playing certain games. I'm fully aware that the Xbox 360 controller is partially supported through Chocolate Doom, but it's not fully supported like in the Doom 64 PC port; Doom 64 Ex.

I have no option for mapping either the left- or right trigger buttons (useful for changing weapons). Also I have no option for mapping any of my gamepad-buttons to view the map, or even make a button act as the run-key. The "Turn left/right" option does not have any kind of sensitivity, so even a tiny touch on the analogue stick makes the Doom guy take a sharp turn in one or the other direction.

The question people may ask is why I don't instead use the mouse-keyboard-combo while playing Cryspy Doom in front of my TV, and my answer to that is that I feel the mouse make the aiming a little to precise/easy for being a game that was not originally designed to play with the mouse-keyboard-combo. Playing with a controller on the other hand doesn't make you that super OP in my opinion (and I enjoy playing with a controller).

Any plans of further improving the controller-support on Crispy Doom?

[fabian]

Gagert said:

Not long ago I found this fork of Chocolate Doom, and I'm impressed. But still there is one thing I miss with this excellent port.

Thank you very much!

Any plans of further improving the controller-support on Crispy Doom?

Actually, Crispy Doom is a fork still very close to Chocolate Doom. My philosophy is to apply any fixes that could help both ports first in Chocolate Doom and merge them back later into Crispy. Since improvements for the controller-support are in no way specific to Crispy Doom, that request is best addressed directly at Choco.

I am afraid, however, that I won't be of much help in this regard since I don't have an Xbox controller and have no deep experience with SDL's I/O code.

It should be possible, however, to map a Controller key to "Run" or "Change Weapon" even now.

[plums]

Gagert said:

Any plans of further improving the controller-support on Crispy Doom?

As a work-around, have you tried a program like JoyToKey?

[Gagert]

Maybe I should give that a try, and edit the config afterwards. I posted a suggestion in the GitHub home to Chocolate Doom regarding controller support minutes ago, so we'll see.

[fabian]

Update 18 Aug 2014: Crispy Doom 1.5 "Supernova" 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 release contains the most extensive changes since Crispy Doom 1.1. Highlights of this release:

* Tons of compatibility fixes (removed limits, support for huge BLOCKMAPS, extended nodes, Medusa and Tutti Frutti fixes, etc.)
* Monster targets preserved in savegames.
* Automap improvements.
* Mouse look improvements.
* SPECHITS cheat code.
* 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_1.5.zip

Have a lot of fun!

- Fabian

[manny]

It seems that flats get more distorted the closer they are to the right edge of the screen. This is also visible in low quality mode and Chocolate Doom, but is less pronounced because of the low resolution. Other software rendering ports, in particular Doom Retro which is also based on Chocolate Doom, do not seem to have this problem. Here are some comparison shots: .

Additionally, the flats seem to twitch on the right side when slowly turning.

[fabian]

manny said:

It seems that flats get more distorted the closer they are to the right edge of the screen. This is also visible in low quality mode and Chocolate Doom, but is less pronounced because of the low resolution. Other software rendering ports, in particular Doom Retro which is also based on Chocolate Doom, do not seem to have this problem.

Oh, indeed this looks clumsy, though I have never noticed this myself before. Brad, do you still know which fix this required?

[bradharding]

fabian said:

Oh, indeed this looks clumsy, though I have never noticed this myself before. Brad, do you still know which fix this required?

Yes, it just requires a rewrite of R_DrawSpan():

void R_DrawSpan(void)
{
    unsigned int        count = ds_x2 - ds_x1 + 1;
    byte                *dest = ylookup[ds_y] + ds_x1 + viewwindowx;
    fixed_t             xfrac = ds_xfrac;
    fixed_t             yfrac = ds_yfrac;
    const fixed_t       xstep = ds_xstep;
    const fixed_t       ystep = ds_ystep;
    const byte          *source = ds_source;
    const lighttable_t  *colormap = ds_colormap;

    while (--count)
    {
        *dest++ = colormap[source[((yfrac >> 10) & 4032) | ((xfrac >> 16) & 63)]];
        xfrac += xstep;
        yfrac += ystep;
    }
    *dest = colormap[source[((yfrac >> 10) & 4032) | ((xfrac >> 16) & 63)]];
}

[fabian]

bradharding said:

Yes, it just requires a rewrite of R_DrawSpan():

Thank you!

The original code has a lot more bit shifting and masking that seems to suffer from loss of precision with increasing x coordinate. I have changed the few relevant lines in DrawSpan() and it renders fine now. Thanks again!

[Average]

Hey Fabian, I think I've found a bug. If I set the UP arrow key to 'fire' it still moves Doomguy forward. FYI I use WASD and UP-fire, DOWN-next weapon and LEft and RIGHT for turning. :)

[plums]

Average said:

Hey Fabian, I think I've found a bug. If I set the UP arrow key to 'fire' it still moves Doomguy forward. FYI I use WASD and UP-fire, DOWN-next weapon and LEft and RIGHT for turning. :)

You can work around this by changing the "Move cursor up" and "Move cursor down" keys in the "Other keys..." section of the keyboard config to something else, like W and S. Of course this means that the arrow keys won't work in the menu, unfortunately.

[Average]

Thanks for the work around. I'll give it a bash. :)

[fabian]

Average said:

Hey Fabian, I think I've found a bug. If I set the UP arrow key to 'fire' it still moves Doomguy forward. FYI I use WASD and UP-fire, DOWN-next weapon and LEft and RIGHT for turning. :)

Thanks for the report! I'd rather call it a feature than a bug, though: When I am at my desk, I prefer WASD (keyboard strafe) with mouse look. whereas, when I am on the train, I usually prefer the arrow keys (keyboard turn). Crispy supports both setups by mapping the menu keys to movement when not in a menu. As plums already pointed out, you may want to remap the menu keys to the movement keys to work around this behaviour (or you could use the mouse wheel to scroll through the menus).

[plums]

fabian said:

Thanks for the report! I'd rather call it a feature than a bug, though: When I am at my desk, I prefer WASD (keyboard strafe) with mouse look. whereas, when I am on the train, I usually prefer the arrow keys (keyboard turn). Crispy supports both setups by mapping the menu keys to movement when not in a menu. As plums already pointed out, you may want to remap the menu keys to the movement keys to work around this behaviour (or you could use the mouse wheel to scroll through the menus).

Hmm, having multiple buttons per action is nice, but I'm not so sure that overloading the menu keys is the way to do it. I tried Average's key setup for a bit and not being able to use the arrow keys to move in the menu got pretty frustrating, even though it's a relatively small thing. It's probably something that I could adjust to after a while, but then when using other ports I'd expect to use W and S to move in the menu, which would mean remapping those keys in all other ports -- and not all of them support doing that!

Since using the menu keys to move is a crispy-specific feature anyhow, is it too much to just add some "alternate movement" keys? Other fixes might be to only use key_menu_up/down to move if those keys don't have another function (seems like it would require a lot of checks), or hardcode up and down arrows to moving in the menu. (eek!)

[fabian]

plums said:

Since using the menu keys to move is a crispy-specific feature anyhow, is it too much to just add some "alternate movement" keys? Other fixes might be to only use key_menu_up/down to move if those keys don't have another function (seems like it would require a lot of checks), or hardcode up and down arrows to moving in the menu. (eek!)

That's tricky! I could additionally allow key_automap_{north,south} in menus, which are also mapped to arrow up/down. If you remap your menu keys to your movement keys then, you'd still be able to scroll through menus and the automap as usual. Phew, I am not sure about that. :/

[fabian]

fabian said:

Phew, I am not sure about that. :/

Because it's all hack! I'll implement key_alt_* in the next release. If I forget about it, beat me to it. :)

[Dragonsbrethren]

Attempting to open the yellow door in BTSX E2 MAP01 without the key will make the latest version (8/18) bomb out with a Bad V_DrawPatch error. Not an issue in Chocolate or vanilla.

[plums]

Ah, the text string is too long for the screen with the BTSX font. I actually just had this problem with HacX but I thought it was the Dehacked patch to blame.

[fabian]

Thanks for the report, Dragonsbrethren, and thanks for the analysis and forwarding to the Github bug tracker, plums!

This is indeed a very old bug, an oversight from the first patch that finally became Crispy Doom. I am curious why this hasn't become an issue earlier. Anyway, it is fixed in GIT now. As a workaround, I'd recommend playing with "Messages: Off" until I finally manage to bring up the next release.

[plums]

fabian said:

I am curious why this hasn't become an issue earlier.

Well, none of the strings in Doom are normally long enough to trigger it, and replacing the messages font is not something that most wads do.

As a workaround, I'd recommend playing with "Messages: Off" until I finally manage to bring up the next release.

In this specific instance you could also add this to the Dehacked patch.

Text 45 41
You need a yellow key to activate this objectNeed a yellow key to activate this object

[sector666]

This screenshot on the Doom picture thread made me think of something. I know that all the numbers on the minimal Crispy hud are in the original place. But without the "Ammo, Health, etc" line there, the numbers there look a little out of place floating above where that line used to be.

When using the minimal hud is there any way to move the hud info there closer to the bottom? (Preferably even with the bottom of the numbers all the way to the right?) If not that'd be a nice option to have.

[fabian]

Hm, honestly, I'd rather like to keep the numbers "where they belong". My eyes are used to look right there and I like how they line up when switching to the automap and back.

Also, as they are now, they are at least even with the +top* of the numbers all the way to the right. ;)

[joe-ilya]

You should fix the menu, it's possible to hold the menu button and the menu will go turbo, I know it happens in most source ports but you should fix that.

[plums]

Could you clarify? Do you mean holding ESC causes the menu to flicker on and off repeatedly?