Is Doom CPU or GPU bound?

[Shikamaze]

Title. What makes a Doom level lag, is it a CPU can't handle all that stuff, or is it GPU can't handle that much stuff? On a similar question why are ZDoom based ports laggier?

[Shepardus]

If you have to ask that question, it's probably CPU-bound. But of course it depends, you can always come up with a GPU weak enough that it becomes the bottleneck.

[Quill]

2 hours ago, Shikamaze said:

On a similar question why are ZDoom based ports laggier?

 

Probably because it's a whole different engine with a Doom coat of paint on it. Same reason why some of the original bugs don't work there.

[Dark Pulse]

CPU. Many Doom source ports don't have hardware-accelerated renderers, and are pure CPU horsepower.

[Swagskart]

On 10/25/2022 at 3:35 PM, dotQLL said:

 

Probably because it's a whole different engine with a Doom coat of paint on it.

I thought ZDoom was just an engine bulit upon Boom, which means that it is a Doom engine?

 

Also no. The reason is because ZDoom ports use too much of the CPU as opposed to the GPU. You can always change this by using OpenGL renderer but even then it becomes too much CPU dependant to the point where it's basically software rendering

[No-Man Baugh]

1 hour ago, Swagskart said:

I thought ZDoom was just an engine bulit upon Boom, which means that it is a Doom engine?

According to doomwiki.org's Source Code Genealogy section on the ZDoom article and ZDoom.org/wiki version history page: ZDoom is based off of NTDoom and ATB Doom, ZDoom just incorporates Boom and MBF compatibility

[dpJudas]

(G)ZDoom is the Doom engine just as much as any other source port. It started with the original Doom source code, just like anything based on Boom or MBF. For some reason some on Doomworld believe it is a completely different engine because it changed 42.24% of the code, while those ports that only changed 13.37% of the code is still Doom. It is an arbitrary cutoff.

 

The real reason ZDoom is laggier is that its features are more complex and that makes it is slower at processing a frame.

 

Oh, and Doom is pretty much always CPU bound, unless you have a really really poor GPU.

[banjiepixel]

GZDoom kinda is it's own engine at this point, it just happens to still have compatibility. GZDoom can't replicate how the original Doom engine works with 100% accuracy anymore and what it can do goes so far beyond what the original Doom engine is able to do. It's based on Doom engine code but main goal for the development is clearly to be general purpose FPS game engine that also can be used to play Doom. You can play Doom with GZdoom but it doesn't preserve the original ruleset of the Doom engine and instead just imitates it, just like quake or unreal engines are only able to imitate how the actual original Doom engine worked.

[Shepardus]

9 minutes ago, banjiepixel said:

GZDoom can't replicate how the original Doom engine works with 100% accuracy anymore

Neither can most source ports.

[banjiepixel]

5 minutes ago, Shepardus said:

Neither can most source ports.

 

If it can play vanilla demos, all of the Doom engine functions are still being replicated, if that is not 100% accuracy, it is atleast so close to it that the difference doesn't matter. Just like not all emulators are exactly 100% accurate to original hardware but as a emulator GZDoom would be extremely inaccurate while something like DSDA-Doom would have much more acceptable accuracy as a emulator.

[Swagskart]

8 hours ago, Shepardus said:

Neither can most source ports.

Well, PrBoom and DSDA-Doom exist

[Swagskart]

17 hours ago, No-Man Baugh said:

According to doomwiki.org's Source Code Genealogy section on the ZDoom article and ZDoom.org/wiki version history page: ZDoom is based off of NTDoom and ATB Doom, ZDoom just incorporates Boom and MBF compatibility

Ah, I see that. Thought it was entirely based upon Boom

[dpJudas]

Ah yes, the good old demo compatibility argument. Doom 2 v1.666 then isn't the doom engine because it can't play 1.9 demos correctly. So now we have established PrDoom and DSDA-Doom is more Doom than the software released by id software itself!

[banjiepixel]

10 hours ago, dpJudas said:

Ah yes, the good old demo compatibility argument. Doom 2 v1.666 then isn't the doom engine because it can't play 1.9 demos correctly. So now we have established PrDoom and DSDA-Doom is more Doom than the software released by id software itself!

 

It doesn't work that way. Doom 2 v1.666 is just older version of the doom engine and is just outdated, so naturally it can't play 1.9 demos correcrly. And being officially released by id software makes it doom engine by default. It's only when 3rd party starts messing with the doom engine code is when the engine can become something else than the doom engine and demo compatibility is critital to being still being the doom engine. Source port like DSDA-Doom still has all the basic functionality of the Doom 1.9, which is the latest version of the doom engine.

 

GZDoom isn't a doom engine, it's a fork of the doom engine with tons of new and radically different functionality. It has no ability to play like the latest official version of the doom engine correctly. It is a different engine at this point, engine that is used in many commercial FPS projects that play almost nothing like the original Doom games.

[Shepardus]

Plenty of source ports besides (G)ZDoom are also not demo-compatible but I don't see people saying they're "not Doom" or comparing them to the Quake and Unreal engines. Saying that GZDoom "just happens to still have compatibility" with Doom really undersells the work that goes into making it playable with nearly all Doom-related content out there - that doesn't "just happen." For all that GZDoom has rewritten, it's still Doom at its core, and calling it a "whole different engine" is misleading both in terms of how much GZDoom is still Doom as well as the difficulty of making an actually different engine like the Quake or Unreal engine run Doom. It doesn't really answer the original question anyway, as GZDoom performance has at least as much to do with what it hasn't changed as what it has. If it were actually a "whole different engine" and just dropped support for Doom entirely, maybe it'd run better on modern hardware.

[hobomaster22]

Doom is without a doubt CPU bound even for ports using hardware rendering. The way the BSP tree works is very CPU intensive. For large maps and the vast majority of user's systems, the GPU is going to be sitting idle waiting for the CPU to generate the data. Every frame has the walk the BSP tree to generate all the data to send to the GPU. Worse, larger maps also tend to have large monster counts. Once they wake up all their AI routines and collision checking stress the CPU even more dropping the frame rate further. Ports like Boom or dsda-doom have less features and less to check for dealing rendering and collision checking, etc so they will stress the CPU much less. GZDoom's features aren't free.

[banjiepixel]

2 minutes ago, hobomaster22 said:

Doom is without a doubt CPU bound even for ports using hardware rendering. The way the BSP tree works is very CPU intensive. For large maps and the vast majority of user's systems, the GPU is going to be sitting idle waiting for the CPU to generate the data. Every frame has the walk the BSP tree to generate all the data to send to the GPU. Worse, larger maps also tend to have large monster counts. Once they wake up all their AI routines and collision checking stress the CPU even more dropping the frame rate further. Ports like Boom or dsda-doom have less features and less to check for dealing rendering and collision checking, etc so they will stress the CPU much less. GZDoom's features aren't free.

 

I have been wondering why they can't make a option in GZDoom to skip all those checks and other costly advanced stuff when they are not needed. I am talking about special mode that makes GZDoom have only features similar to PrBoom+ and does nothing extra beyond that point. I mean there are very little reason to use such thing when actual PrBoom+ and DSDA-Doom exists but demo compatible emulation mode within GZDoom would be great to make it really the all in one solution for playing Doom. Even just being able to turn GZDoom fully vanilla/limit-removing accurate would be awesome.

[Murdoch]

On 10/26/2022 at 4:33 AM, Shikamaze said:

Title. What makes a Doom level lag, is it a CPU can't handle all that stuff, or is it GPU can't handle that much stuff? On a similar question why are ZDoom based ports laggier?

 

The original Doom and many ports, cpu. Gpus as we know them today weren't a thing when Doom was written. 

 

I will add one extra comment not precisely covered by the mostly excellent and accurate responses and that is coding inefficiencies are a factor. Each engine (Doom and otherwise) will eventually reach a point where inefficiencies in the coding will affect performance in certain circumstances. This will effect Doom ports in different ways too. Zdoom as others have pointed out have more work to do. This will become less obvious in a standard map, but more obvious on a more complex map depending on your computer's performance.

Edited October 31, 2022 by Murdoch

[dpJudas]

22 hours ago, banjiepixel said:

It doesn't work that way. Doom 2 v1.666 is just older version of the doom engine and is just outdated, so naturally it can't play 1.9 demos correcrly. And being officially released by id software makes it doom engine by default. It's only when 3rd party starts messing with the doom engine code is when the engine can become something else than the doom engine and demo compatibility is critital to being still being the doom engine. Source port like DSDA-Doom still has all the basic functionality of the Doom 1.9, which is the latest version of the doom engine.

 

GZDoom isn't a doom engine, it's a fork of the doom engine with tons of new and radically different functionality. It has no ability to play like the latest official version of the doom engine correctly. It is a different engine at this point, engine that is used in many commercial FPS projects that play almost nothing like the original Doom games.

It doesn't work that way. Since we've now concluded that 1.666 is the Doom engine after all, the fact that DSDA-Doom can't play its demos means that DSDA-Doom isn't Doom. Since Doom engines are only doom engines if they have demo playback compatibility. I recorded the demo in 1.666 and DSDA-Doom desyncs when I try to play it.

 

As you can probably tell already, this kind of logic is totally broken. We can also extend from this kind of logic that if I change ONE line of code in DSDA-Doom, the source port goes from "doom engine" to "not doom engine". Based on similar logic, Windows 2000 and Windows NT are completely different kernels, because there are some applications Windows 2000 can't run that Windows NT 4 could.

 

I'm sorry, but when something is considered a completely new engine is an entirely subjective thing. Using demo compatibility as some kind of proof is just silly. If you want people to play DSDA-Doom, why don't you spend your time advertising its good features instead of resorting to this kind of nonsense?

[TasAcri]

Back in 1994 there were video cards that would slow down DOOM, even when using a 486 or higher CPU. There were also graphics cards fast enough that helped DOOM run a bit better on 386 machines.

 

Or so i'm told. First PC i ever got was a Pentium 3 + Voodoo 3 so i don't have first hand experience.

[Edward850]

41 minutes ago, TasAcri said:

Back in 1994 there were video cards that would slow down DOOM, even when using a 486 or higher CPU. There were also graphics cards fast enough that helped DOOM run a bit better on 386 machines.

 

Or so i'm told. First PC i ever got was a Pentium 3 + Voodoo 3 so i don't have first hand experience.

There's a kernel of truth to it but not entirely. The graphics card didn't help Doom at all, but it could become a bottleneck if the card didn't have the bandwidth or memory to push the framebuffer at full speed. However it couldn't make the game any faster and wouldn't help a 386 in any possible way, as it wasn't used as a graphics coprocessor.

Edited October 30, 2022 by Edward850

[Kinsie]

On 10/26/2022 at 2:33 AM, Shikamaze said:

Title. What makes a Doom level lag, is it a CPU can't handle all that stuff, or is it GPU can't handle that much stuff? On a similar question why are ZDoom based ports laggier?

The vast majority of performance issues can be put down to this: To grossly oversimplify things, the extended modding functionality means that more work has to be put into processing every monster every tick (1/35th of a second). As such, maps with tons of monsters that run okay in vanilla, Boom etc. are more likely to chug in the ZDoom family. Especially GZDoom, as the extended modding functionally has become even more extended and rooted deeper into everything.

 

The knife cuts both ways, sadly!

 

There's some other things that can reduce performance - large areas that aren't broken up by one-sized lines tend to cause performance issues, especially on weak old GPUs - but large monster counts are probably one of the more common culprits.

[prfunky]

5 hours ago, Kinsie said:

There's some other things that can reduce performance - large areas that aren't broken up by one-sized lines tend to cause performance issues, especially on weak old GPUs - but large monster counts are probably one of the more common culprits.

Is "one-sized" or "one-sided" lines?
Asking to clarify meaning in my head, not trying to be a grading school teacher here.

Any expansion/explanation of this concept/logic would also be appreciated.

[Kappes Buur]

11 minutes ago, prfunky said:

Is "one-sized" or "one-sided" lines?
Asking to clarify meaning in my head, not trying to be a grading school teacher here.

Any expansion/explanation of this concept/logic would also be appreciated.

 

Breaking up a large sector into smaller ones is done with 2-sided lines.

1-sided lines have a void on the "unused" side and are thus impassable.

 

[prfunky]

49 minutes ago, Kappes Buur said:

 

Breaking up a large sector into smaller ones is done with 2-sided lines.

1-sided lines have a void on the "unused" side and are thus impassable.

 

So, making larger sectors or having many sectors joined by 2-sided lines

is more taxing on the engine, correct?

[Kappes Buur]

All it means is:

 

• breaking up a large sector is preferable

Spoiler

 

• over a single large sector

Spoiler

 

Edited October 31, 2022 by Kappes Buur