Crispy Doom 6.0 (Update: Mar 31, 2023)

[Jon]

I guess implementing just the music bit of MAPINFO would have been a lot harder.

[Gez]

11 hours ago, kb1 said:

Is it really that bad? I haven't seen examples yet, but I thought the goal was to provide similarity. Maybe you mean C vs. C++? :)

Is it just that it's not yet mature, or has it actually gone down a different path?

Well, I'll just answer with a couple links. Here's the DoomImp in...

• ZDoom DECORATE
• Eternity DECORATE

 

 

 

Edited March 30, 2017 by Gez : changed ZDoom link to one that includes doomednum for fuller comparison

[BigDickBzzrak]

About this D_E4Mx feature, a thought I just had:

what will happen if I type IDMUS41? Usually it would play the title track or something, but what to do if we have an actual E4 track?

[fabian]

5 hours ago, bzzrak said:

what will happen if I type IDMUS41? Usually it would play the title track or something, but what to do if we have an actual E4 track?

The IDMUS cheat will work as before, not sure how to fix that.

 

19 hours ago, Grain of Salt said:

I've always thought it'd be really cool to be able to see statistics for stuff like your accuracy and health conservation while you're playing. It's helpful to be able to measure your progress in specific terms.

How do you think these statistics are best exposed to the player? Crispy doesn't have a console (no, never, thanks for not asking) and I don't want to stress the Automap window any further.

[Grain of Salt]

I was imagining it as a collection of plain messages in the top-left corner, à la Chocorenderlimits.

[kb1]

13 hours ago, Gez said:

Well, I'll just answer with a couple links. Here's the DoomImp in...

• ZDoom DECORATE
• Eternity DECORATE

 

 

 

Frame definition is almost identical in structure (with each having unique func pointers, of course). Differences in actor defs seem to be due to the ways each port presents data. Eternity member names more closely match original Doom members. ZDoom data is abstracted a bit more (sound names, for example). However, all in all, it's the same basic parsing and the same data. Code that can parse one dialect could potentially parse the other, and could stand a chance of being converted back and forth. I could envision a specification being written to strictly define a subset of these possibilities, that could be loaded by any engine. That would be a huge leap forward for compatibility. One can dream :)

[Death Egg]

I have another suggestion, but it's a bit more drastic so it might be denied. When the IWAD for a Doom 1-based game, whether Ultimate Doom or Freedoom Phase 1 or even The People's Doom has a M_EPI4 lump in it, that's what activates the fourth episode. What if, when a modder puts an M_EPI5 or higher lump, along with relevant files, they are able to add episodes in? There would probably be a lot of logistics to figure out to get it working in a way that's easy, accessible, and doesn't break the spirit of the original. Just offhand I can imagine it being great for Xaser's The Lost Episode to be ported to a limit removing engine without replacing the original maps. Just like my previous idea, it wouldn't effect legacy mods or ones that don't have relevant data in the wad, only mods that are specifically designed for it.

 

This might be getting a bit close to MAPINFO so hopefully that doesn't deter people from the idea. Especially since MAPINFO seems too advanced for a port like this.

 

EDIT: Also doesn't the original Doom have code for a fifth episode but it isn't finished?

 

One big issue I also thought of after posting is secret map locations, no idea how that would be implemented. Does the "fifth" episode I just mentioned have one that's coded in already?

 

Maybe it could be a system where each lump has two numbers; the first number would be the episode, and the second would be the map the secret level exit returns to. M_EPI55 for example would mean that the secret exit is on E5M4, and beating E5M9 has the player return to E5M5. This could also work for episodes 1-4, for people who don't want to stick to where the secret maps are currently.

Edited April 1, 2017 by Death Egg

[Da Werecat]

On 25.03.2017 at 0:09 AM, kb1 said:

My point is that, being a superset of 256 colors, 32-bit color can do everything 8-bit can do, and much more. If 32-bit does not, at a bare minimum, look as good as 8-bit, something is simply being done wrong. (I don't know this to be true, nor do I believe that that is the case).

In theory maybe yes, but with this amount of colors some of the old solutions can become unwieldy. I'm talking about color tables, of course. As much of a burden 256 colors can be, they also make it manageable to tweak the way the colors fade and blend by manually adjusting the color-matching tables - in this case the COLORMAP lump.

 

I guess you can more or less compensate for it by making a complex enough color-fading algorithm, I just don't think it's gonna be easy if you want it to be universal.

 

On 25.03.2017 at 0:09 AM, kb1 said:

In other words, perhaps some special-case code could provide extra attention to, for example, the cyan and yellow transitions, to combat the effect you're describing. This could even be automated with code that tweaks colors, based on the results of a color-matching function that detects poor transitions.

The key is to not lose too much saturation when fading something bright. Bright colors can't be very saturated (the difference between R, G, and B is small), so when they're darkened they turn into grey crap very fast.

 

But preserving saturation is not a very natural way of darkening things. It requires good art assets with good color distribution. There's a palette/colormap mod for Doom (PALPLUS, I think) that attempts to give the game nicer fading without ugly color mutations, and even though it dulls the palette as a whole, it still results in cases of "burning colors" - like yellow pixels on CEMENT textures (normally blending well with their surroundings) lighting up from remaining too saturated.

 

Maybe Heretic, Hexen, and Strife should use an elaborate fading algorithm, while Doom would be better off with a straightforward one.

 

[BigDickBzzrak]

SEND HELP I've somehow made all levels flipped, how the hell did I do that, I didn't use any parameter or anything, Crispy 3.5

Using -fliplevels makes everything normal.

 

About E5: vanilla can access E5Mx levels if you have the WILVs, but completing the level takes you back to that level. @Death Egg's suggestion sounds awesome. Though, I think that might break savegames, correct me if I'm wrong?

[Gez]

37 minutes ago, bzzrak said:

SEND HELP I've somehow made all levels flipped, how the hell did I do that, I didn't use any parameter or anything, Crispy 3.5

Using -fliplevels makes everything normal.

I'm sure things will get back to normal tomorrow.

[VGA]

Hahaahah, nice!

[BigDickBzzrak]

OH MY GOD, Crispy Doom is officially my favourite port now. Great!

[fabian]

On ‎01‎.‎04‎.‎2017 at 7:30 AM, Death Egg said:

This might be getting a bit close to MAPINFO so hopefully that doesn't deter people from the idea. Especially since MAPINFO seems too advanced for a port like this.

Sorry, this somehow got lost...

 

As much as I like your approach in general, I think it would be running too far behind an actual clean implementation like MAPINFO which is currently out of scope for this port. Your proposed solution would be so special and so much tailored to Crispy's needs that I doubt any other port would jump suit and follow its implementation - especially since most ports that go as far as allowing to add another episode to Doom already have achieved this by means of supporting MAPINFO.

[Death Egg]

I put this request in a different topic but since that topic was closed before it was discussed, I figured I'd bring up the idea:

 

 

And please nobody use this as an excuse to revive those arguments.

[fabian]

4 hours ago, Death Egg said:

Maybe both sides could be made happy by making it an optional holiday mode, set off by default? Perhaps other holidays could have special things...

Na, please grant me my unprofessionalism once a year (this is like 1 GAMETIC in 10 seconds!).

[Arctangent]

I still think it'd be a good idea to save the flipped level property to the save file, and only set it for new games.

[fabian]

This souldn't be necessary anymore. I have fixed restoring savegames, so cou can save a game with flipped levels and restore it with regular ones and vice versa. And if you still insist on playing the maps in their original orientation, you may want to use the '-fliplevels' parameter to toggle between both, even on April 1st. ;)

[NecrumWarrior]

On 3/8/2017 at 2:37 AM, fabian said:

And once it has, I will switch away from palette-based rendering to true-color rendering. Sorry, but at least then the 'H' binaries will *really* require a lot of work to get back on track...

I'm not sure if this is your way of saying H Binaries won't be worth it for sure after that, or confirmation that you do plan to eventually update them, but if you do ever update them it would be cool if the mouse could actually perform vertical looking. It seems so weird to me that Chocolate Heretic and the old Crispy Heretic don't support this since it's a much better way to use vertical look for mouse players.

[Danfun64]

Already mentioned that for Chocolate here.

[fabian]

On 17.4.2017 at 8:48 PM, NecrumWarrior said:

I'm not sure if this is your way of saying H Binaries won't be worth it for sure after that, or confirmation that you do plan to eventually update them,

What this means it that as it is now, you may build Crispy Heretic/Hexen/Strife by simply uncommenting them in the build scripts and they will work out of the box (but they won't have any of the advancements added to the Doom code base within the previous three years). However, when rendering has been changed to true-color this won't be the case anymore without substantial adjustments to these three games. And as long as nobody steps up as a volunteer maintainer, this won't happen, because I have neither the time nor the incentive to maintain these additional three myself.

[Death Egg]

Will truecolor mode be toggleable or the only option?

[fabian]

The palette mode will still be there, but the palette colors will be "emulated" with RGBA colors... It will look the same. [*]

 

[*] Except for the pain, radiation suite and item pickup palette changes. These will get emulated by adding translucent colored textures over the rendered scene. But the results will look great, trust me. ;)

[Grain of Salt]

What about custom PLAYPALs that use different effects for the pickup/pain/radsuit tints?

[fabian]

8 minutes ago, Grain of Salt said:

What about custom PLAYPALs that use different effects for the pickup/pain/radsuit tints?

Yep, that will be a problem... :/

 

Not sure, maybe I will have to estimate an "average color change" from the base palette at init, but that won't be in the first truecolor release.

 

Does anybody know how other truecolor- or OpenGL-rendering ports handle this?

[Jon]

13 minutes ago, fabian said:

Yep, that will be a problem... :/

 

Not sure, maybe I will have to estimate an "average color change" from the base palette at init, but that won't be in the first truecolor release.

 

Does anybody know how other truecolor- or OpenGL-rendering ports handle this?

 

I don't ; but I do know last I checked GZDoom did do some kind of emulation/interpretation of COLORMAP (boom 242 applied COLORMAP effect worked) and QZDoom didn't.

 

On the one hand, writing a heuristic to figure out a fade from a custom COLORMAP or similar sounds like a fun piece of work.

On the other, and not relevant to crispy particularly but for boom or boom+ ports, we really need a declarative way of managing colours (afaik zdoom has it)

[fabian]

An alternative approach would be to generate an array of COLORMAPs, one for each palette, and then switch and redraw everything on the fly. But this might be a real performance killer (not to speak of the additional memory wastage) and somehow plays against the advantages of true-color rendering as a whole. :/

[BigDickBzzrak]

Hi, I've noticed that the -mergedump parameter won't work if you use the NWT sprite merging parameters (-af, -as, -aa). It will just make a copy of the IWAD, it seems. Should it be like that?

 

edit: no it's just me being silly

Edited May 12, 2017 by bzzrak

[fabian]

According to Choco's w_merge.c this is what W_NWTAddLumps() does:

    // Go through the IWAD list given, replacing lumps with lumps of
    // the same name from the PWAD

This means, the number of lumps in the dumped WAD is expected to be identical to the IWAD and the file size might be about the same. But the actual lumps in the S_START/S_END range should be different. Could you pelase check that?

[BigDickBzzrak]

Ah damn, sorry! I've specified the wrong file path, so it didn't work. Silly me. :/

Yeah, it works, the new sprites and flats show up in the merged WAD when loaded properly. Sorry, false alarm.

[Woolie Wool]

How good is Crispy Doom's Boom support? I know it implements at least some features of Boom, and I could make map01 and map30 of Sunlust load (didn't try actually playing either of them) but it wouldn't play any Sunlust demos (complaining that they're v2.02 rather than v1.9, being Boom demos and all).

 

Confirmed: none of the Boom specials work in boomedit.wad. Oh well.

 

EDIT: The "angle" crosshair (really a chevron) has its offsets set incorrectly. With a chevron the point of impact should be at the apex of the chevron, so the graphic should be just below the center of the screen so the very top is dead center. The way it is set up now would induce a player using it to aim too low. Also Doom smallfont characters are too fat and eye-catching for this task, the crosshairs would be better off having their own, simpler sprites.

 

Other than that, it works very well as a nice, no frills "vanilla Doom with mouselook" sort of port. I really don't like the sound of the truecolor renderer, though, I implore you to keep the original renderer intact, with the original palette blending behavior.

Edited May 13, 2017 by Woolie Wool