Talk:GZDoom

Out of date

This article needs a serious update. GZDoom development has since resumed, with a new release last December. I'm surprised the article wasn't updated further since the 2.0 release. ConSiGno (talk) 21:04, 4 May 2015 (UTC)

3.2.5

It says 3.2.4 but latest is on the ZDoom forums. I was looking for the wiki text to edit to update but could not find it? Mrchris (talk) 17:54, 8 February 2018 (CST)

I've updated it. For future reference, the date and version number are taken from GZDoom/Date and GZDoom/Version so it's just updating those individually. Eris Falling (talk) 20:11, 8 February 2018 (CST)

(edit conflict)  Yeah that.  :D   Ports and a few other apps have such "articles" nowadays, e.g. DeuTex/Version, Doom64 EX/Date.    Ryan W (living fossil) 20:17, 8 February 2018 (CST)

"Laggy"

Okay, so I'm curious why this was added in the first place, and I'm the anon that made the removal edit. Now the original editor wants to move "performance issues" to a whole separate section? The three cited "sources" are essentially two randoms complaining about lag in extremely demanding mods (only one of which actually even bothered to participate in their own thread after receiving an answer) and a developer discussion which clearly points out the issue is hypercomplex geometry combined with dynamic lights. These are hardly worth mentioning, much less taking up nearly HALF the article's footnotes. This to me reads like a cherry-picked hit piece rather than a legitimate point of discussion. GZDoom isn't intended for low-end machines and never made any pretense to be. Caligari87 (talk) 18:04, 7 January 2022 (CST)

I'm the one who added it. Since you're one of the sources, particularly the single-threaded bottleneck, I appreciate your contributions on the ZDoom forum. But I completely disagree that it shouldn't be covered here. It's a very real experience for people that you and others respond to on the forum. Like it or not, real people use GZDoom in this way. And it's not niche at all: Project Brutality is one of the most popular GZ-only mods, and the big, ornate maps like Bastion of Chaos get Cacowards. Plus, you're completely wrong about the "hit piece" accusation. Click my username and review my edit history :) Anyhow, no hard feelings on my end, but again completely disagree. --PhilthyPhilistine (talk) 18:16, 7 January 2022 (CST)

Essentially I disagree with the naïve framing that this is a "limitation" of the engine. Project Brutality, like its parent project, is a terribly-optimized hodgepodge of code and effects. Would you add a paragraph to the Wikipedia article about the limitations of the Unity engine because "Babby's Popular First Asset Store Game" has performance issues? As clearly stated in the linked threads: When it comes to complex maps and mods, these are issues endemic to Doom's map BSP and gameplay sim in general because of how it forces reliance on single-threaded CPU performance (unlike most modern engines). The reasons people seem to complain about it more with GZDoom is simply because the baseline system requirements are higher than Boom or Chocolate. It's the difference between being able to stream 480p smoothly but lagging at 4kHD. That's not some failing in GZDoom's design, and presenting it as some kind of important point is disingenuous and only serves to spreads a misinformative meme. Caligari87 (talk) 19:10, 7 January 2022 (CST)

I agree with Caligari on this one, to be honest I don't see the point of a performance section just because the baseline is higher, I mean, should I also write that prboom++ lags on my raspberry pi on the later maps of struggle: antaresian legacy? I think not. Though at the very least, the poor examples seem to have been removed already... --Dynamo128 (talk) 19:16, 7 January 2022 (CST)

I agree as well, because the same thing could be said of literally any game engine if stretched beyond its means or run on hardware that doesn't meet the requirements. Hell on a 486 DX4 75, Doom II itself didn't run very well in the later maps. Though that would be, ironically, more topical information for the wiki to cover than source port performance, which could vary vastly over time due to ongoing development plus hardware advances. --Quasar (talk) 19:25, 7 January 2022 (CST)

In regards to the last point you made, the Punisher article has that type of info in the Trivia section. I didn't know about the official games having problems on reasonable 1994 PCs, though. That was many years before I ever played the game :) --PhilthyPhilistine (talk) 20:41, 7 January 2022 (CST)

I can agree that calling GZDoom's tendency to lag in certain scenarios a limitation is overshooting it, but for what it's worth, I do think there's no harm in mentioning it on the page. Obviously, the way one would phrase it is key here - as factual and neutral as possible, as a wiki page should be in the first place. And it certainly doesn't warrant a whole section of its own. I know I'm largely the odd one out here, but with how drastically GZDoom differs from your "average" source port, I genuinely believe that addressing the port's performance would not be a bad thing. But there'd need to be some information regarding the specific scenarios where GZDoom's performance tends to drop - which is namely when it has to process 10k actors moving at once (see nuts.wad) or render scenes with lots of dynamic lights and/or pieces of geometry. --MF38 (talk) 02:43, 8 January 2022 (CST)

For reference, the proposed Performance section of this article (that is pending review). I think I did an adequate job concisely explaining it. If others with more technical knowledge of the GZ engine quirks/nuances/limitations want to refine it, that would be good too. --PhilthyPhilistine (talk) 11:08, 8 January 2022 (CST)

←←←←
Let's review the article reference in question here. How is the gaming PC of ZDoom forum user "Doge" in any way under the "baseline" requirements of GZDoom? He's got a decent system, and as Caligari87 responded there, it's the 2.6 GHz CPU that's the likely bottleneck. But that's not an "old potato" CPU, and like Doge said, he can run modern games at 60 FPS with mid-level settings. Now, let's look at the official GZDoom download page. The only baseline requirement stated is OpenGL 3.3, which Doge probably has (don't know the GPU details).

It's rather strange to me that these would be considered too extreme or too niche of cases. After all, Graf Zahl stated this a year ago: "I never thought I'd see a map that brings down my computer by its sheer size - but this year two of that kind got awarded. I have to wonder - can anyone play them at decent frame rates?" So now Graf's computer is underpowered? --PhilthyPhilistine (talk) 19:40, 7 January 2022 (CST)

These are nothing more than anecdotes. I was able to play said those two maps just fine and I don't have a great computer (Graf just recently mentioned needing to upgrade his hardware), you didn't really address the points brought up by Quasar and myself here. --Dynamo128 (talk) 20:00, 7 January 2022 (CST)

The stated experience of Mr. GZ himself, the very founder of the most popular source port, is "nothing more than an anecdote". Please tell me you don't seriously believe that. And what else would I respond to in your post: that nonsense about a Raspberry Pi is apples and oranges compared to the Doge post I just covered.

I'll restate what I originally responded to Caligari with: Like it or not, extreme GZ-only maps win Cacowards and people play them on reasonably-powered computers but experience lag. Lots of people like Project Brutality, and some (not all) experience bad lag as a result. It's a notable part of the GZDoom ecosystem and deserves to be covered in this article. --PhilthyPhilistine (talk) 20:24, 7 January 2022 (CST)

As I stated, you cannot compare any Doom engine to a modern game engine. It simply does not scale the same way. Honestly I'm not sure how else I can possibly explain this any clearer than it already has been. GZDoom raises the ceiling on what is possible, and the underlying foundation has to support that. It enables the modder to lean on many many advanced scripting and rendering capabilities. These advanced scripting and rendering capabilities require more processing power as a baseline, processing power which must be jealously shared and carefully allocated. A map which runs fine in PrBoom may lag in GZDoom, because PrBoom doesn't need to allocate processing time for the possibility of different monster AI routine flags from the half a dozen games GZDoom supports, nor the dynamic light linking, or any of a dozen other things. This is not a failing or a limitation of GZDoom, because PrBoom would have the same behavior if you gave it all of GZDoom's modding features. Caligari87 (talk) 20:20, 7 January 2022 (CST)

I don't disagree on technical grounds. I personally don't have any lag problems with my setup played on the maps I enjoy. (The only two lag problems out of the many PWADs I've played were on GZ-only maps. No big deal, delete them and move on to one of the many other maps worth playing.)

But, as I just responded to Dynamo128, these things are a notable part of the GZDoom ecosystem and deserve to be covered in the article. You can't play the "not a modern engine" card when popular maps and mods cause lag for reasonable systems. --PhilthyPhilistine (talk) 20:30, 7 January 2022 (CST)

If you play a mod/game designed for GZDoom which lags on your PC, then the simple explanation is that the person who made the mod has a more powerful PC than you, regardless of how "reasonable" you think your system is. That's not notable, it's called "basic facts". GZDoom doesn't put an upper limit on what performance modders can command. Caligari87 (talk) 20:48, 7 January 2022 (CST)

Are you seriously claiming that Doge and his 2.6 GHz CPU are unreasonable? --PhilthyPhilistine (talk) 20:50, 7 January 2022 (CST)

For the maps and mods he's apparently trying to play? YES. You can play vanilla Doom in GZDoom on a phone or a $35 RasPi just fine in most cases. But maps with lots of actors or complex geometry scale exponentially in the power they require, and yes that can outstrip a 2.6GHz CPU easily because Doom's single-threaded gamesim and BSP is not suited to how modern systems scale performance. I don't understand how this is a difficult concept to grasp. Caligari87 (talk) 20:57, 7 January 2022 (CST)

Think of it this way: Pretend your Doge. You already play all of the latest games 60 FPS on mid-level settings, but to your surprise you try GZDoom with PB or perhaps another mod/map combo and get some lag. Granted, slaughter maps are extreme, but it's still within the realm of expectations for the average gamer that they can do such things on their gaming PC. Hence the repeated forum threads about this. The limitations of the engine and the lag people experience with popular maps/mods deserves to be documented in this article. --PhilthyPhilistine (talk)

And I don't think it deserves to be documented (at least, not remotely how you had it written), because it simply fuels the pervasive meme that "GZDoom is an unoptimized shitty port". GZDoom is already very optimized given the amount of features it provides, and the basic nature of the Doom engine in general prevents it from being optimized further. That's not a GZDoom problem. This isn't as apparent with other ports, because modders simply can't push them as hard. Describing this as a "limitation of GZDoom" is straight-up misinformation.

(And for the love of god please stop appealing to "but muh latest games". It's apples and oranges. The way modern games and GZDoom utilize system resources isn't even remotely comparable and continuing to harp on it points to a fundamental misunderstanding of the problem. )

But whatever. I'm tired and I'm done, so I'll let someone with approval powers make the decision and if necessarily I'll try to workshop it later to accurately convey the nature of these so-called """limitations.""" Caligari87 (talk) 23:22, 7 January 2022 (CST)

To whatever extent lag is thanks to certain mods, such as Project Brutality which coats every surface in the game in thousands of blood decals and gib sprites, causing massive overdraw that would hurt any game engine regardless of how optimized it is (fillrate is the modern limitation of graphics, not poly or vertex count), then it should be documented on those mods' pages, not here.

To suggest that there is a systemic problem with lag in GZDoom requires evidence that this applies to all sorts of mods, including ones of normal complexity. Until such is presented, I am not in favor of this information, because it does in fact remain strictly anecdotal. A few threads complaining about specific mod combos not running well is predictable, especially when the ZDoom community tolerates and encourages loading dozens of conflicting gameplay mods on top of each other which saturate the environment with often expensive worst-case effects involving translucent blending, masked texturing, dynamic lighting, and even hardware shader effects.

To suggest this is somehow not an issue for other engines would be disingenuous. I am a game developer. I ported Turok 2 to the Nintendo Switch. As part of that I had to dial down several of its particle effects because the post-process shader pipeline in effect was causing too much massive overdraw, eating up all the system's fill rate (there's that nasty word again). It's not free, you can't treat it as an unlimited resource.

I will allow some additional time for input but my ruling at this point is going to be to remove this information from the article for lack of rigorous support. If you want to do a systematic study of GZ performance and how it scales with mod complexity, we will welcome your article with appropriate charts and graphs. Otherwise I see this as unencyclopedic. And keep in mind as the author of an alternative source port sometimes seen as a GZ rival I have zero reason to be biased here.

--Quasar (talk) 13:24, 8 January 2022 (CST)

Researching even further, some of the references included are out-of-date. This, discussing a heavy slaughter map that would likely also experience slowdown in Eternity and PrBoom-Plus, was being exacerbated by a bug in dynamic lighting which caused it to cost processing time when not even contributing to the scene, was fixed in the very thread the issue was brought up in. --Quasar (talk) 13:42, 8 January 2022 (CST)

Thanks for the thorough, well-stated response here. In the heated exchanges of last night I forgot an important (to me) reason why I added this performance/lag info to the article in the first place: providing readers who may be enamored with the awesome mods they see on Youtube (PB being one of the most popular there) that there are realistic limits to what GZ can do, and for some (not me), rather disappointing results (like Doge).

So, anyhow, I see your points and makes sense that some newer engines would be taxed with slaughter-style enemy hordes or crazy gore. I'm certainly not going to do a "systematic study". I'm content with my level of technical knowledge on this subject, which is far less than yours. Since I doubt anyone else will do it, I'll go ahead and remove the Performance section now and add a ref or two in the PB article. (I also want to add ACS to the lede of this article, per Cagli's edits to ZScript yesterday, so I'll do that after the removal.) --PhilthyPhilistine (talk) 22:51, 8 January 2022 (CST)

Since i love a good argument, i am going to side with Caligari and Quasar and anyone else who is asking why GZDoom out of all port pages needs a performance section. Some things about Doom performance are inherent on the Doom engine itself. What GZ does is introducing a whole post-processing pipeline that brings in pretty pictures, but also introduces additional strain on top of the way the Doom engine works. What would bring massive gains is truly parallelized rendering, and Rum & Raisin Doom shows both how much performance gains and development efforts that requires.

Simply put, When GZDoom maps are laggy, its both a combination of inherent Doom renderer limitations being imposed against a modern post-processing framework that just adds on top of everything else going on. You may also adding a performance page for K8Vavoom since that's the only other [i]high-end[/i] port on the graphical scale. If anything, instead of a performance subsection, one can explain that GZDoom's rendering capabilities combined with how the Doom renderer works will introduce an additional performance strain that isn't easily fixed.

Lastly: In my eyes full-on subsection in my eyes won't do, because then we need to discuss what is a performance limitation. Are clever vanilla or software renderer hacks performance limiting because GZDoom can't render them or slows down to a crawl? Are things like massive Multiplayer ZDaemon/Odamex sessions with 256 players performance limiting because the network layers are pushed to their limits? What GZ's advanced effects require extra hardware power on top of an engine that is rooted in 1993 rendering paradigms. --Redneckerz (talk) 16:34, 8 January 2022 (CST)

I like this info you shared here. I just removed the Performance section in question, but I still think this type of info belongs in the article in some form. Perhaps fleshing out the Features section with helpful explanations like Redneckerz wrote here, instead of just a bland bulleted list? Because, as I stated at least twice above, lag is a fairly common problem and it would be helpful to readers to better understand how GZDoom operates, including things like the single-threaded bottleneck. But, as I also stated above, I'm not the one who will be adding this info. --PhilthyPhilistine (talk) 23:04, 8 January 2022 (CST)

Wouldn't that be similar? I think a short derivative notice would suffice, rather than a elaborate outlining of why GZ (and only GZ) can run into performance penalties. I personally do not see the need for it, and you do not wish to write an outline but rather a more elaborate explanation. So it seems in that sense, we are in a stalemate. --Redneckerz (talk) 12:14, 9 January 2022 (CST)

I don't know what you mean by "stalemate". I was making a suggestion that would require editors with more knowledge of the subject matter to implement in the article. There are some very knowledgable people in this thread, so if one or more of you want to do this, it could be a nice improvment for the article. The suggestion I made is not the only way to go about it; it's just an idea based on the current state of the article. If there's a better approach, by all means go for it. --PhilthyPhilistine (talk) 12:35, 9 January 2022 (CST)

To go devil's advocate here, to some extent the performances issues are a self-inflicted wound on GZDoom's part. Raising limits as much as it has is what enables modders to go overboard. You couldn't have Bastion of Chaos or Ar Luminae without UDMF. And you couldn't have Brutal Doom without DECORATE. So it's not so much that GZDoom's performances are intrinsically bad, and more that it allows you to do stuff that will kill your performances.

That said, GZDoom is not the only port that supports UDMF, with Eternity and k8vavoom both receiving high-profile UDMF maps last year (Heartland for EE, The Unending and Freaky Panties IV for k8vv). And MBF21 combined with DSDehacked may bring Brutal Doom-style actor spam to more conservative ports like DSDA-Doom or Woof!, too; especially when there's tools like DECOHack to make porting DECORATE code to DEHACKED relatively easy. --Gez (talk) 04:47, 9 January 2022 (CST)

One thing is linked to the other. Its a mixture of both. For the rest i agree: With the new standards, even less advanced ports can now potentially turn into a lag fest. Far as i can tell there has yet to be a WADset that pushes these standards to the extreme, so how much performance loss will occur is still in the middle. But if GZ were to support these standards fully aswell, that would just mean that yet another potential performance penalty will be introduced. --Redneckerz (talk) 12:14, 9 January 2022 (CST)