LZDoom 3.88b 02/26 released

[TDRR]

Why sadly? Just download the new version.

Okay i think i didn't explain myself correctly, by regular old MinGW i meant just basic MinGW, i already updated it and the error still persists. Dunno if i'm the one misunderstanding but i downloaded the version the "compiling ZDoom" page leads me to and it's the same issue.

EDIT: Whoops, forgot to point Codeblocks to new MinGW-w64, apparently seems to work now. Will report back if i find some other issue on compiling but it seems it's working well now.

[TDRR]

Some time after i actually downloaded the correct version because the previous one only gave me an error mid compile (it was different from the XInput stuff MinGW32 gave me) but it still isn't fixed. I get the exact same error again. Something about the first class having an unknown DWORD, and there are more but they are very similar to this one.

[drfrag]

Last time i checked it compiled, will do again soon. But there's a Travis CI check for MinGW and it's passing.
Now i've got a limited internet access most likely until next week. You should have reported earlier, besides that's too vague (use copy-pasta). Most likely there's a problem with your configuration or you're using the wrong package, you need to use the exact package i posted (or the gcc 7 equivalent).

The release was delayed due to some pending issues. Now i've finally ported both dithering and HDR support to the vintage build and LZDoom, i can't test HDR tough. Those Git patches are really useful when inexact rename detection fails and it fails a lot, i guess that's why it's named inexact.

[TDRR]

Last time i checked it compiled, will do again soon. But there's a Travis CI check for MinGW and it's passing.
Now i've got a limited internet access most likely until next week. You should have reported earlier, besides that's too vague (use copy-pasta). Most likely there's a problem with your configuration or you're using the wrong package, you need to use the exact package i posted (or the gcc 7 equivalent).

The release was delayed due to some pending issues. Now i've finally ported both dithering and HDR support to the vintage build and LZDoom, i can't test HDR tough. Those Git patches are really useful when inexact rename detection fails and it fails a lot, i guess that's why it's named inexact.

Nevermind now, i'm moving onto Visual Studio because i'm sick of all this MinGW garb anyways. 5GB isn't that much if you think about it.

Does this compile with VS2015?

[drfrag]

MinGW is harder to setup. You don't need to download that much for VS that's huge. You'd better get VS 2017 and get the packages you really need. Besides 2015 is old and has pretty much the same requirements i think and it's unsupported for GZDoom.

[TDRR]

MinGW is harder to setup. You don't need to download that much for VS that's huge. You'd better get VS 2017 and get the packages you really need. Besides 2015 is old and has pretty much the same requirements i think and it's unsupported for GZDoom.

Alright, thanks for the help. I'm going to download VS 2017. I assume the minimal things needed are just the C related packages right?

[Graf Zahl]

Better get VS 2019. 2017 got no advantages over it.

[drfrag]

I thought he may want to target XP, besides 2019 is very recent (inmature?).
But 4 GB of ram will barely cut it (3 GB on a 32 bit system). I've got installed desktop development with C++.

Now i've ported "Add Doom 64-style additive lighting" to both the vintage build and LZDoom but i don't think it will work in LZDoom (legacy should but i haven't tested).
I don't think it will crash, most likely will work partially here. So if someone wants to have a look (Talon1024?)...
You know "a half-assed feature is better than no feature at all" (tm).

[drfrag]

I've just released another rogue devbuild here : https://devbuilds.drdteam.org/gzdoom-vintage/

Edit: as expected still compiles and runs with MinGW (from the command line).

[site]

if i try additive lighting, what should i look for to see if its working properly or not

also ty

[drfrag]

Apparently it works well in both branches which is a bit surprising . Unless Talon1024 says the opposite, he has send me a test wad i'll most likely post later in that thread.
I guess i was lucky again. But you know I.R. very smart.

[Talon1024]

I'm glad to hear it works in both branches, especially since I haven't been able to compile an LZDoom build myself, unfortunately.

Here is a video showing the technical details of how this feature is supposed to work. The "Difference" is what you should get when you put the "glow on" image above the "glow off" image in GIMP and set the blend mode to "Difference".

Here is the test WAD I sent drfrag. All ACS and ZScript code within is licensed under the MIT license.

[drfrag]

I don't know why, i'd like to know which compiler you're using and what errors you get. I think it works well, i uploaded a 64 bit devbuild to gzdoom-vintage for testing.
What i've done is comparing with GZDoom using that wad.

[Talon1024]

I am using gcc/g++ 7.4.0 as the compiler, and a custom build script that serves as a frontend to CMake, Ninja (like Make but much faster and without unnecessary "features"), and automatically adding the builds to qZDL. After watching the script run, I discovered that I failed to account for the executable being named lzdoom rather than gzdoom.

[drfrag]

Good to know it compiles now, Travis checks were passing.

Edit: for those testing the devbuild i forgot to mention LZDoom only supports ZScript 3.8 so to run recent mods you need to try with the '-zsvoverride' switch.