Welcome to the ZDoom Forums!

Notice: The survey is currently CLOSED. GZDoom 4.14.2 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
• macOS 64-bit Intel/ARM
• Source

(note: Linux AppImage is not being published, for now, due to issues, same with Linux Portable)

Highlights:

• Ortho + OOB fixes and improvements
• Revert clipper to older code path when not in Ortho/OOB (speed improvement)
• Fix to some crashes and memory leaks
• Exposed DDoor to ZScript, Exposed DPlat to ZScript, Exposed more of the Ceiling thinker, Exposed more of the Floor thinker, Exposed DElevator to ZScript.
• Exported: • GetLumpContainer • GetContainerName • GetLumpFullPath for WADS struct, useful for debugging custom-made parsers and identifying where problems may arise.
• Added autoSwitch parameter to A_ReFire
• add a few commonly-used gzdoom-specific properties to the dehacked parser
• many more fixes and improvements

Details

Spoiler: This is long

---

• Better flat visibility checks for Ortho projection.
• 3D floor flats now respect r_dithertransparency flag
• Added visual rendering for LinePortals and SkyPortals for OoB viewpoints. SkyPortals will be stenciled, and will always use perspective projection. Disabled interpolation when portalgroup changes (portal transition occurs) if viewpoint is OoB (was necessary for fog of war when r_radarclipper is set to true). Tightened up radar clipper by making it more aggressive. Voided walls wont' get filled in by a floor or ceiling sky (because of the stencil). Ceiling sky will be half-infinitely tall upwards, and floor sky will be half-infinitely tall downwards. Use only floor skies and a good GLSKYBOX for top-down/isometric cameras. Level.ReplaceTextures("F_SKY1", "SKY1", TexMan.NOT_FLOOR); (zscript) is a nice trick for WorldLoaded().
• Making 3D-floors respond to r_dithertransparency properly.
• Reflective flats now work with OoB viewpoints, including ortho. Had to create a new type of portal stencil for the HWPlaneMirrorPortal. Stacked sector portals could be made to work the same way, but there are clipper issues, revealing out-of-view sections of the map on the other side. Hence sector portal rendering is still disabled in OoB viewpoints.
• Stacked sector portals now render for OoB viewpoints.
• Addressing some small regression by conditioning a few calculations on OoB viewpoints. Branching Frustum calculation to old method.
• rework how vector local type restrictions are managed
• add better descriptive name for vectors/quats
• don't allow backing types of string/array/map/etc to be referenced as actual types
• restrict internal structs to gzdoom.pk3
• Allow `>>` in parser for aggregate types
• rename vm internal structs to make room for compilation-unit-internal structs/classes
• fix crash if chat key is pressed during the loading screen
• stop game from getting stuck in chat mode if the main menu is open
• Revert using older stencil method for stacked sectors (and reflective flats) if viewpoint is not allowed OoB. There was some bug with nearby skyplanes otherwise.
• Forgot to account for when both floor and ceiling of a sector are portals.
• Handle sectors within sectors for stacked portals and plane mirrors (affects OoB only).
• Update hw_portal OoB height clip
• Remove bitwise opeartion on bool
• Exposed DDoor to ZScript, Exposed DPlat to ZScript, Exposed more of the Ceiling thinker, Exposed more of the Floor thinker, Exposed DElevator to ZScript.
• fix function-pointer cast parsing
• Interpolate turning 180 degrees
• Added particle rendering to VisualThinkers.
• remove K&R C function declaration bullshit from lemon.c
• Fix memory leak in mixins
• Properly assign tags to various Raven game items
• disable Build light mode due to being broken.
• Exported: • GetLumpContainer • GetContainerName • GetLumpFullPath for WADS struct, useful for debugging custom-made parsers and identifying where problems may arise.
• Added autoSwitch parameter to A_ReFire
• rewrote XY and XYZ accessors for vectors to be read-only and not use type punning.
• Haiku support patch, to allow compiling for the Haiku OS
• fix OptionMenuItemCommand::DoCommand for new 4.15 keyword
• Fixed player respawning
• Added missing return values in VM calls
• fix bug with direct cvar assignment being mistakenly allowed
• save togglehud to ini so that it can be properly restored on crash/exit
• Added OnLoad virtual
• Fixed pitch culling in reflective flats for OoB Viewpoints
• Boolean op instead of mod with 2
• Ensure boolean to suppress compiler warning
• SpawnBlood now returns an actor spawned by the function.
• Added am_showlevelname CVar
• fix dsdhacked actors not spawning when placed in a map
• add a few commonly-used gzdoom-specific properties to the dehacked parser
• limit light alpha mult to renderflag
• 4.14.2 model refactor cherry pick

Thank you kindly. As ever, the work of the devs is greatly appreciated.

Thanks for the super-quick release after the recent DEHACKED-related PRs (probably just good timing, but it's hella welcome for a couple of folks working on mods).

That said, I did notice an oopsie right off the bat: the gzdoom.pk3 in the release looks like it was built from an out-of-date wadsrc tree; e.g. I noticed the SelfObituary property (which was just added in February this year) is missing from zscript/actors/actor.zs, but it's definitely present in the latest commits on Git. Maybe the PK3 from an older release got pulled in?

I'm maybe running afoul of the "don't post bugs in the release thread" rule, but I dunno if this is a "bug" per se or just a distribution thing that needs a zip reupload. Lemme know if I should move this to the Bugs forum instead.


[EDIT] NVM, false alarm -- I didn't realize that the 4.14.2 branch was a stable release that was branched from master a while back, and the pk3 does match the branch (as expected). The DEHACKED commits got cherry-picked but SelfObituary didn't, but that's just a case of the feature itself not yet existing. All is well, carry on.

The main purpose of the release was to address some compile errors with the arm .deb package, but while we were at it we pulled in some cherry-picks and I also managed to fix the bug that was causing my Windows build environment to erroneously pull in a bz2.dll dependence that should not have been pulled in. So yeah, it's effectively 4.14.1 with a few changes.

Rachael wrote: ↑Sun May 04, 2025 7:41 am I also managed to fix the bug that was causing my Windows build environment to erroneously pull in a bz2.dll dependence that should not have been pulled in.

What was causing that?

Graf Zahl wrote: ↑Mon May 05, 2025 1:05 pm What was causing that?

Either CMake or Visual Studio were erroneously pulling from a very old copy of vcpkg that I had, I located it by looking up the strings in that extra .dll that it was pulling in. After I did I renamed it and then re-ran cmake and it stopped pulling it in.

Rip in textured automap displaying properly. Oh well, it'll be fixed in the next update.

Rachael wrote:
> (note: Linux AppImage is not being published, for now, due to issues, same with Linux
> Portable)

So what's the deal with this? I was able to just extract the .deb package on my Steam Deck and GZdoom 4.14.2 *seems* to run fine as is. Is this bug tracked somewhere? Is this the one? https://github.com/ZDoom/gzdoom/issues/2362

If you get that working, that's perfectly fine.

The deal is there's no reliable way to figure out exactly what libraries are required to make the executable completely portable. GZDoom has way too many dynamic object dependencies and the problem is made infinitely worse by distro maintainers insisting that GZDoom compile with more system libraries than we as hobby developers have time to hawk over to ensure there is no breakage.

If ever there was a way to pull GZDoom together as a completely self-contained binary we'd really rather go that route.

I stopped publishing .AppImage because the script broke, and regular Windows-style .tar.gz elf bundles because the script I use to gather the loose libraries doesn't work reliably, either, and I don't have the time to constantly keep that up to date.

So if you can extract the .deb and get it working - great. If that crashes though, I would recommend just using a Windows executable on the Steam Deck, everything actually works great out-of-the-box via Proton.

I would probably recommend changing that note to saying the AppImage has been dropped due to lack of a maintainer. Invites someone to pick it up if they're so inclined.

In regards to running the deb on other operating systems. I've long said that people can do this, but you are in charge of resolving the dependencies manually (automating this is the only feature of Apt I use in any of my packages). I'm actually personally fine fielding reports in that kind of setup on non-immutable distros as long as it's specified this has been done (i.e. so we don't assume you've self compiled and conversely aren't assuming you're running Debain/Ubuntu).

However I'm a bit surprised that it would work on SteamOS since as far as I know that's an immutable distro. So I can only imagine it worked by coincidence that Valve happens to install the dependencies we use (granted we don't require anything crazy)? We can't really support this and it's possible an OS update could break the setup on a whim to no one's fault. Although it hasn't been blessed as an official package, you're probably better off using the Flatpak. (Or as Rachael said, the Windows binary if you want to stick to first party builds.)