Elementalism, an ambitious GZDoom mapset, Phase 1 out now!

[Graf Zahl]

The original Crysis had framerate issues because they coded the game for a mythical 6 Ghz CPU instead of multi-threading, and terrible unfixable performance was the result. Gzdoom is the same. At some point, modders will completely break gzdoom, if they aren't already pushing it now.

The engine is going to have to implement better culling and multithreading to continue supporting all these high end mods. That or modders will have to quit making them, or use performance workaround hacks. It's not feasible to continue pushing the envelope any further with such limitations.

Hell, if they can't multithread, maybe do the reverse like that TempleOS guy did, where he combined multiple cores to compute a single task. I dunno, anything is better than the current way of ignoring performance optimization while increasing features that tax the engine.

Well, how about to shut up? If you have complaints, you should at least show a hint of technical understanding.

It is very obvious that you have no *fucking clue* about the whole thing. The engine can only be as efficient as the maps being thrown at it and if maps get too large there is simply no way to keep up. Doom is very hard to optimize because there is no static mesh that can be used to reduce the workload. You have to recreate everything each frame because it may have changed. If you precalculate stuff you have to recheck it anyway because it may no longer be the same.

Also your ideas about multithreading clearly show that you do not know how this stuff works. The renderer already uses two threads, but you need to have transition points where they can exchange their data so that they won't block each other.

If you want a fully multithreaded renderer you need a different game design. Doom won't cut it, especially when you try to render wide open maps with 15000+ elements.
Yes, it could be made faster, if I could ditch OpenGL and do a total rewrite of the renderer to make full use of Vulkan. But here's the thing: This would *exactly* shut out those people on systems that have performance issues and mainly help those with fast, powerful computers where this mod already runs at stable 60 fps.

Also, if you so desperate to get this stuff, how about financing it? The devs here have to make a living, too, and GZDoom does not pay that. So it will inevitably get lower priority.

[DefectiveByDesign]

It is very obvious that you have no *fucking clue* about the whole thing. The engine can only be as efficient as the maps being thrown at it and if maps get too large there is simply no way to keep up. Doom is very hard to optimize because there is no static mesh that can be used to reduce the workload. You have to recreate everything each frame because it may have changed. If you precalculate stuff you have to recheck it anyway because it may no longer be the same.

Also your ideas about multithreading clearly show that you do not know how this stuff works. The renderer already uses two threads, but you need to have transition points where they can exchange their data so that they won't block each other.

If you want a fully multithreaded renderer you need a different game design. Doom won't cut it, especially when you try to render wide open maps with 15000+ elements.
Yes, it could be made faster, if I could ditch OpenGL and do a total rewrite of the renderer to make full use of Vulkan. But here's the thing: This would *exactly* shut out those people on systems that have performance issues and mainly help those with fast, powerful computers where this mod already runs at stable 60 fps.

Also, if you so desperate to get this stuff, how about financing it? The devs here have to make a living, too, and GZDoom does not pay that. So it will inevitably get lower priority.

Which is my point explained at a high level. The Doom engine isn't designed to handle 15000+ elements, so this creates an unfixable bottleneck. Unless there's some carmack level hack that can cull hidden surfaces from being processed, the only alternative is a completely new engine. Neither exists, so it's not possible. The only thing I disagree with is Vulkan, because every card that doesn't support it has been discontinued and has ridiculously low vram, like dx10 hardware or the old Kepler/Fermi cards. I don't think anyone is still using non-vulkan AMD hardware, as the VLIW hardware was never popular. There might still be a few windows 7 holdouts with old nvidia cards, but lack of security updates and feature support should have pushed people to upgrade by now. Not to mention, these people's CPUs are already too slow to play gzdoom mods.

I don't think pure vulkan will double framerate though, unless you somehow move map rendering to GPU compute, which might be the only way to solve the CPU problem, but even if you did this, it would still screw people on low end hardware. So there's really no answer to fixing performance, unless there was some map LOD system.

[Graf Zahl]

Which is my point explained at a high level. The Doom engine isn't designed to handle 15000+ elements, so this creates an unfixable bottleneck. Unless there's some carmack level hack that can cull hidden surfaces from being processed, the only alternative is a completely new engine.

The main issue with such maps is that in wide open areas there is no way to do visibility culling. Everything needs to be rendered in such places.

Neither exists, so it's not possible. The only thing I disagree with is Vulkan, because every card that doesn't support it has been discontinued and has ridiculously low vram, like dx10 hardware or the old Kepler/Fermi cards. I don't think anyone is still using non-vulkan AMD hardware, as the VLIW hardware was never popular. There might still be a few windows 7 holdouts with old nvidia cards, but lack of security updates and feature support should have pushed people to upgrade by now. Not to mention, these people's CPUs are already too slow to play gzdoom mods.

And yet, the last survey still showed 20% of holdouts running such old hardware. It is still too much to drop OpenGL. Most of these use Intel GPUs, btw.
Of course you are right, but in this community it'd be a fatal mistake to drop support now. Do not underestimate the people who play old games because they have old hardware.

I don't think pure vulkan will double framerate though, unless you somehow move map rendering to GPU compute, which might be the only way to solve the CPU problem, but even if you did this, it would still screw people on low end hardware. So there's really no answer to fixing performance, unless there was some map LOD system.

No, it won't double it - but with Vulkan I could split the scene in two halves and run two render instances in parallel. On CPUs with more cores I could even do 4 slices instead of 2. While it won't double the performance, it will definitely speed things up. But as long as OpenGL is the limiting factor here - not a chance. There's also the problem that the current Vulkan backend is not designed to do such a thing.

[Rachael]

We should also probably point out that, especially for this particular mapset, that rendering is not the only bottleneck here. In fact, Gez already said it:

Well, consider line of sight checks on a large open map...

This is something that is completely unfixable due to the way Doom was designed.

I dunno, anything is better than the current way of ignoring performance optimization while increasing features that tax the engine.

Hey, if you don't want new features, GZDoom 1.8.6 is still available. Have fun.

Or you can stop parroting shit other people who also don't know literally anything about the engine say, and actually do some technical research for once so you know what you're talking about, and avoid looking like a fool like you just did here. If you're going to make such claims - come with some evidence of it - *and* come with actual solutions (i.e. done by YOU) on how to fix it. (And not lazy ones like "stop merging pull requests huehuehuehue")

[DefectiveByDesign]

It's not about not having new features, it's about modders overpowering the engine with no warning how inefficient that is. Maybe have like a faq about how many elements can run acceptably. So some people can stick to performance guidelines, maybe use a HUB system to transfer between zones. That should lessen the performance impact of mega maps with extreme detail, without requiring things like a new vulkan renderer.

This whole feature thing is contradictory anyway. On one hand, we can't drop support for OpenGL, on the other hand, we promote mods that can't run acceptably on said hardware. Not to mention, this kind of invalidates LZDoom, which the whole premise is supporting old GL hardware, so it doesn't make sense to continue doing this with GZdoom. If GZdoom is going to be the high end mod port, then why not fully commit, and leave the OpenGL support to LZdoom?

Perhaps modders can be more efficient with maps, the problem is nobody is even thinking about it. Once you think about it, solutions will appear.

[Rachael]

Easier said than done. We've been pushing for lower linedef and monster counts in maps for years, but people are obsessed with pushing the limits to see what they can get away with - all in the name of art.

And I won't lie - yes, those maps do look beautiful - but they do perform terribly, none the less, and adding linedef after linedef after linedef after linedef is in large part to blame. The same happens with active (non-ambush) monsters as well.

In the end we simply can't force people to follow such guidelines. People will do what they do. Elementalism is a perfect example of a mapset that doesn't completely follow those guidelines - and the end result is very pretty. But yes, you do need a somewhat decent PC just to even run it with any acceptable performance.

But make no mistake - I do know first-hand that the mappers do care about performance because I have seen them talk about it. But they were definitely not going for full 60 FPS or bust in every scene - they were willing to accept lower values at some points - I don't know what their criteria were. It came with compromises either way.

[Graf Zahl]

It has always been like that. 20 years ago, mods like "Phobos: Anomaly Reborn" were pushing the engine beyond its limits, barely running with 30 fps on 800x600 in GZDoom. Other hardware rendering ports of that time ran it with 10 fps, though, or outright crashed on it.

The thing is, if a mapper does not care about good performance, you will get pretty looking maps that play like shit on anything but the most powerful systems around. Elementalism is not the first mod of this kind. In the past there were Frozen Time, and the one currently taking the crown for being unplayable due to its size is Ar Luminae.

The only way around this problem would be to change the mapping process to allow the engine to group some static, completely unchanging sectors into larger units so they can be rendered as one draw call - but this would be the total antithesis of how Doom mapping works and really does not mix with how Doom implements doors and lifts, etc.

[neoworm]

Problem of DooM community is that a very few people are actual game designers that do even know about optimalization and adapting to the limitations. Mindset i more is always better and if it doesn't work it's the fault of the engine.

[Enjay]

Yeah, I think, actually, this debate might be the wrong way around. The "problem" to my mind is more that some people are trying to make the engine do things that it isn't good at than the engine being flawed. Therefore, they have picked the wrong tool for the job. I fully understand why someone would stick with something that they know rather than learn a new engine for a particular mod, but if someone is forcing the game to do something that it doesn't and can't handle well, that's the fault of the modder, not the engine. Either redesign your project, pick another engine or accept that your project will run like a slide show.

So, in such a situation, it's not the engine that is flawed, it's rhe mod and it's unfair to blame the engine for poor mod design decisions.

[Graf Zahl]

The modders are only one side of the coin. Let's never forget the "This is Doom, it is supposed to run on my computer from 2009 without performance issues" attitude of the people not upgrading their computers.

On my new computer Elementalism runs fine, barely dropping below 60 fps.

[Enjay]

Agreed. However, that's still part of the equation that the modder has to consider. If they are happy with targeting their mod at a certain level of hardware (and no doubt putting up with the flak from people who can't run it on their toaster - "but it's Doom, it should run heuheuheu"), then that's fine and a valid decision.

FWIW I can detect some slow down in some places with Elementalism but at no point does it become unplayable (I don't think it drops below 40fps - at least not so I have noticed, and most of the time it is at my vsynced 60). It sounds like that's within the mod's intended parameters and that's fine.

[Graf Zahl]

According to its makers they shot for 30 fps on reasonably modern hardware, so this makes sense. It surely isn't worse than Blade of Agony.

[Enjay]

My machine is, I think, 5 years old now, but I did upgrade the memory and GPU last year. It was a pretty decent machine when I got it so it probably still qualifies as reasonably modern hardware. Certainly, I have no problems running Cyberpunk 2077 for a modern, but not particularly valid, comparison. I guess the performance I get with Elementalism is about right, perhaps even slightly better than anticipated.

[Bauul]

For what it's worth, we spent a huge amount of effort optimizing Elementalism as best we could. It is true for at least a couple of maps that they were designed with art in mind first, and then optimized later, but we still put considerable effort into ensuring the mapset ran acceptably before release. Our general guideline was it had to run at 35fps on my mid-range 2017 laptop (i5-7300HQ, GTX 1060 Max-Q, at 1080p with all the usual graphical effects turned on), and aside from a couple of specific places, it hits that consistently.

Some maps do definitely just about skim that though - Earth 4 being the most notable example. It's not unoptimized though: for example if you open the map editor you'll see large numbers of "void columns" and other site-blocking additions designed to decrease the number of rendered walls (we targeted a maximum of 10,000 rendered walls at any one time). There are also multiple trip-lines that close off parts of the map adding more sight-block lines as you move around. The first version of the map had no such LOS-blockers and ran considerably worse than the current version.

We also utilized a lot of geometry-to-model conversions. Models are significantly faster the render than sector geometry (in most cases), so any situation where there was significant amount of detail-only sector work we converted as much as possible to models. Fire 5 is a particularly notable example - the Boss encounter takes place in an arena that is one invisible 3D floor and a model, and nothing else. Thankfully due to the way dynamic lights mostly interact with a model in the same way as sectors means it's almost impossible to tell it isn't a full heavily-detailed level.

I completely appreciate Elementalism pushes the limits of "acceptable" GZDoom performance, but honestly for the scope and scale of what we achieved I feel the performance is pretty acceptable. And that also seems to be the general consensus based on what I've seen in streams and playthrough videos - yes it doesn't run as fast as Doom2.wad, but at least it's relatively clear on screen where that performance hit went.

[SaveTheDoomer]

So, a geforce 1060 should be the "minimum" requirement? I saw a 1060 3gb on amazon at 337 bucks... not bad And for 60 fps? I have a ryzen 2700, 4.1 Ghz on 1-2 threads.