LZDoom 4.14.3 released

[drfrag]

Notice: This version won't run on Win XP.

Download

• Windows 64 bit
• Windows 32 bit
• Linux 64-bit
• Source code

Fixes/features since 4.11.4

• Based on GZDoom 4.14pre master from february 17 2025 with many patches on top.
• Includes patches from both GZDoom and UZDoom.
• Can load both GZDoom and UZDoom savegames.
• Line culling with multithreading enabled. (Dileep V. Reddy)
• Fix dangling pointer on Softpoly (issue #43). (Blzut3)
• Fix Softpoly crash with PsychoPhobia.
• Add option for testing old lightning modes to menu.
• Fixed death cam not working with A_SkullPop. (Boondorl)
• Fix VM Abort with Crusader A_CrusaderSweepLeft and Right pointers. (Enjay)
• Add i_searchdistributors to disable Steam iwads. (Sally Cochenour)
• Fixed +playerclass not being respected when new players join a save. (Boondorl)
• Fix SMF_PRECISE flag for seekers. (Boondorl)
• Fixed setinv cheat. (Boondorl)
• Made the BFG and EXPLOSIVE weapon flags usable. (inkoalawetrust)
• Made MTF_NOINFIGHTING work. (inkoalawetrust)
• Fix LookForEnemiesEx(). (inkoalawetrust)
• Fixed StaticEventHandlers double destroying. (Boondorl)
• Correctly mark currently-running ACS scripts for the GC. (Ricardo Luís Vaz Silva)
• Remove `delete` from GC, replace with destructor + free. (Ricardo Luís Vaz Silva)
• fix am_cheat 4-6 behavior for textured automap mode (intent is to show map as if the player has viewed every sector). (Xaser Acheron)
• Fix 32 bit compilation on other platforms.
• Make CMake find SDL2 on Haiku 32bit. (Peppersawce)
• fixed DECORATE code generation for direct functions. (Christoph Oelckers)
• fix bad game filter in Chex's 101 lock. (Christoph Oelckers)
• Added support for massacre special 515 used by Heretic+Hexen's UMAPINFO definitions. (Christoph Oelckers)
• use a submenu to select the MIDIO device. (Christoph Oelckers)
• Backport "Fixed net event data being dropped in packet-server mode" by Boondorl.
• Removed checks for corrupt config files.
• Full zscript 4.14.3 support.

Details

• See full changelog here: https://github.com/drfrag666/lzdoom/commits/l4.14dev

[drfrag]

Well. Seems i got Graffed xD. There was a bad commit by Graf about DECORATE ("fixed DECORATE code generation for direct functions") which broke it. I don't think it's intentional but it happened after the fork under a thing. I shouldn't have merged it for the release but looked like a minor optimization and i assumed he knew what he was doing, i tested a DECORATE mod and uploaded a devbuild some days ago to try it among other things. Besides there wasn't an issue about it on the GZDoom repo.
So sorry about that and better don't download the release until i upload 4.14.3a ASAP.

[drfrag]

I've updated the release to 4.14.3a.

[rayburn]

Hello.

I just tried LZDoom for the first time.

I did some tests in Ascension TC's City of Sorona on latest GZDoom vs. LZDoom. It's a location notorious for it's disgusting performance because of large city area + no vision blockers + tons of NPCs + 3D models, yada yada. Basically the entirety of the huge city is getting rendered all at once. For it to be clean as possible, I used the same .cfg file I used for GZDoom when I launched LZDoom. By default, I did not see any difference between engines both visually and it terms of performance, but that was just a quick test and I haven't really counted FPS, was just "gathering empirical data" haha.

But wall/sprite culling is another story entirely. Holy caco balls people, this is an absolute game changer. The performance went from absolute garbage to almost buttery smooth most of the time. It did cause quite a few visual artifacts like the rooftops of some buildings floating in the air, etc, but I guess it has to do with implementation.

The point is, in an engine that forces you to map with vision blockers in mind to avoid garbage performance, this feature is incredibly important and I do not understand why it is not in GZ/UZDoom at all.

I have a couple of questions, will you endulge me?
1) So what are the downsides of using this fork in terms of visual fidelity compared to the engine it is forked from? Since I saw none empirically, although I didn't test for very long.
2) And in terms of performance, is there a comprehensive document listing all of the features/feature removals improving it? A lot of changelog feels quite technical and doesn't convey level of impact those changes have really.
3) Are you going to continue to re-fork the engine from latest versions of UZDoom that would be released in the future? I believe the two main issues of the engine are multiplayer and performance, and I see that UZDoom team seems to be working on the former, while culling seems to largely solve the former up to an extent where every other problem could just be solved by careful profiling, I believe. In other words, when UZDoom team gets multiplayer right, should we expect it in LZDoom as well?
4) If the answer to the previous question is "NO", do I need to ask permission to patch that particular functionality into my own UZDoom fork for my own project, if it comes to that?
5) Is there any way to trigger culling contextually via ZScript or other means atm? And mark the exact parts of the map I want hidden or shown? If not, are you planning on adding that? I.e. what if instead of distance-based culling, I want to build triggers into my maps to hide/show specific other parts of map geometry? To maximize performance and avoid any weird artifacts by carefully managing what player can and can't see as they explore.

I'm lost for words guys, I'm not sure if this technology is "new" or "returning", but I am pretty sure ZDoom always needed it. Blew my mind. Well bloody done.

[drfrag]

Wenas (hi). Well, there are obvious differences such as the startup and the classic UI and a different scaling AFAIR supporting 320x200 all the time and the extra difficulty setting, something i should have made in a mod i know but now Heretic+Hexen also includes a mod xD. BTW changing the UI to modern to use asian languages requires a restart.
An enhanced render distance culling will be included in the next UZDoom version AFAIK and there's a PR for it by Dileep V. Reddy.
LZDoom wil remain as a GZDoom fork i think but i will merge code from both, there are already fixes from UZDoom in the last release. LZDoom 4 was forked from GZDoom master around 4.5 but for this 4.14 release i created a different branch to cherry-pick fixes.
I plan to release 4.14.3b with more UZ fixes very soon but the next major release will come out several months after UZDoom 5.0 becouse LZ usually is behind the main port. You can see LZ as a LTS version of GZ/UZ. I'll try again to fix GLES 2 for ancient intel cards but i dunno if @emileb could help.
Now i'm trying to add MBF21 support to ZZDoom and it's a lot of work with the old VM but i must be an absolute ZDoom freak xD.

[rayburn]

Thank you for the reply, that's great news! FYI I was looking into it a bit further, and concluded the "visual artifacts" I previously mentioned with culling is a problem with how the culling interacts with portals. Since portalled geometry is not "factually" where it seems to be, the distance-based approach doesn't render it as long as it is "too far away", although for the player, it is "visually" close. Here's an example with 4 cases with different cull distance set, hiding more and more stuff on the second story of the "Mansion" map in Hedon episode 2 (just a good example, I am not actually working on it), that is not a 3D floor and is overlaid on top of the first floor via a portal: https://imgur.com/a/fG2fUfa . What would be the best way to report it, or is it actually expected behavior? I don't see an option to create a thread in the Bugs (LZDoom) forum section, I guess I'll have to report it when it's in UZDoom. I can think of a workaround with authors adjusting the r_line_distance_cull cvar on the fly as the players explores the specific parts of their maps, but it's hacky as hell. And I guess fixing the whole feature interaction with portals may be quite challenging. This honestly gets me back to my earlier wish for contextual culling. If such a thing could ever exist instead of the feature being strictly about "distance", that would allow to manually fix all the problems in any new maps, just maybe not the old ones.

In any case, I like that ZDoom makes me excited lately. All the best, cheers!

[drfrag]

If you can't create a thread in that forum may be there's a problem with permissions, i see the New Topic button. You could create an issue on GitHub but there are reasonable default values in LZDoom that usually work well and i don't think it's a problem with portals.
https://github.com/UZDoom/UZDoom/pull/404

[Uschi]

Ahoi Dr. Frag
using 4.14.3a
i test with my deathmanager launcher 2 custom .ini to launch a network game and make splitsceen game with 2 xbox controller. (works very flawless with your nice port!)
i discovered a special issue: when launching a server and closing the console window with the X at the right top. LZ Doom will close the window but keeps running in the background. the taskmanager shows lzdoom.
so the effect is, that the Network Port is bound to the old lzdoom task. so i cant create a new server with the same port address.
if i click the bottom button "Abort network game", lzdoom closes correctly.

the same is happening with join command, waiting at the console window and closing with X button right top. this also produces a crash of lzdoom.

can you or someone reproduce it?
I think the X Button of the console window is handling the close window event different than the abort network game button.

best greets

[drfrag]

Wenas. It's already fixed by dpJudas himself for 4.14.3b which will be released very soon. For now you'll have to kill the the process in the task manager. BTW that bug was present on GZDoom since long ago.

[Uschi]

thanks. i also thought it was coming from gzdoom. thanks for the info.