My critisism on GZdoom/ZDoom (mod note: derailed by toxic garbage, not worth the effort to save)

Now before I state anything further, I want to state that I do not hate gzdoom. It is definitely an impressive port and the amount of effort put into it is massive.

Rather, I want to state what I think is good and bad about the port.

The first major issue in my opinion is that it has an unnecessary amount of features that don't really do much. There are a few zdoom features that I have seen

in eureka that just seem unnecessary. And it isn't just in mapping either. Many of the enemy behavior changes only affect very specific scenarios.

The second issue is that it is not at all compatible with any other port. This means that if you want to use MAPINFO or if you recorded a demo

for deathmatch using a zdoom fork, it will not work in a single other source-port. Although there is an alternative with UMAPINFO, it is way

less popular. So, usually you have to convert it yourself or just switch to gzdoom entirely.

Before I state the third issue, I want to remind you that this is my opinion. I am not trying to hate on gzdoom. Heck, I sometimes use Lzdoom!

I just want to make that clear. Don't hate on any doom port!

The third issue is how unoptimized it is compared to other ports. I played nuts.wad on dsda-doom and it ran at an average of 120ish fps.

Gzdoom ran at about 30-60 fps. I also played bastion of chaos and it was sometimes 80fps but usually was around 40fps. Many people say it is optimized for doom but not for mods. And that is the exact issue. It has issues running mods

that were designed SPECIFICALLY for it and wads that run fine in vanilla.

Although there are more issues, these are the issues that affect me the most.

EDIT: Most people have been informing me about the unnecessary features section in my post and how there are plenty of useful things. And you are right! I am not saying that

every feature is useless. Rather, I am saying is that some of the thing's seem oddly specific and don't really have a use unless they are in very specific scenarios.

This applies to everything I have stated. It doesn't affect every part of the port. But it does enough that it makes it an issue for me.

Ignoring the first and third issues, although I don't understand those either, why would you expect port-specific demos to be cross compatible with anything else? Or pure vanilla compatibility?

46 minutes ago, BUYXRAYS said:

The third issue is how unoptimized it is compared to other ports. I played nuts.wad on dsda-doom and it ran at an average of 120ish fps.

Gzdoom ran at about 30-60 fps.

Did you try it in Vulkan? On my PC i'm getting a ton more fps in various mods compared to the default OpenGL.

48 minutes ago, BUYXRAYS said:

The third issue is how unoptimized it is compared to other ports. I played nuts.wad on dsda-doom and it ran at an average of 120ish fps.

Gzdoom ran at about 30-60 fps. Many people say it is optimized for doom but not for mods. And that is the exact issue. It has issues running mods

that were designed SPECIFICALLY for it.

Nuts was never designed specifically for GZDoom. In fact, the only thing Nuts was specifically designed for is the trash bin, true story.

1 hour ago, BUYXRAYS said:

The first major issue in my opinion is that it has an unnecessary amount of features that don't really do much.

So, disable them!

1 hour ago, BUYXRAYS said:

The second issue is that it is not at all compatible with vanilla or any other port.

Compatibility is strictly between ports, and game data. You wouldn't really say that ports are compatible with each other. Rather, they can share compatibility with certain game data. Demo compatibility is a big deal because the demo file is literally just a stream of inputs, so when you play back a demo it is as if you simply pressed the buttons the exact same way. So for example if one engine uses fixed point coordinates and the other uses floating point, one takes player input at 30fps while the other at 60, one has a table-RNG while the other doesn't... everything that happens in the game will start to deviate. Think of it like driving two different cars... unless they are pretty much identical, one will handle a little differently and so reproducing the same exact motions will not result in the car taking the same path.

Maps and other mods don't usually require the same level of precision to be playable. All but the most experimental vanilla maps can be played with no issues in GZ, and the slight differences in things like movement and RNG will not break the game completely in most cases. And, there are special options to recreate some of the bugs and oddities that existed in the original engine, meaning GZ can sometimes handle mods that depend on such "hacks."

1 hour ago, BUYXRAYS said:

The second issue is that it is not at all compatible with vanilla or any other port. This means that if you want to use MAPINFO or if you recorded a demo

for deathmatch using a zdoom fork, it will not work in a single other source-port. Although there is an alternative with UMAPINFO, it is way

less popular. So, usually you have to convert it yourself or just switch to gzdoom entirely.

Making a mod for GZDoom makes it incompatible with other ports, just like a BOOM mod cant be played with vanilla, or an Eternity mod cant be played with GZDoom (althrought GZDoom tries to be compatible with everything). And nobody forces you to use just use GZDoom you can have several executables on your pc.

On the subject of optimization:

It needs to be said many more times until the point gets really tiring, there's a massive misconception that since this is Doom, it should be piss easy to run in any situation. However, Doom is *not* a modern PC friendly game, you can't have it use modern technology and have it run exactly the same. It was not designed with things like hardware acceleration or multi-threading in mind. GZDoom's goal is to try it's damnedest to bring it into the modern age (hold the multi-threading), but is simultaneously limited by the bottle neck of having to use inefficient methods that only worked great for computers of the 90's. Of course nuts.wad doesn't run on it. Those 10k actors cost significantly more processing power, because GZDoom is cutting so many less corners, has to respect the original engines idiosyncrasies, and has a far larger load to handle to enable the sheer amount of mod support that it does.

Also, nuts.wad is not a performance metric. Try this mod instead.

The way I see it, the way ZDoom (and by extension GZDoom) have been developed since its inception kind of dug the developers into a hole. Demo compatibility became completely out of the question very early on, and it always seemed like there was never any sufficient amount of care given to interface design and being user-friendly aside from the noob-friendly "drag-and-drop" loading for mods. I think a lot of mods for GZDoom are pretty great for the most part, but the port itself is just so bloated and disorganized.

28 minutes ago, kevansevans said:

On the subject of optimization:

 

It needs to be said many more times until the point gets really tiring, there's a massive misconception that since this is Doom, it should be piss easy to run in any situation. However, Doom is *not* a modern PC friendly game, you can't have it use modern technology and have it run exactly the same. It was not designed with things like hardware acceleration or multi-threading in mind. GZDoom's goal is to try it's damnedest to bring it into the modern age (hold the multi-threading), but is simultaneously limited by the bottle neck of having to use inefficient methods that only worked great for computers of the 90's. Of course nuts.wad doesn't run on it. Those 10k actors cost significantly more processing power, because GZDoom is cutting so many less corners, has to respect the original engines idiosyncrasies, and has a far larger load to handle to enable the sheer amount of mod support that it does.

  

Also, nuts.wad is not a performance metric. Try this mod instead.

I think in the context of running Doom natively in your modern OS through a port, it really can be a lot less intensive than you're making it sound. The original PrBoom came out the same year as ZDoom and its derivatives still run far better. It's a matter of feature creep and bloat that weighs GZDoom down. In the dev team's pursuit of more and more modding features, it seems like they dug themselves into a hole in terms of what they can do with optimization among other things.

Just wait till @Graf Zahl hears about this!

As a mapper, I absolutely love GZDoom. I usually don't throw the GZDoom-isms in the player's face, and strive for maps that appear about 90% vanilla most of the time, but I'm still surprised how many little things I try to do in non-GZDoom projects and end up saying "Oh, crap, I can't do this little thing outside of GZDoom? But it's so useful!"

1 hour ago, OpenRift said:

I think in the context of running Doom natively in your modern OS through a port, it really can be a lot less intensive than you're making it sound. The original PrBoom came out the same year as ZDoom and its derivatives still run far better. It's a matter of feature creep and bloat that weighs GZDoom down. In the dev team's pursuit of more and more modding features, it seems like they dug themselves into a hole in terms of what they can do with optimization among other things. 

There's a difference between bloat and more complexity. I am well aware which changes made the playsim run slower than simpler ports, but changing those back now would break pretty much any modern mod out there because it solely comes from removing shortcuts in the original collision detection - mainly the ability to recursively call the movement code from action functions - that were ok in the context of vanilla Doom but not if you want to have an engine that behaves well with more complex stuff. It's actually all down to changes in P_TryMove and its subfunction P_CheckPosition that cause the performance loss. All the supposed bloat is completely irrelevant in this context because it normally does not get run for most maps.

I love mapsets that heavily rely on GZDoom-exclusive features and use them well. Wish we'd have more of them.

GZDoom allowed me to create a mapset of my dream but yeah, if it gets some rendering/logic speed up, that wouldn't hurt. I highly reckon that even without a massive source overhaul it could be brought up massively performance wise, if there was an option to disable BSP traversal entirely or for some linedefs only + all the static geometry and static ligts baked into one mesh and rendered just like a regular 3D model? There is a proof of such technique hand made with Map15 of Hell Renaissance, the game archive has two maps for it: Map15.wad and Map15_HR_v0d1.wad that you can play both and really see the difference (up to 400%) and with LZDoom's line distance culling it allows for 60 FPS on Athlon 2.6GHz + Radeon HD2400 pro in 640x400, which is techically the same as disabling BSP traversal for distant linedefs and thus saving CPU massively.

What's about logic optimization, Rachael came up with a really nice script that does enhance the matters with big monsters and projectiles count on big large levels, it's called "Slaughter Map Performance Booster", it slows down the time for actors that are far away for you thus, making it easier on CPU, that much easier that Brutal Doom styled mods can be played on nuts. The only drawback is that everything slows down but if they could speed the actor's speed according to the slowdown amount, that could make the game in the far distance feel more "laggier" but maintain the speed.

29 minutes ago, Darkcrafter07 said:

GZDoom allowed me to create a mapset of my dream but yeah, if it gets some rendering/logic speed up, that wouldn't hurt. I highly reckon that even without a massive source overhaul it could be brought up massively performance wise, if there was an option to disable BSP traversal entirely or for some linedefs only + all the static geometry and static ligts baked into one mesh and rendered just like a regular 3D model? There is a proof of such technique hand made with Map15 of Hell Renaissance, the game archive has two maps for it: Map15.wad and Map15_HR_v0d1.wad that you can play both and really see the difference (up to 400%) and with LZDoom's line distance culling it allows for 60 FPS on Athlon 2.6GHz + Radeon HD2400 pro in 640x400, which is techically the same as disabling BSP traversal for distant linedefs and thus saving CPU massively.
 

The only downside here is, that all is easier said than done. It's not something you could add in a day or week and have instant profit. To get this right it will require a lot of work

54 minutes ago, Graf Zahl said:

There's a difference between bloat and more complexity.

I mean, having as many options as there are console commands seems like bloat to me. 

58 minutes ago, Graf Zahl said:

I am well aware which changes made the playsim run slower than simpler ports, but changing those back now would break pretty much any modern mod out there because it solely comes from removing shortcuts in the original collision detection

I think this proves my point about feature creep digging you and the rest of the team into a hole you can't get out of.

Perhaps make your own source port ;) 

The only objective problem I have about GZDoom is @Graf Zahl's horrid default settings that make the game look terrible. (Seriously man, stop enabling texture filtering on by default, it looks horrible and a part of my soul dies every time I see a YouTuber talk about Doom and have texture filtering enabled in their footage :p)

Otherwise, it is still arguably the best source port out there, especially for modding.

Not to hate on the source port either. As a game development engine, it's nice to use considering DECORATE, ZScript and other features are a thing. As a way to play Doom itself, I'd rather stick DSDA-Doom for that.

And also like Roebloz said, never understood why it's a good idea to enable texture filtering by default, it wasn't made for that anyway.

The first issue here can essentially be drilled down to the classic "I don't want the features I don't need" bloat complaint that any larger product receives. I have added features to GZDoom that I wish I could remove again, but every time I have mentioned maybe we should do that, there's practically always someone that really likes the feature. That's why the bloat doesn't get removed - each feature is liked by someone. Your list of bloat features is different from the next guy's list.

The second issue is simply not what ZDoom and its family of source ports ever tried to do. Boom sort of emerged as a standard in Doom modding only really because half the ports following this standard emerged from Boom itself. Restricting yourself to that standard has its pros and cons, as most modders will probably agree. There's plenty of excellent boom compatible source ports out there, so the solution here is pretty simple: switch to a source port that fits your needs, if these are indeed your primary needs. It isn't really GZDoom's fault if some mods chose differently and actually wanted GZDoom's features.

Then there's the optimization issue. This is a matter of perspective. Modders generally like their mods to look the way they did when they created it, so any optimization for GZDoom comes with the huge caveat that it shouldn't break existing mods. I could design a "BSP-less" version of GZDoom in like 10 minutes, but it would also render half the GZDoom mods wrongly. Most GZDoom users would rather have lower performance with backwards compatibility, than speed. That is why GZDoom doesn't just fix its speed. It is actually quite fast for something that uses the rendering strategy that it has. Any further improvement requires a ton of work that so far has been too much for it to happen. Don't take our word for it though - it is an open source project that welcomes pull requests improving the performance, if it is such a simple thing to do.

41 minutes ago, OpenRift said:

I think this proves my point about feature creep digging you and the rest of the team into a hole you can't get out of.

I think this statement just proves that you shouldn't judge things you don't understand.

Doom has some very serious design flaws. Some of these flaws do not really matter with the original feature set, but once DECORATE came to be some of them were causing some rather obnoxious problems with mods, so attempts were made to make these mods work. Well, the fixes worked, but the downside was that when there's lots and lots of actors in a map, performance dropped quite a bit. You normally only notice this on maps like NUTS where an incredibly high amount of projectiles is flying around, so the trade-off was deemed acceptable.

47 minutes ago, OpenRift said:

I mean, having as many options as there are console commands seems like bloat to me. 

No-one disagrees that the GZDoom options menu got a bit overwhelming tbh, that's why new GZDoom installations come with a simplified Options menu.

47 minutes ago, OpenRift said:

I think this proves my point about feature creep digging you and the rest of the team into a hole you can't get out of.

"Feature creep" is somewhat the wrong term to use there I believe, as implies that there was some agreed upon list of features that were meant to be the only things included, from which the source port then crept.  AFAIK this has never existed, so you can't really have "feature creep" if there never was meant to be an "end" to the features in the first place.

2 hours ago, Graf Zahl said:

I am well aware which changes made the playsim run slower than simpler ports... It's actually all down to changes in P_TryMove and its subfunction P_CheckPosition that cause the performance loss. All the supposed bloat is completely irrelevant in this context because it normally does not get run for most maps.

I've always been curious as to why GZDoom struggles with extreme amounts of active monsters when compared to vanilla-ish source ports, and now we know.

That being said, performance issues with GZDoom have always been overstated as its really just fine (compared to vanilla-compatible ports) with the vast majority of maps and WADs out there. Even mega-slaughter maps are fine as long as they don't activate most of their monsters at the same time. For example, Okuplok runs well in GZDoom, while SlaughterMAX MAP28 (featured in Antaresian Reliquary) does not.

6 hours ago, TasAcri said:

 

Did you try it in Vulkan? On my PC i'm getting a ton more fps in various mods compared to the default OpenGL.

I tried to do it. It completely broke gzdoom. I had to completely reinstall it. Apparently it does this on M1 Macs.

It gave me a segmentation fault.

i love gzdoom as a super unlimited modding sourceport, being able to use zscript is wanderful, gzdoom's UDMF is really good too.

my only problem with it, its just the position it is right now.

newer players tend to use it for everything. and i think it kinda sucks for that. its not going for full compatibility with all pwads, it doesn't have full dehacked support, or advanced vanilla tricks like mikoportals. dsda-doom/prboom+ is more of the "compatible and accurate with everything source port" then gzdoom is.

but, i don't judge it for that at all, i just don't like how people see it as the ultimate doom source port and try using it with everything. making mappers having to worry about it.

i wish gzdoom had a alternative, that was more compatible and accurate when it wants. but also kept the comfiness, freelook, smoother graphics, the heavy lifting and this kind of stuff.
for non turbo nerds that want to play doom but not in a speedrunning environment heh.

also stop using gzdoom when mapping for vanilla/ limit-removing aaa, it changes alot of bugs and errors of the game and levels that other source ports keep, these are important to keep in mind.

2 hours ago, BUYXRAYS said:

I tried to do it. It completely broke gzdoom. I had to completely reinstall it. Apparently it does this on M1 Macs.

It gave me a segmentation fault.

M1 Macs don’t support Vulcan. It’s either OpenGL or Metal for them and gzdoom doesn’t support Metal yet.

24 minutes ago, JBerg said:

M1 Macs don’t support Vulcan. It’s either OpenGL or Metal for them and gzdoom doesn’t support Metal yet.

Thanks to _mental_, the Vulkan backend actually does support Metal via a thin translation layer known as MoltenVK. This is all built-in, so the user doesn't really have to do anything. Why it crashes on his M1 Mac I have no idea though.

4 hours ago, Higo Doragon said:

i love gzdoom as a super unlimited modding sourceport, being able to use zscript is wanderful, gzdoom's UDMF is really good too.

 

my only problem with it, its just the position it is right now.

newer players tend to use it for everything. and i think it kinda sucks for that. its not going for full compatibility with all pwads, it doesn't have full dehacked support, or advanced vanilla tricks like mikoportals. dsda-doom/prboom+ is more of the "compatible and accurate with everything source port" then gzdoom is.

 

Instead of complaining ask yourself why new players choose GZDoom over the 'lesser' ports. In the end, aside from GZDoom having greater exposure there's one other thing that quite takes me out of these other ports and that's that they do not feel like a modern app, they feel like something out of the late 90's transported into the present without fully adjusting to modern expectations. They also mostly feel the same, considering their overlapping goals.

Regarding those 'modern vanilla tricks'. Are those really what makes the game tick? I have seen one notable project that made use of them (KDIKDIZD) and that was ported faster to GZDoom than you could look. So nothing was lost in the end.

The bottom line here is, GZDoom does bring new players to the community, but the important question is how long they stay if they see these salty reactions from some people here who cannot accept the concept of Doom moving on from its 1993 roots.

I figured that the "new player" concerns regarding GZ clouding one's first impression of Doom would've been at the very least slightly mitigated now thanks to the much-improved Unity port. After all, it's the new, basic straight-out-of-box experience for anyone who buys it these days.