GZDoom 4.1.2 Released

[Graf Zahl]

Notice: There is currently no Vintage version planned for this release.

Please note that the survey is currently closed. GZDoom 4.1.2 does not include the survey code that 3.5.0 did.

Download (Modern, OpenGL 3.3 and higher)

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

• Source

Highlights

• bug fixes and vulkan improvements

Details

• always apply vid_maxfps even when vid_vsync is on. Some users may override the application in their driver control panel and this helps stabilize their fps if they did it this way
• SIMPLE is never ever defined for main.fp
• fix stencil test not being active when applying SSAO to portals
• fix some vulkan warnings
• removed useless assertions
• do not show par time when it's zero
• fix validation error for shader input not declared by main.vp
• fix model chasecam crash
• Fixes for Door_AnimatedClose (#838)
• fixed: The software renderer was accessing the global viewpoint in several places. Aside from using incorrect values this could crash the renderer if used in the very first rendering frame because the software renderer always operates on a copy.
• fixed crash when VM exception is raised during entering a level
• added missing newline to scriptstat CCMD output
• fix wrong screenshot gamma
• made DUMB library always static DUMB uses dumb_decode_vorbis() function from the main executable, so it failed to link as a dynamic library
• made setting actor TID more explicit
• Intel on Linux used the footnote in the standard saying a descriptor pool can become fragmented (thanks guys!)
• fix command buffer invalidation bug when DynamicSet is updated
• add fragment shader texture reading as an additional subpass external dependency
• add vk_debug_callstack for getting the location where a vulkan warning or error happens
• fix burn crash on vulkan
• only write the warning if r_multithreaded has its default value
• Write out a warning if std::thread::hardware_concurrency returns zero.
• If the number of cores cannot be determined, turn of multithreading in the software renderer as it is most likely a low end system
• added handling of GLSL noise() functions to Vulkan backend
• removed obsolete snd_flipstereo CVAR
• added missing compat flag CVAR for Strife railing
• Greek Sigma character fallback The lowercase Sigma letter in Greek has two different forms (σ and ς), which changes depending on its placement in a word, but in uppercase and smallcaps contexts, it only has one look regardless of word positioning. If the character ς is missing, it should fall back to σ.
• Accented Greek characters for Doom
• fixed output of software renderers with Vulkan backend
• moved greek characters to proper location
• OpenBSD build fix. As FreeBSD, does not have malloc.h aligned_alloc stricly available since C++17/C11, using the local impl.
• Fixed letter Ξ
• Greek characters for Doom
• fix mirror effect shader
• fix wrong fog color used for ssao when using multisampling
• move camtex depthstencil to VkHardwareTexture
• Fix build on FreeBSD (#829) On FreeBSD malloc.h is deprecated. <cwctype> is needed for iswalpha.
• rendering to texture requires a separate depth/stencil image as the image used by the main view may be using multisampling

[Caligari87]

oops, patched the wrong file

Oops left a stray commit message in the changelog?

[Rachael]

Oops indeed - Thank you. Removed it.

[Rachael]

Did 2 hotfixes (the hotfixed packages are labeled "4-1-2b") for the language update that I forgot, and screwed up the first time. (Nothing is ever "quick" is it?)

[Darkcrafter]

You guys are working very hard on that. Many thanks!

[Turret49]

"made setting actor TID more explicit" - What does this mean?

[Rachael]

"made setting actor TID more explicit" - What does this mean?

Now it's no longer possible to manipulate TID hash from arbitrary location
For example, this prevents linking of destroyed object into the hash
TID member is still public but writing to it is limited to a few very specific cases like serialization and player traveling between levels

(he referenced this thread in the commit message)

[Rachael]

Mac and Linux builds now available.

[Esrael]

Thanks for the hard work, people! This is my favourite Doom port and being able to participate in it by translating the game is a great honour!

I read a bit on the 320x200 debate on the 4.0.0 release thread, and how the problem could possibly be solved by separating the menu 2D scaling from the game's 3D scaling, and I'd just like to let you know, that it is my humblest wish for this to come to fruition at some point. Allow me to tell a story, if I may.

<story>Back when 3.5.0 was the latest version, I finally picked up Final Doom and started playing it for the first time. I made the decision to play the episodes in a way resembling how people played them back in the day as faithfully as possible. So, I turned on the Doom SW renderer, scaled the resolution to 320x200, turned off mouse look, turned on the strictest Doom compatibility settings and even turned off rendering interpolation to make things as authentic as possible. And with version 3.5.0 I was able to achieve this goal of retro authenticity.

(Granted, it feels almost too authentic: Sticking to no rendering interpolation has proven to be pretty hard. Whenever I turn rendering interpolation back on in my 165 Hz monitor, the game feels just SOOO much better! But I keep telling myself, that "hey, once you beat Final Doom the authentic way, you can replay it with rendering interpolation on as a reward!" so with that in mind, I've been able to resist the temptation and turned rendering interpolation off again.) xD </story>

Okay, story time's over. Anyway, since the latest versions no longer support 320x200, I've been forced to stick to version 3.5.0 while still on my first playthrough of Final Doom. (Yeah, I still haven't finished the episodes! What can I say, I've got work and family and other things competing for my time!) xD So, I wholeheartedly and sincerely wish that 320x200 scaling will make a comeback one way or another in the hopefully not too distant future. So, just know there are retroists out there like me, who actually play with these chunky settings for more than just a few minutes at a time. And as you move forward with the port, I just hope we won't be forgotten along the way.

I wish you all the best and humbly thank you for your hard work!

[fr1dd]

I just noticed that the openal32.dll is older in this version than v.4.0.0/4.1.0. Any particular reason for this?
Just curious.

Great work as always otherwise .

[Rachael]

Ooops, I thought my own package building ones were up to date.

[Mini--Joe]

Anyone else unable to play multiplayer with this? I keep trying with one other person and we both immediately get the out of Sync message, even though we clearly are in sync. The game freezes for seconds at a time, and sometimes just locks up our computers completely.

[XxMiltenXx]

@Mini--Joe: Please report such problems in the "Technical Issues" or "Bugs" subforum, not here.

[Gez]

's over. Anyway, since the latest versions no longer support 320x200, I've been forced to stick to version 3.5.0 while still on my first playthrough of Final Doom. (Yeah, I still haven't finished the episodes! What can I say, I've got work and family and other things competing for my time!)

You've got another good reason to finish your playthrough with 3.5: the saves from 3.5 are not going to be loadable in 4+.

[siealex]

Ξ

What is this? A new demonic symbol?