ZDoom

Notice: The survey is currently CLOSED. GZDoom 4.11.1 contains no survey code. This version will not prompt you to submit your hardware info.

Please do not post bugs or issues in release threads! Click here

Download (OpenGLES 2.0 and higher)

• Windows 64-bit
• Linux 64-bit Intel
• Linux 64-bit ARM
• Linux (Portable) 64-bit
• Linux (AppImage) 64-bit
• macOS 64-bit Intel/ARM
• Source

Highlights:

• Fixes from 4.11.0, ties up loose ends, to have a solid release overall before the transition to the next major release

Bugfixes:

• fixed actor class creation for DSDHacked
• fix DSDHacked state creation.
• fixed DumpCPUInfo() definition for non-x64 platforms
• update soundfont for all platforms
• removed several bad casts to 'long'.
• Fix inheritance for bNoSaveGame
• fixed another bad string validation check involving GetChars
• use copystring instead of strdup when reading environments.

Details

• set default backend to Vulkan, if Vulkan fails use GLES instead of OpenGL
• disable survey code again.
• make zs Actor.GetReplacement and Actor.GetReplacee clearscope

Oops, I published debug symbols in the Linux portable build. I went ahead and stripped them out and named the new build 4.11.1a (for those who prefer smaller downloads), but the old build is still on the Github release just named as -debug instead.

From seeing this changelog, and other things posted in the past (especially by Graf), it seems the goal is to ultimately get rid of OpenGL entirely. I understand the rationale, and personally I use Vulkan and even on my almost decade old hardware it runs so much better. However I wanted to warn you that some wads require OpenGL to run. I played Umbra of Fate not long ago (on GZDoom 4.10) and it crashes almost immediately after loading the map in Vulkan, I assume because of some of its custom shaders. I don't know how feasible it is to have an auto-translator for shader commands, or if it's worth it. For what it's worth, that initial crash didn't happen in ES, but I don't know if there are other problems later, and what the plans are for keeping/removing ES.

As always thank you for the new version and for the bugfixes.

I intend to keep OpenGL around as an option, one way or another, in an unofficial fork if necessary. But it won't get any new features when the decision is made to move forward with Vulkan.

Nevertheless, you should try those wads with VkDoom and see if they run any better.

Previously, when I used vulkan, it had artifacts or crashes gzdoom when video memory is full - this is the reason I'm using opengl for now. This is fixed? This is a known issue so I never reported it, but if reports are required, I can report it

Please report it.

Make sure to include your hardware info and what mods/maps you are using.

I never said I'd discontinue OpenGL right now. What I said is that we have to split this into two separate builds because OpenGL's mere presence stands in the way of refactoring the Vulkan backend.

brick wrote: ↑Sat Oct 14, 2023 8:37 am I played Umbra of Fate not long ago (on GZDoom 4.10) and it crashes almost immediately after loading the map in Vulkan, I assume because of some of its custom shaders. I don't know how feasible it is to have an auto-translator for shader commands, or if it's worth it. For what it's worth, that initial crash didn't happen in ES, but I don't know if there are other problems later, and what the plans are for keeping/removing ES.

I didn't think GLES supported custom shaders?

brick wrote: ↑Sat Oct 14, 2023 8:37 amI don't know how feasible it is to have an auto-translator for shader commands, or if it's worth it.

There already is one. If it's because of a shader, GZDoom will tell you what the error in the shader was, and if it didn't do that, chances are it wasn't the shader.
If something's broken in Vulkan but not OpenGL, and it isn't caused by bad user shaders, you should report it.

FYI, the only reason a shader might work on OpenGL but not on Vulkan is if the shader is relying on GPU vendor quirks.
One of those is that some vendors (*cough*AMD and Nvidia*cough*) love to implement non-extension-gated features over the base shader language spec, and shaders that use those then fail to compile in Vulkan. (they also usually fail on Intel!)
The other big quirk a lot of user shaders accidentally rely on is uninitialized variables. Intel, Nvidia and AMD all initialize those to 0, but the specs specify using uninitialized variables is undefined behaviour. The Vulkan shader compiler GZDoom uses instead leaves those variables uninitialized (which the specs allow), so you end with random, flickering patterns of garbage all over where the shader is being used.

The shader in Umbra of Fate is known to be bugged:

viewtopic.php?t=75731

Rachael wrote: ↑Sat Oct 14, 2023 9:21 am Please report it.

Make sure to include your hardware info and what mods/maps you are using.

done, please check when have time: viewtopic.php?t=78344

Thank you.