ZDoom

Notice: The survey is currently closed. GZDoom 4.2.4 does not include the survey code that 4.2.0 did.

Download (OpenGL 3.3 and higher)

• Windows 64-bit
• Windows 32-bit
• mac OS
• Linux 64-bit
• Linux 32-bit

• Source

Highlights

• This is a bugfix release without new features. The notable highlight is that this fixes translucent objects in the software renderer.

Details

• Fixed stretching for 256 and 240 pixels tall skies in software.
• fixed broken walkthrough of Restoring Deimos MAP07
• Fixed a bug in the flagdef processing code.
• adjusted collision detection for item pickups. Use vanilla condition for a thing with MF_SPECIAL flag to fix inability to grab it when item's top is at the same height as sector's floor from it can be picked up
• fixed localization support for intermission texts
• fixed radius attack that may inflict damage twice
• sort CVAR output in config alphabetically instead of randomly dumping them in their internal order.
• Fixed ZScript's Screen.DrawLine using the wrong color when drawing pure black.
• fixed missing frames for Hexen's fighter's axe attack without mana
• fixed usage of uninitialized object in BlockLinesIterator
• removed hardcoded width limit for screenshots
• Fixed dynamic arrays as function arguments.
• added Visual Studio debugger visualization for several types
• do not accept read-only variable as out argument
• fixed variable's stack offset for implicit dynarray clearing
• Fixed Vector2/3 out parameters in the ZScript compiler.
• added explicit clearing of global VM stack. When exceptions are thrown from JITed code, the VM stack isn't cleared during unwinding.
• fixed typo with D'Sparil's serpent attack in lights.pk3, creating an extremely large light.
• fixed bad application of translucency in the software renderer
• Scythe MAP22 Compatibility fix

I originally wanted to do this last week but had no spare time for it so it had to wait a little longer.

4.2.4 is currently being pushed to Flathub:
https://flathub.org/apps/details/org.zdoom.GZDoom

As for the release numbers, we've had 512 downloads in last year, of which 416 in the last month. Not bad if you ask me. It's also doing better then Duke Nukem

With Duke Nukem, do you mean EDuke32? If so, how much better?

I was indeed referring to EDuke32, which is now also on flathub:
https://flathub.org/apps/details/com.eduke32.EDuke32

I get my usage stats from Paul Carroty, who runs an overnight script to consolidate all numbers:
https://github.com/paulcarroty/flathub- ... s/releases

Based on the monthly figures, GZDoom has 416 downloads and EDuke32 has 116. It's not a truly fair comparison though: GZDoom has had a few more releases, so that keeps it on the 'recently updated' page. By doing regular updates, you can increase your visibility a lot. I noticed this with my own app as well.

Still to slow on OpenGl and instable with xBRZ 4x (crashes often) on Vulkan API on Windows 10 with gtx1070 (8gb Vram) on Ryzen 2700x with 16gb Ram. I can´t recommend this build.

Try without the xBRZ filter. That's not trivial to run.

Tkfreak77 wrote:Still to slow on OpenGl and instable with xBRZ 4x (crashes often) on Vulkan API on Windows 10 with gtx1070 (8gb Vram) on Ryzen 2700x with 16gb Ram. I can´t recommend this build.

You are aware that xBRZ x4 is not only a first grade performance killer but also eats lots of video RAM? The menu already warns you that it requires 16x as much as unscaled textures. Even with an 8GB graphics card you'll reach that faster than you might ever think, when you blow up a simple 128x128 texture to use 4MB of VRAM - 6 with mipmapping.

Tkfreak77 wrote:Still to slow on OpenGl and instable with xBRZ 4x (crashes often) on Vulkan API on Windows 10 with gtx1070 (8gb Vram) on Ryzen 2700x with 16gb Ram. I can´t recommend this build.

There is something very wrong with your setup if you're having issues running with this. It sounds like you're trying to run a mod that uses an insane amount of texture memory and you are somehow expecting this to "just work", especially with the resizer.

What is the difference between gzdoom-4-2-4-Windows-64bit.zip from zdoom.org and gzdoom-4-2-4a-Windows-64bit.zip from Github.com?

4.2.4a has been recompiled with Visual Studio 2017 due to visual corruption in the software renderer caused by a compiler bug. If you only use the hardware renderer they'll be the same.

I noticed the highlights from 4.2.3 still haven't been compiled.
You gonna put them here or in the next update?

Zenon: F3DFloors was exported, otherwise it mainly just a bunch of bug fixes.

Not sure if I should ask this around here, but anyway.

A long time ago, I noticed that they added the Doom-64-colors and said, well, this is great, but I realized that things are missing, such as actions that allow you to change the colors at the time you want and that you decide how you want that work and that that can also be used by ACS.

Now, I don't know if this is the job of the person in charge of supporting the editor GZDoom Builder-Bugfix or the GZDoom team (I don't want to sound like someone demanding, I just would like to know) but, will it be possible to do these things for him editor of GZDB in some future? Would that depend on GZDoom or GZDoom Builder?

TheMafla: You should post about that in the GZDoomBuilder-BugFix thread instead, that's where the editor devs would see such posts. posting.php?mode=reply&f=232&t=54957