Changelog updates

[mikeday0]

Crispy friends: here's my humble attempt to catalog all the changes over the last year. You folks have been busy! Please review for wording and correctness. Thanks!

@JNechaevsky @rfomin @ceski-1 @SoDOOManiac @tomas7770 @SilverMiner @kitchen-ace

[kitchen-ace]

Nice work, bookkeeping is never anyone's favourite job.

Can't speak to everything but anything with my name on it looks good, and I didn't spot any errors elsewhere at a glance.

I'll see if I can fix this today -- IMO no need to note it in a changelog since it's just a fix for a previous feature. edit: Done!

[JNechaevsky]

Composing changelog is always most unexciting thing to do, thank you very much @mikeday0! I made few tiny corrections to make things a little bit fair. 🙂

One thing that disturbs be: I have Program:Win32/Wacapew.C!ml false alarm about compiled crispy-doom.exe in Microsoft Defender check on VirusTotal. It's slightly different from Woof, but have same roots of the problem. But! If crispy-doom.exe is processed via strip, then no false alarm is happening. Maybe this will helps somehow?

[rfomin]

If crispy-doom.exe is processed via strip, then no false alarm is happening. Maybe this will helps somehow?

We should run strip during packaging: https://github.com/fabiangreffrath/crispy-doom/blob/d80f4a110b01c502276a3db0e1dac47af692b32c/pkg/win32/GNUmakefile#L53

[JNechaevsky]

Do we have an established release date yet? I have a small set of improvements for Hexen, collected while working on Inter, and definitely would like to contribute them to Crispy. Nothing too big, but I would like to ask for one or two extra evenings to don't do anything in rush.

[fabiangreffrath]

No, not in a rush at all. I'd like to get the Choco release through the door first, so we'd have a new clean base to biuld upon.

[mikeday0]

Shall I leave this open for additional items then?

[JNechaevsky]

From my side - nothing critical, just a small improvements, even not worth mentioning:

• Raven: do not reset cursor position after deleting save game.
• Hexen: smooth sky scrolling (finally I was able to make simple and better implementation).
• Hexen: better line drawing in overlay mode.

[fabiangreffrath]

Now that Chocolate Doom 3.1.0 has been released (🥳) I'd kindly like to ask all Crispy contributors to get their changelogs updated, so we don't have to wait too long to follow suit.

[SoDOOManiac]

@fabiangreffrath, I have just a tiny pull request: https://github.com/fabiangreffrath/crispy-doom/pull/1189

[SoDOOManiac]

And yeah, another one, tiny as well https://github.com/fabiangreffrath/crispy-doom/pull/1202

[JNechaevsky]

Wrote changes from my side. Not all of them, just important, I have dropped some technical ones to keep things clean. But please, feel free to correct me if needed, I was bad at composing changelogs 7 years ago at starting my "source port cariere", and bad with it even now. 🙃

Probably worth to make a note about TrueColor support for all games in the first lines of release post, but I'd like to leave this honor to @fabiangreffrath.

P.S. Barely I can find a words to describe amount of TrueColor abilites. It's not just a 16,777,216 colors mode. It's a Godsend.

[JNechaevsky]

Uh-oh. Woke up with a though that Hexen needs small update of drawing translucent functions as well, just like it was done for Heretic. PSP translucency is not an often guest there, but it's used for Cleric's invulnerability effect (missing one pixel line at the bottom):


There are two drawing functions, normal and alt., I'll take care about them shortly.

[fabiangreffrath]

All done here? Then I'd like to merge this tomorrow and kick off another release based on the brand new Chocolate Doom 3.1.0!

[mikeday0]

All done here? Then I'd like to merge this tomorrow and kick off another release based on the brand new Chocolate Doom 3.1.0!

Nothing more from me!

[fabiangreffrath]

Alright, I expect to kick it off on Friday.

[JNechaevsky]

One more thing, please. @kitchen-ace suggested to have a sound fix for huge levels, and probably it will be good addition for crispy_soundfix. Easily to implement, but first approval of @fabiangreffrath is needed. Suggested aproach is something like this:

```diff +++ D:/JN/GitHub/crispy-doom/src/doom/p_setup.c Wed Nov 8 10:21:22 2023 @@ -887,17 +887,8 @@ } // set the degenmobj_t to the middle of the bounding box + if (!crispy->soundfix) + { sector->soundorg.x = (bbox[BOXRIGHT]+bbox[BOXLEFT])/2; sector->soundorg.y = (bbox[BOXTOP]+bbox[BOXBOTTOM])/2; + } + else + { + // [crispy] Andrey Budko: fix sound origin for large levels + sector->soundorg.x = bbox[BOXRIGHT]/2+bbox[BOXLEFT]/2; + sector->soundorg.y = bbox[BOXTOP]/2+bbox[BOXBOTTOM]/2; + } // adjust bounding box to map blocks block = (bbox[BOXTOP]-bmaporgy+MAXRADIUS)>>MAPBLOCKSHIFT; ```

Also, I think there is a way to support custom palette tinting effects in TrueColor. In theory, they shouldn't be color_panes, but colormap arrays, same to colormaps[]. This should do the trick, but:

• a) This may will lead to possibly way too big diff comparing to current implementation and more ifndef's.
• b) For god's sake, not now, no need to delay release because small abstract thought.

EDIT:

a) This may will lead to possibly way too big diff comparing to current implementation and more ifndef's.

Wait, what if I_SetPalette will set/swap pointers between different colormaps[] arrays?... 🤔

[fabiangreffrath]

Suggested aproach is something like this:

Yes, please. This will fit the current release quite well.

Also, I think there is a way to support custom palette tinting effects in TrueColor.

Maybe, but later. We have really reached the point for a new release.

[fabiangreffrath]

Wait, what if I_SetPalette will set/swap pointers between different colormaps[] arrays?.

You'd still have to redraw everything that's already on screen, i.e. status bar, bezel, crosshair, ...

[JNechaevsky]

Ah, yes, that's a pal_color[] array implemented for a good reason. And even if it will be precalculated/tablified as well, probably a full screen refresh will still be needed, as some parts of screen are using "buffered" drawing, like screen bezel and wide screen status bar sides.

If done carefully, having an extra 13 arrays for colormaps[] + 13 arrays for pal_color[] (but, ahem, it's +27/+27 in Hexen palettes!) will probably help to get few extra fps on palette changing and provide some extra compatibility, but... SDL color operations for color panes is not that expensive, and the idea itself doesn't sounds too reasonable. Maybe one day later, if it will not require too much code changes and/or destruction, perhaps it will deserve a chance to suggest and live. But as decided, not now of course.

My another idea was to use malloc/free for wiping effects, since (d)/pixel_t is consuming more memory in TrueColor, and such memory becomes a hostage in purgeable zone memory, while it can be freed immediately after wipe effect. But that's it, enough for now. 🤐