UZDoom 5.0.0 Pre-release

[Ultimate Freedoomer]

Any chance we might see multicore rendering added down the line? VKDoom & Rum-&-Raisin Doom could be used as a reference for the code for it, & it would help the lag issues that the OpenGL & Vulkan renderers have

GZDoom already used multiple threads for what it could (i.e. BSP traversal) in the hardware renderer. Any more is not possible at all with OpenGL due to its very poor design and would require UZDoom to go Vulkan-only.

Can you elaborate on the "very poor design" thing with OpenGL? I was under the impression Rum & Raisin Doom had a proper multicore OpenGL renderer

[edward850]

You seem to be very confused about something. If Rum & Raisin is famous for anything, it's explicitly its multithreaded software renderer. Certainly not OpenGL or Vulkan.

[Ultimate Freedoomer]

It didn’t say either way on the git repository, so I just assumed. But what are the design issues with OpenGL interfering with multithreading it?

[Chris]

It didn’t say either way on the git repository, so I just assumed. But what are the design issues with OpenGL interfering with multithreading it?

OpenGL works by sending commands to a renderer context, and that context is specified on a per-thread basis. So you do like

Code: Select all

glXMakeContextCurrent(..., context);
// Run commands on the above context:
glCommand1(...);
glCommand2(...);
...etc...

A given context can't be made current on two threads simultaneously, and there's a cost to continually reset the current context. While you could use multiple threads internally to figure out what to do, only a single thread at a time can really make the actual OpenGL calls to tell the hardware what to do.

[Ultimate Freedoomer]

& that last detail is the real hurdle with multicore OpenGL?

[edward850]

OpenGL isn't capable of doing multithreaded rendering, no. But by in large it's not really the main bottleneck anyway.

[shino1]

I tried to make UZDoom load a wad from the iwads folder OR the home folder as default, and neither option worked as long as i_searchdistributors was set to "true". The program always defaulted to using the Doom 2 Unity wad or the Doom 2 BFG iwad regardless of what I did. I think that behavior would be understandable if there WAS no wad in the iwads folder, or the 'defaultiwad' option wasn't set, but *overriding* user preference just because they have a game installed seems excessive.

[Rachael]

& that last detail is the real hurdle with multicore OpenGL?

There seems to be some confusion here. A multi-core renderer is not going to magically fix lag problems, anyhow. There are a lot of moving parts and none of what is happening is magic at all.

If you are playing using a heavy mod or a mapset that uses heavy detail (or both), making the renderer multi-core is not going to suddenly make that playable. To do that, you would have to figure out where the actual chokepoints lie, and address those problems. For example: If you are using one of the famous Brutal mods whose authors like to blame engine developers for performance issues - having 200,000 blood actors on the screen is going to tank your FPS no matter what you do on the engine to try and fix it. In that case, the problem is not the engine, it is the 200,000 blood actors, and no engine in existence can run that at a proper frame rate. Or, if there's only 20 actors on the screen but each of those actors run 100,000 iterations per loop in each of their ticks - that will also tank FPS. Even worse is if they do that off-screen whether they are active or not.

If however, the problem is the 200,000 linedef maps that keep getting released, that will also never be playable on a BSP-walking engine, at least not in the high detail outdoor areas. (Both Eviternity and many Tormentor667 maps are absolutely notorious for this, but there's many other examples of this as well) And in that case, the problem is not as simple as ditching the BSP walk entirely - even though that is part of the solution, but then what happens after that? You still need to figure out what to do in an engine that allows for any sector arbitrary movement at any time. If it were so easy, it would have been done a long time ago, probably even before Vulkan ever got released. (Yes, Helion did do it, but it's in C# so it's impossible to "just" borrow that code, and notice how it took a full 26 years since Doom's release before that ever even materialized)

Sometimes the problem might even be the system itself, it might just not be up to the task of rendering all of that. Computers tend to go obsolete very quickly, unfortunately. And what you are running for your CPU, your GPU, your RAM, and the relevant drivers, also really matter. Doom might be a 1993 game, but today's source ports are hundreds if not thousands of times bigger than that and require that much more computational power to run.

TL;DR: It's not that simple, and there's never going to be a silver bullet to solve all your issues. Magic is not real. If you are having performance issues, being clear about where and how and what you are playing would help to narrow that down. In order to actually fix it, you would have to find the low hanging fruit and fix that first. Honesty is also important here - I am not saying you'd be prone to doing this, but a lot of people try and obscure what actual mods they are using when asking for help, or may even lie about their system specs, both of which will ultimately leave their problem unable to be solved.

[Redneckerz]

& that last detail is the real hurdle with multicore OpenGL?

If you really want to go multicore without breaking any Doomism's, you would have to require to rewrite the entire rendering system that makes Doom, well, Doom, and THEN make that renderer practically behave as Doom's original renderloop.

There is a reason it took years for Helion to get where it is at because that's what they did: There is no BSP traversal here, its all on the GPU. And in order to do that, well..

This is something UZDoom simply cannot do because it has its own feature set and its own set of intricacies that needs to be supported. Reversely, Helion doesn't support UZDoom's feature set (nor does it claim to). Helion is more akin to Ironwail and UZDoom is more akin to Darkplaces (Although the latter is not the best technical comparison, its the easiest to name in terms of visuals)

With that said, i am glad UZDoom is getting picked up upon by independent games as their engine of choice.

[Ultimate Freedoomer]

The reason I brought it up is because the OpenGL ES renderer doesn’t seem to have lag issues like that, no matter how intricate or performance-heavy the mod is.

[Rachael]

All 3 of the renderers use the exact same render path, so that is a very clear indication that it is the strength of your GPU that is at play here.

If you must use the other renderers, you can use the display scaling to reduce your resolution and that will increase your FPS - but even that has its limits. In the main 2 modes there's different vertex shaders running also, probably won't impact anything but if you have a lot of bone-anim models it could.

[phantombeta]

The reason I brought it up is because the OpenGL ES renderer doesn’t seem to have lag issues like that, no matter how intricate or performance-heavy the mod is.

The OpenGL ES renderer "doesn't have lag issues like that" because it supports a tiny amount of the features G/UZDoom has. The code that sets up rendering for walls and sprites is hugely expensive, and that gets even more expensive once you throw in things like dynamic lights.
All the rendering features G/UZDoom supports take a lot of branching and CPU cycles to handle in the renderer, and the sheer size of the Actor class does not help at all. (It's over 1KB for each actor, and that means you'll get a LOT of cache misses in the renderer, constantly!)

Case in point: Nuts.wad's bad performance in U/GZDoom (at least with a CPU and GPU that aren't horribly underpowered nor made over 15 years ago) is largely the rendering- on my computer, if I turn off dynamic lights and disable sprite rendering with gl_render_things false, the framerate goes from an unplayable slideshow to being rock solid at 60 FPS, ~200 if I turn off VSync. (though a bit stuttery due to some tics taking too long)

[Boondorl]

Mouse sensitivity sliders do not react to Left arrow, so with arrow keys it is impossible to decrease the mouse sensitivity, only increase it (Right arrow does work). The only way to decrease mouse sensitivity is to press Enter and input the desired sensitivity in digits.

Good catch, seems like it does work but for some reason the scaling on the number isn't 1:1. If you hold it long enough it does seem to ramp back down.

[Ultimate Freedoomer]

All 3 of the renderers use the exact same render path, so that is a very clear indication that it is the strength of your GPU that is at play here.

If you must use the other renderers, you can use the display scaling to reduce your resolution and that will increase your FPS - but even that has its limits. In the main 2 modes there's different vertex shaders running also, probably won't impact anything but if you have a lot of bone-anim models it could.

my GPU is an Nvidia RTX 2080 ti, if that helps

[Boondorl]

To put an end to the rendering debate here, the problem is multi-faceted:

• The BSP is still traversed linearly. While it uses its own thread separate from the thread generating the level data, it's still a single thread. The current setup makes it basically impossible to multithread without the level data having been already generated. VKDoom could do this because it used the level mesh from the raytracing struct to traverse, but that was Vulkan exclusive and used a new renderer meaning it cannot be backported as-is.
• The sprite rendering code is just not good. It seems to consume a ton of time and large maps tend to have a lot of sprites visible at once, making it a double whammy of the CPU getting bogged down.
• Some of this boils down to the way the Vulkan renderer is set up. It's designed to use a similar pipeline to OpenGL, but OpenGL and Vulkan don't play nicely together. This is because the way Vulkan expects commands to be built and sent over is entirely different than the way OpenGL does. This would require more or less a full rewrite of the Vulkan renderer which would make supporting both significantly harder going into the future; any feature would require targeting two completely different renderers in their design.
• GLES disables shaders almost entirely. It's an extremely cut down version of the renderer designed for the lowest tier hardware. It will likely break quite a few mods visually, so it's only recommended if you absolutely must use it.

There are paths forward to improve the renderer and we're interested in them; this isn't an unsolvable problem. But we also have no renderer architect contributing at the moment nor would we have a goal for what the end result should look like. We're going to have to put a ton of legwork into learning this ourselves first which comes down to the ultimate equalizer: time. Most of us either don't have the time or are focused on other core parts of the engine that are equally in disrepair.