Crispy Doom 6.0 (Update: Mar 31, 2023)

[plums]

2 minutes ago, kokrean said:

Is there widescreen option for crispy heretic?

Nope. In theory it shouldn't be too hard to port from Crispy Doom, but someone has to actually do it, which hasn't happened yet. (fabian is happy to take patches for Crispy Heretic but has no interest in developing it himself.)

[Ks4]

On 10/19/2020 at 4:20 AM, fabian said:

I am going to have all special treatment for the NRFTL episode intact even during demo recording and playback for the next Crispy Doom release.

 

I think that you should not to do that, prboom is the only port that don't show the intermission ending screen after map 6 with -record parameter, I think that have to removed from prboom because it's vanilla doom behavior.

Edited December 8, 2020 by kokrean

[xttl]

edit: nevermind, seems --enable-truecolor=no still enabled it :)

 

(I tried compiling with =yes first, then recompiled with =no when I noticed a problem, but it seems I had to remove the parameter completely instead to disable it...)

Edited December 8, 2020 by xttl

[VGA]

Image doesn't load

[xttl]

1 hour ago, VGA said:

Image doesn't load

 

Yeah I removed it because the problem was caused by enabling the truecolor mode which is still marked as experimental. But if you want to see what it looked like, here:

 

 

(notice the bottom left/right corners, regular reduced screen size border still worked fine though)

[wrkq]

15 minutes ago, xttl said:

(I tried compiling with =yes first, then recompiled with =no when I noticed a problem, but it seems I had to remove the parameter completely instead to disable it...) 

 

Aren't autoconf --enable-xyz flags usually paired with --disable-xyz?

[xttl]

1 hour ago, wrkq said:

 

Aren't autoconf --enable-xyz flags usually paired with --disable-xyz? 

 

Help text with a quick glance said:

  --enable-truecolor      true-color rendering (experimental) [default=no]

so I just went by that.

 

Seems it also says:

  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)

so probably it should have worked, but w/e, at least it works now.

 

I tried it again, and I really do get that bug with the widescreen status bar borders if I compile with --enable-truecolor=no. --disable-truecolor also builds a buggy binary. Only leaving out the parm completely works!

[fabian]

My autoconf-foo was failing on me. /o\ I have fixed this in GIT, and the rendering glitch of the status bar bezel in widescreen mode, thanks!

 

@xttl Could you please try again with the current state in GIT?

Edited December 9, 2020 by fabian

[🌸 V E W M 3 2 🌸]

Ideas regarding coloured hud flashes in truecolor mode, inspired by your response on this thread: https://www.doomworld.com/forum/post/2227840

A toggleable option that changes the palette of everything based on the wad-defined palettes, while still applying all the truecolor lighting shenanigans. Like if you were to somehow change palette 0 midgame, it changes the palette of all the textures/sprites/etc, but still does the truecolor lighting on top of that. It absolutely would not have the same effect as the original wad maker's intent, but it might be an interesting half-fix for those that want it. Definitely not enabled by default.

Or, maybe, an option for users or mods to define their own truecolor screen blends. Not sure how the mod-defined part would work though, lump-wise.

Should say, I am no programmer nor do I have any idea how much progress you've made on this already and thus if these suggestions are redundant. Maybe all of these suggestions are too obvious and have already been thought of and are completely useless.

[xttl]

22 hours ago, fabian said:

My autoconf-foo was failing on me. /o\ I have fixed this in GIT, and the rendering glitch of the status bar bezel in widescreen mode, thanks!

 

@xttl Could you please try again with the current state in GIT? 

 

Yes, both --disable-truecolor and --enable-truecolor=no seem to work as expected now (CRISPY_TRUECOLOR not defined in config.h), and the screen border fill in widescreen mode also has the correct palette even when built with truecolor enabled.

[fabian]

2 hours ago, xttl said:

Yes, both --disable-truecolor and --enable-truecolor=no seem to work as expected now (CRISPY_TRUECOLOR not defined in config.h), and the screen border fill in widescreen mode also has the correct palette even when built with truecolor enabled.

 

How do you like the look of the rendering (especially translucency, which is where truecolor rendering really shines)? Make sure to have `crispy_truecolor` set to `1` in your config file.

 

[xttl]

I don't have much of an opinion on the transparencies because I've generally always disabled them in all ports except when playing maps or mods I know to use them (so mostly ZDoom/GZDoom-exclusive stuff which I only play occasionally, with the odd Boom map that actually uses transparencies). From what little I looked at it now, yes, in general the transparent items look better (at least more consistent). It seems Crispy Doom already didn't have the worst transparencies in 8-bit mode anyway, compared to old autogenerated Boom TRANMAPs for example (they made a lot of transparent blues and greens always look gray). Truecolor rendering would certainly benefit transparent textures very noticeably, but alas, Crispy Doom has no support for Strife or Boom maps. :P

 

The big reason I was interested in truecolor was lighting and yes, that definitely looks better now. Especially when certain colors (pink and red) and dark environments are involved.

 

The partial invisibility effect looks too dark/opaque against most backgrounds compared to the 8-bit renderer, so partially invisible sprites are too easy to see (look at the comparison pics of map03 Spectres), but it's probably hard to make it look just right always in all cases when not using the old colormap based approach.

 

 

 

Oh yeah, there's a new minor bug now with the initial screen wipe when going to directly to game on startup in widescreen mode (see corners):

 

The same bug also appears with the widescreen assets from Unity engine port IWAD loaded, just with data from the new status bar graphic instead of border padding:

 

 

Using higher d values (0xF0 in this case) for I_BlendDark gives results closer to the old renderer in MAP03:

 

But then the effect looks too transparent compared to the old renderer in bright environments, 8-bit paletted:

 

Truecolor with d=0xF0:

 

I tried 0xD8 as a midway compromise between 0xC0 and 0xF0 and it looks about right in fullbrighted E1M3, but is already too dark in the MAP03 location. Also, these screenshots starting to eat away a lot of attachment space, I think I'll have to remove them or convert to jpegs later...

 

One more thing I thought I might be worth trying is to copy the formula from dcolors.c that was used to calculate colormaps[6] in the first place (well, the colour values that were then used to find the closest available colour from the palette anyway):

red = (red*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS;
green = (green*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS;
blue = (blue*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS;

for l=6 becomes

pixel_t FuzzBlend(pixel_t original)
{
  uint32_t r,g,b;
  pixel_t newpx;

  r = (original & rmask)>>16;
  g = (original & gmask)>>8;
  b = original & bmask;

  r = (r*26+16) / 32;
  g = (g*26+16) / 32;
  b = (b*26+16) / 32;

  newpx = (r<<16) | (g<<8) | b;

  return newpx;
}

used in R_DrawFuzzColumn in place of I_BlendDark like this

/* *dest = I_BlendDark(dest[fuzzoffset[fuzzpos]], 0xC0); */
*dest = FuzzBlend(dest[fuzzoffset[fuzzpos]]);

 

Unfortunately the result still seems slightly too dark against some backgrounds, so either there is something I'm missing or the 256 colour quantization process (esp. when combined with repeated lookups from the colormap?) affects final perceived brightness enough that a more complex calculation is needed to simulate the original look:

 

On the other hand this spot in Plutonia doesn't look so bad using the formula from dcolors.c,

 

8-bit:

 

Truecolor with dcolors.c formula:

 

I_BlendDark with d=0xC0 (shot is taken in low detail mode because I left the code for that untouched so I can easily switch between original and modified fuzz blending):

 

Only I_BlendDark w/ d=0xC0 looks very noticeably too dark here.

 

I think fullbright E1M3 doesn't look bad either with this formula (compare with 8-bit above):

 

Yet another thing I noticed now is that the truecolor fuzz drawer should also probably always multiply fuzzoffset[fuzzpos] by SCREENWIDTH like the 8-bit code does. It works just fine and looks better, and more like the 8-bit mode.

 

 

one last update:

 

If I understood everything correctly, then using I_BlendDark with d=0xD3 (alpha value 211 or ≈0.82) should give the same results as using the dcolors.c colormaps[6] formula. So still not perfect as can be seen from the MAP03 shots, but generally closer to 8-bit than 0xC0.

 

Edited December 10, 2020 by xttl

[fabian]

I have applied your suggestions in GIT, thank you very much!

[xttl]

It seems some stray invisible characters slipped into the doom/r_draw.c changes :-)
 

Spoiler

 

make[3]: Entering directory '/home/***/crispy-doom/src/doom'
  CC       r_draw.o
r_draw.c: In function ‘R_DrawFuzzColumn’:
r_draw.c:417:64: error: stray ‘\357’ in program
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                ^
r_draw.c:417:65: error: stray ‘\273’ in program
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                 ^
r_draw.c:417:66: error: stray ‘\277’ in program
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                  ^
r_draw.c:417:67: error: expected ‘)’ before numeric constant
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                   ^

 

 

 

 

and so on for lines 436, 503, ...

After removing those it compiled fine.

 

I think the initial screen wipe in widescreen mode could be fixed by simply checking for st_firsttime in st_stuff.c line 485, ie. this

if ((SCREENWIDTH >> crispy->hires) != ST_WIDTH)

becomes

if (((SCREENWIDTH >> crispy->hires) != ST_WIDTH) && !st_firsttime)

 

edit: unfortunately not, if using Unity WAD's widescreen status bar it is still broken.

 

But adding a check for st_firsttime to the beginning of ST_refreshBackground does work with both regular and widescreen STBAR, ie.

if (st_classicstatusbar || force)

becomes

if ((st_classicstatusbar || force) && !st_firsttime)

not sure if it's the best solution though.

Edited December 10, 2020 by xttl

[xttl]

I'm trying to add widescreen to Crispy Heretic. It was really easy (<30mins job) to get sprites and walls (ie. everything drawn as columns) working properly by copying a bit of code from the Doom side, but flats (spans) have serious distortion I've yet to figure out how to fix. Any tips, @fabian?

 

Okay, I was looking in the wrong places, I just adapted/copied the "accuracy improved" R_MapPlane code from Crispy Doom and it seems to be working fine in-game now with screenblocks==11. Then I need to catch and fix all the HUD, intermission, etc. stuff that needs fixing.

 

 

Current status: automap and page drawing (titlepic, etc.) are still broken but otherwise everything (game view, HUD, intermissions, etc.) seems to be working. I need some rest right now, however. I also ported the notarget cheat from Crispy Doom because I like it.

 

Just before posting this I noticed the top border is not always drawn correctly in hires mode for all reduced screen sizes, but it happens in Crispy Hexen too (which I haven't touched at all) so seems it's not caused by my changes.

 

Attachments include source diff and a Windows binary. Binary was built with MSVC (2015) so it may have some hidden problems. The PACKED_STRUCT macro that's apparently supposed to handily pack certain structs on both GCC and MSVC didn't work at all for me (caused zillions of <class-head> errors), so I removed it completely and compiled with /Zp1. This change is omitted from the source diffs since it is not necessary for GCC builds. I also couldn't get libsamplerate to work at all without crashing (perhaps because it's *not* been compiled with /Zp1? SDL still works...) so use_libsamplerate is disabled.

 

Compiling on not Windows should be very straightforward (at least was for me) but don't --enable-truecolor when you compile it, that currently breaks Heretic completely.

 

crispy_wide_tic_srcdiff.zip

crispy_wide_tic_bin.7z

 

Edited December 11, 2020 by xttl

[fabian]

19 hours ago, xttl said:

It seems some stray invisible characters slipped into the doom/r_draw.c changes :-)

 

Oh, how did these get in there? I guess this is what you get copy copying from a browser into an editor. /o\

 

19 hours ago, xttl said:

  Reveal hidden contents

 

make[3]: Entering directory '/home/***/crispy-doom/src/doom'
  CC       r_draw.o
r_draw.c: In function ‘R_DrawFuzzColumn’:
r_draw.c:417:64: error: stray ‘\357’ in program
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                ^
r_draw.c:417:65: error: stray ‘\273’ in program
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                 ^
r_draw.c:417:66: error: stray ‘\277’ in program
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                  ^
r_draw.c:417:67: error: expected ‘)’ before numeric constant
  *dest = I_BlendDark(dest[SCREENWIDTH*fuzzoffset[fuzzpos]], 0xD3);
                                                                   ^

 

 

 

 

 think the initial screen wipe in widescreen mode could be fixed by simply checking for st_firsttime in st_stuff.c line 485, ie. this

 

Hm, this is strange. I'll have to investigate this...

 

15 hours ago, xttl said:

Okay, I was looking in the wrong places, I just adapted/copied the "accuracy improved" R_MapPlane code from Crispy Doom and it seems to be working fine in-game now with screenblocks==11. Then I need to catch and fix all the HUD, intermission, etc. stuff that needs fixing.

 

Cool, thanks for doing this! I hope you are going to file a pull request once you consider your effort finished?

[El Franko]

I know I bothered you guys with this before, but hear me out. So Crispy Doom works fine on my PC, but I recently suffered a system crash and my PC is somewhat busted with a BSoD. So I decided to temporarily transfer to my laptop. The thing is, for some reason Crispy Doom's main executable and the setup refuse to be installed on my laptop. Even whenever I open the zip file containing the executables they immediately vanish from my laptop's system. Or whenever they do appear, they refuse to be clicked on and will also mysteriously vanish.

 

Is there any way I can get my laptop to stop acting like jerk and allow me to rightfully play Crispy Doom?

 

(Other source ports like Chocolate Doom, PrBoom+, and GZDoom work perfectly fine tho)

[fabian]

Most probably some antivirus bullshit. 

[xttl]

4 hours ago, fabian said:

Cool, thanks for doing this! I hope you are going to file a pull request once you consider your effort finished?

 

I have about zero previous experience using git and github other than git cloning a repo to build something locally, but I can try. :P I also attached a diff of the changes so far in the previous post.

 

Btw. is something like support from loading maps directly from PSXDOOM CD images or extracted data files (while still using the PC IWAD for everything except textures and maps) out of the scope or too hacky for Crispy Doom? Those could benefit a lot from the truecolor renderer, they have partially transparent textures and coloured sector lighting.

 

^{(also everyone please don't take this as a promise to definitely code something like that, I'm just asking to make sure it wouldn't become wasted effort in case)}

 

Also, what's the status of Crispy Hexen, is it discontinued / not maintained anymore? Seems it's not even built by default and has no "crispness" menu, but still features working hires mode. I might be interested in fixing widescreen support in it too.

Edited December 11, 2020 by xttl

[VGA]

What about Russian Doom? It has Heretic support, doesn't it?

[fabian]

On 12/11/2020 at 7:45 PM, xttl said:

 

I have about zero previous experience using git and github other than git cloning a repo to build something locally, but I can try. :P I also attached a diff of the changes so far in the previous post.

 

I have seen that, thank you! However, it is _a lot_ more convenient to review and discuss a patch as a pull request on Github than posting patch files on a forum. Also, sorry, but no way I can accept a patch that adds both a widescreen implementation and a random cheat code at the same time (though I would immediately accept the cheat code if you could sort it out into a separate patch). It would be a lot easier to sort this out on GIT branches as well. So, after all it makes sense to have a Github account for the occasional contribution to an open source project hosted there anyway. Learning GIT itself isn't that hard as well - I have just learned the basics of SVN when the GIT revolution came and, though feeling a bit uncommon at first, quickly got used to it.

 

Quote

Btw. is something like support from loading maps directly from PSXDOOM CD images or extracted data files (while still using the PC IWAD for everything except textures and maps) out of the scope or too hacky for Crispy Doom? Those could benefit a lot from the truecolor renderer, they have partially transparent textures and coloured sector lighting.

 

I'd not be opposed to this, although it sounds like a very very niche feature to me. However, please note that truecolor rendering will remain a compile time option for the time being. First, because the three non-Doom games are in no way prepared for it yet. Second, because this rendering mode only uses the first palette, so any mod with a custom PLAYPAL (or COLORMAP) will look differently than intended by its author. Third, it cannot use a foreground/background lookup table for transparencies anymore, so all values for all three RGB channels have to be calculated for each transparent pixel during each rendered frame - which consumes quite a lot of computing time.

 

Quote

Also, what's the status of Crispy Hexen, is it discontinued / not maintained anymore? Seems it's not even built by default and has no "crispness" menu, but still features working hires mode. I might be interested in fixing widescreen support in it too.

 

It is just as unmaintained as Crispy Heretic was earlier this year. As soon as someone steps up to add some features to it, I'll be happy to add it back to the releases as well. Note that it is still part of the source release and compiling it is as easy as "cd src && make -C hexen && make crispy-hexen". It is just that I keep it out of releases because it is far from par with Heretic - and especially Doom - feature-wise. I want to avoid to raise peoples' expectations by releasing a game that I am not going to maintain with the same amount of effort.

 

Edited December 12, 2020 by fabian

[Alaux]

Hey there. I noticed that Boom and MBF DeHackEd flags (things like Friendly, Bounces and Translucent) do not seem to work, unlike the extra frames and A_ functions which do work. I don't know if this is an already known issue or not, but I figured I'd mention it.

[xttl]

7 hours ago, fabian said:

It is just as unmaintained as Crispy Heretic was earlier this year. As soon as someone steps up to add some features to it, I'll be happy to add it back to the releases as well. Note that it is still part of the source release and compiling it is as easy as "cd src && make hexen && make crispy-hexen".

 

Yeah, I noticed it compiles just fine (just not built by default) which is how I also noticed it has working hires support (by compiling and running it). :P

 

I created an account on github now. I could actually port all the new cheat codes from Crispy Doom to Heretic while I'm at it. I forked the repo and cloned it locally, next I should create a new branch (called eg. heretic_cheatcodes), make my changes there (only the cheat related ones) and then submit a pull request to you, right?

 

On 12/12/2020 at 12:02 AM, VGA said:

What about Russian Doom? It has Heretic support, doesn't it?

 

I didn't even know about this Doom source port before. I'll check it out.

[fabian]

26 minutes ago, xttl said:

I created an account on github now. I could actually port all the new cheat codes from Crispy Doom to Heretic while I'm at it. I forked the repo and cloned it locally, next I should create a new branch (called eg. heretic_cheatcodes), make my changes there (only the cheat related ones) and then submit a pull request to you, right?

 

Absolutely! 

[fabian]

3 hours ago, Alaux said:

Hey there. I noticed that Boom and MBF DeHackEd flags (things like Friendly, Bounces and Translucent) do not seem to work, unlike the extra frames and A_ functions which do work. I don't know if this is an already known issue or not, but I figured I'd mention it.

 

That's expected, most of Boom's features are not implemented - extra frames and states and action pointers being the notable exception. 

[xttl]

6 hours ago, fabian said:

Absolutely! 

 

It looks like on the Doom side P_GiveWeapon in p_inter.c was modified to print weapon pickup messages using a new string pointer array: WeaponPickupMessages (to make the messages visible in multiplayer modes where weapons stay). The same array is also reused for printing messages in the give/take weapon cheat. Crispy Heretic does not have this feature.

 

If I make this modification (show weapon pickup msgs in netgames) to p_inter.c, it is not a strictly cheatcode related change, but it *is* a good change which should be made at some point anyway (though in Heretic only affects cooperative because old-style deathmatch is missing... which in itself might be another good future addition), and it makes sense to use the same array for this and the cheatcode.

 

So I created a pull request just for this first on github now.

[fabian]

On 12/11/2020 at 12:15 AM, xttl said:

Just before posting this I noticed the top border is not always drawn correctly in hires mode for all reduced screen sizes, but it happens in Crispy Hexen too (which I haven't touched at all) so seems it's not caused by my changes.

 

Could you please file an issue for this together with a way to reproduce it?

[Smite of Disrespect]

Turning on Weapon Recoil Pitch causes the sky to be stretched!

 

Spoiler

Before:

 

 

 

After:

 

[fabian]

Yes, of course, because your vertical view angle changes and would expose the boundaries of the sky texture otherwise. 

[fabian]

On 12/13/2020 at 4:57 AM, xttl said:

If I make this modification (show weapon pickup msgs in So I created a pull request just for this first on github now.

You've submitted a very good first pull request. I've reviewed it and requested a few tiny changes. If you apply these, I will commit it immediately.