GZDoom renderer questions

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

GZDoom renderer questions

Postby Darkcrafter » Sun Nov 15, 2020 5:00 am

Doom's clipper is 2D (BSP) and as far as I type "stat rendertimes" in the console I see the BSP taking the most time, starting with the value of 5.0 is where CPU bottlenecks my GPU that it's only around 15-20% loaded. Is there any workaround for this, let it be a really plain stupid feature like disabling any visibility check at all and rendering everything with huge overdraw starting with the distant objects and overlaying them on top of each other? I know I do the doom mapping wrong by building 3D structures in a huge sector but I really don't want to make them in the old way.
User avatar
Darkcrafter
 
Joined: 23 Sep 2017
Location: South Russia
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby Redneckerz » Sun Nov 15, 2020 8:48 am

I feel what you are describing adds a insane load of overhead by letting the engine do something it isn't built to do.

If you mean an optimized BSP/node compiler, well, there are options for that. But i don't think you are referencing that.
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)

Re: GZDoom renderer questions

Postby Darkcrafter » Sun Nov 15, 2020 8:59 am

I don't pretend I know something, that's why I asked about it here. If there are other better options then that's great.
User avatar
Darkcrafter
 
Joined: 23 Sep 2017
Location: South Russia
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby Graf Zahl » Sun Nov 15, 2020 8:59 am

What you suggest here will reduce some minor overhead with massive overhead. The only scenario where this would make things faster is maps like Frozen Time where you'd have to render everything anyway. On most larger maps this could slow things down to a crawl
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom renderer questions

Postby Darkcrafter » Sun Nov 15, 2020 9:06 am

Will be interesting to see what happens, especially on maps like those and if does enhance the situation with Frozen Time why not to make it an option for a map developer, like having a line in mapinfo?
User avatar
Darkcrafter
 
Joined: 23 Sep 2017
Location: South Russia
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby Graf Zahl » Sun Nov 15, 2020 9:39 am

Because it won't work.Aside from what I already wrote, the BSP traversal and the geometry preparation run in parallel threads. So even in the best case scenario the second thread will just be idle and you'd save no time at all.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom renderer questions

Postby Darkcrafter » Sun Nov 15, 2020 3:02 pm

At least it's done and it works, thank you for your work. I was specially waiting for someone else drop a word. I'd be glad to help but the only thing I made with C++ is that empty vst plugin in juce with visual studio when having a detailed help over voip - I forgot everything already :lol: . Btw, I tried to google: multithreading in unreal engine 4; apparently the situation there is like only the directly envolved game developers should mulithread the logics on their own, not sure about the renderer though. There are some videos on youtube with a few of presentations of game multithreading subject and just judging by them there are mountains of work to do and there are different approaches. Perhaps more people are needed?
User avatar
Darkcrafter
 
Joined: 23 Sep 2017
Location: South Russia
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby Graf Zahl » Sun Nov 15, 2020 4:45 pm

You cannot multithread Doom's game code or the BSP traversal. What I did was the only feasible way to parallelize parts of the render process in OpenGL.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom renderer questions

Postby Darkcrafter » Sun Nov 15, 2020 5:33 pm

You know it better. But here is a thing, why should it necessarily be Doom's code? There must be some way to recreate Doom mechanics, of course to some degree of accuracy. If we dive deep into the way Doom works there will be some nuances in how monsters work like they're assigned to RNG and that sort of things but honestly after playing this game for 18 years I got to admit there is no nuance I'd like to be reproduced, all the behaviour is all about finding a shortest path, not to fall down of a ledge, play a sound, shoot and die :)

If you place monsters in a huge space it becomes clear that their "AI" is nothing more than just that, the maps contribute a lot to guide them, the developers do such a posititioning at which monsters act the most effectively, this is the point at which modern games suck, that is why there are only locked down arenas filled with crowds and nothing happens in between them.

Here is an example of something out of this league: https://www.youtube.com/watch?v=_gfMeRaj3e8
I've posted this video before here and the reaction was like phew! :blergh: but I do too think it's not that good, yet who knows how far this project could be driven regarding the faithfullness to the original?

To me it looks like performance wise Doom's code scalability limit was reached, I keep on seeing threads here and there how their visually simple maps stutter with mods like brutal doom on a pretty beefy computer like having ryzen 9 3900x with gtx 1080. I explain to them that Doom was written with only 1 CPU thread in mind and it gets fully loaded even without mods but when brutal doom joins the discussion the matters get much worse.
User avatar
Darkcrafter
 
Joined: 23 Sep 2017
Location: South Russia
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby Rachael » Sun Nov 15, 2020 9:37 pm

If you could run Doom on a 386, you can run it just fine on modern systems. Brutal Doom is, and always has been, brutally bad with its code optimization - and this is something that's said repeatedly over and over by many different people, for good reason.

Ignoring that though, even if you were to perfect Brutal Doom to the point where there isn't one flaw or bug or bloat, and if the likewise happened for GZDoom, it still wouldn't run well, because one of the biggest problems with it is the utterly ridiculous amount of actors that it spawns. The thing is, each of these actors has *everything* it needs to become a full actor, such as a monster or a player, but instead all that extra memory is wasted on a single blood spray particle or splat, instead. Not to mention the amount of processing that it has to do since it has to process each of them one by one. Would a true multi-threaded simulation help? A little, but probably not as much as you'd think.

If you want to rewrite Doom's renderer and simulator from the ground-up, be my guest. All I can say is - good luck. If it were that easy, somebody would've done it by now already.

At any rate, I don't consider Brutal Doom relevant enough that it should constantly be on my radar. In fact, most of the time I don't even think about it. It has tons of fans, sure, and I don't fault them for liking it, and the unfortunate truth about human nature is that few are willing to go out of their comfort zone and explore things they haven't seen yet (i.e. NashGore, which if I understand correctly, Brutal Doom was built upon).

The fact is, even if the majority of users that use GZDoom play Brutal Doom (I don't know the actual numbers but I really would not be surprised if that were the case), GZDoom was not built for Brutal Doom and there always has been a great deal more to the engine than that. A single-track mind to focus on that mod would hold the engine back in such harmful and incalculable ways and just wouldn't be worth it in the long run. I would never go out of my way to intentionally break that mod, but at the same time I'm not going to go into a massive cold sweat panic if I do something which has the side effect of breaking it. It's still actively developed, it will survive one way or another without me helping it to do so.

So - generally - when GZDoom is loaded without mods like Brutal Doom, and with well-planned maps that don't show thousands of 2-sided linedefs on the screen at once - it runs perfectly fine and without issue. You push the engine to its limits though, and of course it's going to chug along, just like any engine would. I'm not saying it's perfect by any means - I'm just saying it's good enough for what it's meant to do and has been for a very long time.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby SanyaWaffles » Sun Nov 15, 2020 10:21 pm

I notice alot of people think GZDoom is horribly optimized but then they insist upon loading it with Brutal Doom, which is held together by duct tape, clown jizz, spaghetti and slurs that even a based gamer like me would cringe at. Then they load it with maps that have more detail than a painting of a bulge by someone who really likes bulges on top of that. Then they wonder why the engine cries.

I notice with my projects I probably need to scale back the gibs alot, it seems keeping the gibs just laying around causes severe lag at times. GZDoom, and most engines, are not meant to keep that many objects in memory. People forget that each object has a memory and thinker footprint. One way might be to have textured particles that can stay around indefinitely, but that might pose it's own problems.

Optimizing any game using any engine is important, and Brutal Doom failed to do that.

That, and coupled with my disdain with having to deal with people who can't handle me not supporting it... like there's more to the engine than just Brutal Doom. I can't deny it's influential, but there's more to it than just that project.
Last edited by SanyaWaffles on Mon Nov 16, 2020 3:40 am, edited 1 time in total.
User avatar
SanyaWaffles
Wouldn't be an epic gamer if I didn't commit a few war crimes.
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby Rachael » Sun Nov 15, 2020 10:34 pm

SanyaWaffles wrote:That, and coupled with my disdain with having to deal with people who can't handle me not supporting it... like there's more to the engine than just Brutal Doom. I can't deny it's influential, but there's more to it than just that project.

Exactly.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoom renderer questions

Postby Graf Zahl » Mon Nov 16, 2020 3:28 am

Regarding Brutal Doom - trying to optimize an engine for a poorly written mod that's pushing all the wrong button is the first step of becoming obsolete.
Actually, there's a lot such an approach has in common with supporting demo compatibility - while it may serve to solve the problem, it also erects so many obstacles that any sane future development is impeded.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom renderer questions

Postby Nash » Mon Nov 16, 2020 4:39 am

My headcannon to keep maps rendering as fast as possible is to limit each view to ~2000 walls (you can see this info with 'stats renderstats' console command). Anything beyond 2k walls and IMO a redesign should be considered because the engine simply isn't equipped to handle it.

This metric seems to work well on a very old computer I have (an i7 950 - a rig built in 2010).
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GZDoom renderer questions

Postby Graf Zahl » Mon Nov 16, 2020 4:56 am

That's overall a good approach - but with more modern systems 4000 would still be safe - beyond that you'll need a powerful CPU. Frozen Time goes up to 13000 and that's something where problems are inevitable, especially when so many of them are two-sided mid textures.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to General

Who is online

Users browsing this forum: Jimmy and 3 guests