[UPDATED] ZDoom32 2.8.6a (ZDoom is undead)

[drfrag]

I've added the mmx hqnx modes to LE, i thought the google version was removed but it wasn't so i've renamed hqnx to hqnx google, that's a poorer quality version and not the original hqnx (the mmx version is the original and not just an optimized version). Since the code didn't compile with gcc 4.6.1 i've switched to 4.9.2 for LE. But then the gcc crash on exit in the FMaterial destructor has appeared so i've applied my hack for the old renderer (a simple and elegant solution ).

I've investigated the issue with generalized boom crushers for hours, the bug in 2.2 was reported at doomworld but got no reply. Normal crushers work but these won't damage monsters nor the player. I think this was never fixed and may be it works now due to some compiler dependant undefined behavior. It's not a git problem, i've checked all changes between the two QZDoom q0.0 alpha and q0.1 beta tags with diffmerge (brute force approach) and i couldn't find any relevant changes there. Also i compared 0.1 beta to my later version (ZDoom32) and there's nothing missing.
@Graf Zahl: could you please tell me where to look at? I've checked a lot of code and i suspect the problem is that the damage somehow ends being zero somewhere (depending on crusher speed?).

Also i've added the ACS stack checking stuff to LE. And i've ported the unsafe context for console commands as well (inspired by Rachael commit to Zandronum), it this really that much of a thing?
I ported "Improved compatibility of blocking lines handling" too since i had applied the previous patch (normally i wouldn't do this kind of thing). BTW the maintenance to the old 2.8 codebase has gone way too far beyond reasonable.
@_mental_: when cherry_picking this last commit the conflict was so severe that i could not resolve directly with tortoisegitmerge (i resolved partially and then compared differences in your commit vs those in the working tree). I think it's okay (i've tested both wads) but could you have a quick look at it?
https://github.com/drfrag666/gzdoom/com ... ef08147419
https://github.com/drfrag666/gzdoom/commits/gzdoomle

@_mental_:On the unsafe context thing how could i test this? (running unsafe commands from menus). I've run BD v20c and an older SmoothDoom and they still work.
I get the warning "warning: override controls (override/final) only available with -std=c++11 or -std=gnu++11" but i guess it should work (functions are still overriden if i'm not wrong). I'm using gcc 4.9.2.
Also about the safe frame for the automap i don't know how to do it since the old version (LE) uses integers instead of doubles.

Thanks guys, please reply when you have time i know you're busy right now.

[_mental_]

The blocking lines merge seems fine.

Use the following KEYCONF lump and press K after entering the game

Code: Select all

addkeysection "My Keysection" MyKeysection
addmenukey "My Key Bind" my_newbind
defaultbind k my_newbind
alias my_newbind "echo hi!; wait; logfile 123; test 1 \"wait; save 123\""

You should get something like this

Code: Select all

hi!
Cannot execute unsafe command logfile
Cannot execute unsafe command save

Usage of any unsafe commands from mod's key bindings or menu should end with the same error message.

GCC 4.9 supports all C++ features needed for GZDoom. I could be something with compiler configuration in CMake if -std=c++11 isn't added by default.
Actually it should be C++14 because at least generic lambdas require it (honestly I don't remember are they still around somewhere or not).

[drfrag]

Thanks very much.
Blocking of unsafe commands runs fine, as expected the functions are overloaded without the override anyway so i just removed it to keep compatibility with gcc 4.6.1 (required for the old win95 version). It's the only place in the code where override is used and c++11 support wasn't in CMakelists.txt yet.
I assume about generalized crushers you don't know where the problem could be.

[_mental_]

I assume about generalized crushers you don't know where the problem could be.

What's the simplest way to reproduce this issue?

[drfrag]

Doom II Dark World (d2dw-v1.wad) activating the crushers on MAP06. Happens with ZDoom32 and GZDoom 2.2 (works fine with QZDoom 0.1 but ZDoom32 is a later version).

[_mental_]

If you know two versions, one with this bug and one without it, then use git bisect to find out in which commit the behavior changed.

[drfrag]

That's just a blind binary search (could be useful as a last resort), first i'd need to compile ZDoom32 with Visual Studio and i wouldn't be surprised if this is compiler related. I've checked all commits in that range and all changes manually with DiffMerge, i suspect this thing could still be alive so it might be worth checking.
Thanks for looking into it anyway. I've found that arg4 is zero in:

Code: Select all

FUNC(LS_Generic_Crusher)
// Generic_Crusher (tag, dnspeed, upspeed, silent, damage)
{
	return EV_DoCeiling (DCeiling::ceilCrushAndRaise, ln, arg0, SPEED(arg1),
						 SPEED(arg2), 0, arg4, arg3 ? 2 : 0, 0, (arg1 <= 24 && arg2 <= 24)? DCeiling::ECrushMode::crushSlowdown : DCeiling::ECrushMode::crushDoom);
}

But i don't know where this arg4 comes from, do you? I hope Graf Zahl could tell something one of these days.

[drfrag]

@_mental_: It's fixed and actually you commited the fix much later, the bug was present only in VS 64 bit builds and in MinGW, it was an unitialized variable in the XLAT parser.

viewtopic.php?t=57109

Now i'm preparing a new ZDoom LE release (following your steps fixing the security issues), also i'm reviewing some old stuff.

[drfrag]

Yesterday i released a new ZDoom32 version (2.8.4) with the security updates and a lot of bugfixes. I don't know what will happen from now on.

https://github.com/drfrag666/gzdoom/releases

[VGA]

The Zdoom LE fork is for running it on older OSes. What is ZDoom32's purpose?

[drfrag]

It's based on a more recent ZDoom version and has the old truecolor renderer which is faster on old machines. I created it when the GL renderer didn't work in LE.
I can't just port new modding features since the non ZScript version is based on a much older VM. The right thing to do would be to merge ZScript (conflicts) and then cherry-pick a lot of stuff. But for now i'm going to lose my internet connection becouse i'm a poor man (as many people here). These ports are developed with very few resources.

[drfrag]

I've reuploaded the release due to the severe performance regression in gcc 4.9.2, the game mostly ran fine but was very slow in extreme cases with a lot of actors. Now it's compiled with gcc 5.1 and still runs on win98. Thanks to Graf, _mental_ and Rachael for helping with this re-release.

[drfrag]

Well you won't believe this but it has happened again. I cherry-picked something that apparently was safe but it wasn't and broke some maps, there was some refactoring at certain point and somehow there was an infinite loop somewhere and game hung. So i've re-released the last version again and by the way i've added some more fixes such as the unmorphing bugfix. The unexplored secret color is in as well. To clarify things this has never happened with LE, that re-release was only due to a minor compiler problem and was still the same code.
I didn't catch this since i've been testing LE lately. But now it's fixed and apparently everything is fine this time for real. With the exception of course of a couple of 3d floor problems. Certainly i'd need help with that broken drawer, that code looks like chinese to me.

Edit: i've uploaded the version without the GL renderer again for purists.
P.S: My connection is still working but it's only a delay.

[drfrag]

First i released 2.8.4a on APR 08 to fix several bugs.
Then i've compiled the old dpJudas' truecolor branch with Visual Studio 2017 (this has been a pain but i'll explain that in a different thread) and i've found what broke the 3D floors (screenshots of the problem on page 4 of this thread).

It was not a broken drawer, it's this commit: 14 Aug 2016 Remove premultiplied alpha
https://github.com/coelckers/gzdoom/com ... 7c1cd25479

But according to Graf Zahl i cannot just revert it since "Any texture being put on a one-sided wall, on the upper or lower part of a two-sided wall or a non-3D-floor flat will always be drawn without alpha blending. Even fully transparent parts will be rendered black."
viewtopic.php?f=18&t=52270&start=60#p931114
I don't know where i can find any example of that problem.
@dpJudas @Rachael: Could you please give a hand? Of course when you have time and the 2D refactor is complete. Thanks very much in advance.

[dpJudas]

The alpha blending in alpha_blend is wrong. The parenthesis is not including the fg part before dividing by 256. It should be saying:

Code: Select all

FORCEINLINE static uint32_t alpha_blend(uint32_t fg, uint32_t bg)
	{
		uint32_t alpha = APART(fg) + (APART(fg) >> 7); // 255 -> 256
		uint32_t inv_alpha = 256 - alpha;
		uint32_t red = MIN<uint32_t>((RPART(fg) * alpha + RPART(bg) * inv_alpha) >> 8, 255);
		uint32_t green = MIN<uint32_t>((GPART(fg) * alpha + GPART(bg) * inv_alpha) >> 8, 255);
		uint32_t blue = MIN<uint32_t>((BPART(fg) * alpha + BPART(bg) * inv_alpha) >> 8, 255);
		return 0xff000000 | (red << 16) | (green << 8) | blue;
}