Why are GZDoom's default settings the way they are?

[dpJudas]

For some Doomworlders every bug or unintended side effect in the original engine is a feature to be exploited. It is that very attitude that makes it almost impossible to fix the rendering performance of complex Doom maps. All the code stuck in time because it has to emulate such edge cases is what makes it so hard to move some of the time critical code to compute shaders.

[Graf Zahl]

The impact on the renderer from those hacks is minimal. The far, far bigger problem is that the map's geometry is not static so that every single linedef has to be processed for every single frame. This was introduced by ZDoom itself, actually, namely, the backside activation feature. Doom originally only had it for a few door types. This alone is the single biggest optimization blocker in the entire game because it makes it completely impossible to detect static map parts and optimize them out of the BSP.

These hacks are far more a problem of the playsim code because in order to preserve these glitches there must be no change of the movement code whatsoever, however tiny. I think this one's easy to sit out. If maps stop working on the more popular ports, it's the mappers who will be in trouble.

[dpJudas]

Take this analysis with a grain of salt as I'm not as familiar with the hardware renderer and thus may be reading the numbers wrong. When I looked at the latest rendertimes stats for Frozen Time it seemed like more than half the time was spent in the two first stages: collect visible sectors and lines (BSP clip to figure out what the draw lists should be) and then convert each draw list entry into renderstate commands.

The draw list entry processing step is in theory very easy to parallelize - there are no dependencies between the entries except that each draw emitted to renderstate should execute in that order when submitted to the GPU. If there are N CPU threads, split the list into N parts and have each thread process totalsize/N of the entries. Create a renderstate object for each thread, that will generate N command buffers. When all threads finished submit the buffers. Order is thus maintained.

What I just described has the problem that unless BSP clipping is extremely fast we can't begin processing draw list entries until the entire list has been generated. As core count increases the BSP clip will become the dominant bottleneck. The only way I know that can parallelize the BSP clipping is to split the field of view into parts (like I did with r_scene_multithreaded). Most extreme variant is a ray for each column of pixels.

Doing this on the GPU is trivial if the input data can be uploaded to storage buffers (like the shadowmap pass is doing). The catch is that each clipping region will have duplicates of subsectors that other clipping regions also saw. I think it may be possible to also use the GPU to merge the result of the initial clipping into one combined output. That can then be downloaded from the GPU and the engine would have its draw list.

Or better yet, the GPU could process the draw lists itself. If the data needed by draw list entry analysis code also was put in storage buffers the GPU could just do the work itself. Then that result could be downloaded. And so on.

So what does all this have to do with the render hacks or other things? Well, the more complex the original data structures are, and the more complex the rules for analysis become, the harder it will be to put this into storage buffers and shaders. That's why I think it affects more than just the playsim.

[Graf Zahl]

Your analysis is mostly correct.

Currently it works so that the internal draw lists are created in a parallel thread to the BSP traverser, which already shaves off quite a bit of time. And surely, processing the draw lists into render commands in parallel is the next step on the list.
But to simplify the BSP I don't think that throwing ever more horsepower at it is the solution. What should be done instead is to cut out static sections of the map, turn them into isolated meshes and remove their content from the BSP and thus reduce the workload of traversing the BSP and several of the follow-up steps. And here's where the dynamic nature of the maps bites us in the ass, because it's virtually impossible to detect static map parts with all the options ZDoom has to offer to manipulate linedefs and sectors.

[dpJudas]

I think such an approach will require that the engine can move things between the static and dynamic set. Or they will have to be marked static by the modder (this unfortunately means no existing map will get the speed advantage).

About detecting static map parts, I think this would have to be done by the code manipulating the linedefs and sectors. When something modifies a field on a sector/linedef it also has to inform the renderer in one way or another.

When I experimented with a static/dynamic set version it worked really well to have everything static at first and then move things to dynamic if they changed. The only catch is that it really needs to move things back into the static set if it stops changing. For most maps this didn't matter, but infamous Frozen Time lowers the most complex sector in the entire map somewhere near the end. That test renderer ran the map rather well until that happened.

[Gez]

The impact on the renderer from those hacks is minimal. The far, far bigger problem is that the map's geometry is not static so that every single linedef has to be processed for every single frame. This was introduced by ZDoom itself, actually, namely, the backside activation feature. Doom originally only had it for a few door types.

I don't think it's that much of a problem. There's not much qualitative difference between "a few" and "several". You can still have a rather simple analysis that goes "sector is dynamic if it has a tag or is backsector to a line with non-zero type" and that'll give you a way to split sectors between static and dynamic easily.

I'd be inclined to believe that the vanilla stairs and donut effects (which will affect untagged sectors without active linedefs) are more troublesome.

[Graf Zahl]

It's not that easy, because with scripting there's no simple way to determine in what way a sector can move, if you execute a stair action somewhere where the engine cannot easily autodetect it the whole thing would fall apart.

Without some mapping restrictions and mapper hints this cannot really work.

[Gez]

I'm echoing Enjay's sentiments about Doomworld, although I come at it from a fairly different perspective. But purism? Elitism? Zealotry? Definitely.

Case in point:
https://www.doomworld.com/forum/post/1987375

The Nightdive crew (which includes Kaiser, Quasar, and Edward850) get bashed because there are slight differences between Blood: Fresh Supply and vanilla. The fact the game engine had to be recreated without access to the original source code doesn't matter.

[Matt]

::throws literally all the boomer-baiting entitled-millennial memes at this whirled guy::

replicating all the functionality of a closed-source ancient software is hard.

[Arctangent]

Case in point:
https://www.doomworld.com/forum/post/1987375

The Nightdive crew (which includes Kaiser, Quasar, and Edward850) get bashed because there are slight differences between Blood: Fresh Supply and vanilla. The fact the game engine had to be recreated without access to the original source code doesn't matter.

The only point I'm really seeing here is that we should use SMIV as representative of us, despite the fact that it's blatantly obvious that nobody here but his lurking cronies are anything like him or even find what he does tolerable.

But hey, one of our worsts that everyone disagreed with was a racist suicide-baiter, so I guess ZDF is a sanctuary for racist suicide-baiters.

[leileilol]

Former engine dev here, can confirm experiences of "this changes nothing" first impressions tester feedback from having vanilla defaults in Engoo (when I didn't want to make my pretty featurecreep defaulted on, I instead made multiple presets to instantly pick to flip em all on or off for the lazy)

[Rachael]

The only point I'm really seeing here is that we should use SMIV as representative of us, despite the fact that it's blatantly obvious that nobody here but his lurking cronies are anything like him or even find what he does tolerable.

But hey, one of our worsts that everyone disagreed with was a racist suicide-baiter, so I guess ZDF is a sanctuary for racist suicide-baiters.

You do you, boo. Sgt Mark IV does not represent me. Anyone who believes he does is not worth my time.

[Arctangent]

You do you, boo. Sgt Mark IV does not represent me. Anyone who believes he does is not worth my time.

rip gez then

[Kinsie]

You, uh, you wanna take a mulligan on this one, Arctangent? Step back, think out your point, then try to present it in a way that doesn't confuse and/or mildly offend everyone?

[Arctangent]

You're gonna have to point out exactly where you find "I found a twat, therefore these people are all twats even though they're blatantly disagreeing with the twat" being not a great way to go about things confusing and / or mildly offensive, because I'm struggling to see where this is either convoluted or controversial.

This isn't exactly a hot take. Or a cold take. It's like, a glass-of-water-left-out-on-the-counter-for-five-hours temperature take.