Performance overhead for running boom maps in zdoom?

[dpJudas]

Do you really think it's a good idea to add limiters to the renderer that cater to this type of map?
Let 'em crawl! I don't care about such crap.

I mainly added it because its standard practice in modern games to hide objects of this sort once the distance is great enough and thus figured it wouldn't do much harm. I'll remove it again once I've improved the DrawSegmentGroup handling.

@drfrag: You should be able to do the change in ZDoom in a couple of lines too, although I can't remember the exact spot. It is at a place that looks somewhat similar to the code that I changed.

[invictius]

Segmentation violation is somewhat odd for 32 bit code...

Anyway, it may just be that the zone heap is too small. Most modern ports either ditched that piece or if it got filled, allocate more memory from the system. Any port not doing that will abort if some map needs more than 8 or 16 MB, depending on what it is set to.

Although the errors you're seeing are TEXTURE1 related, Ancient Aliens will NOT run in mbf.exe as it's maps are built with ZDBSP extended nodes.



I have no interest in supporting a legacy port like MBF - modern, maintained alternatives such as ZDoom, Zandronum, prboom-plus, and Eternity all run Ancient Aliens without issue.

Now I just have to find a version of eternity or prboom-plus that will both run on ME and support zdsp extended nodes...

[drfrag]

You should be able to do the change in ZDoom in a couple of lines too, although I can't remember the exact spot.

It's done (r_things.cpp) and was pretty easy since there is another distance check somewhere else. As expected has a massive impact on performance here (10 year old machine), fps went from 1 to 10 (600 vs 100 ms). Now i'm going to add a menu option with three settings. Thanks.
However it won't help with nuts.wad, as soon as i shoot the game freezes (less than 1 fps), that doesn't happen on prboom-plus and i don't know why.

Is this the real Lee Killough?
http://www.vogons.org/viewtopic.php?f=2 ... 20#p594574

[Graf Zahl]

Nuts brings out the worst in ZDoom's far more complex AI code. Just compare PrBoom's A_Chase with ZDoom's.

[invictius]

Where can I get old versions of risen3d? I'm trying to run eternity on ME but can't find an old enough version. From my testing, it seems that complex boom maps run fine on a high-end pentium 2, because sunlust does (at least in dos). I know Ancient Aliens will work on a p4 fine, just need to somehow test on a p3.

[drfrag]

Nuts brings out the worst in ZDoom's far more complex AI code. Just compare PrBoom's A_Chase with ZDoom's.

I see, it's fine then.

On the sprite culling, this is what i did:
Sprite Cull Distance -> Close=2000.0, Medium=3500.0, Far=5000.0 (default), Infinite=0.0. It would be safe to use medium as the default but doesn't make much of a difference. You can't hit monsters farther than 2000 units with hitscan weapons.

[Nash]

What is it with Doom modders and their need to create maps where every single line in the entire map is visible?

I see what you did with the sprite draw distance, but would such a thing be possible for lines too? eg lines that are too far from the camera are simply not drawn. I imagine they still need to be processed though (for LOS checks from monsters and things like that) ...

*I am not a graphics programmer and I know nothing about how the Doom renderer works (despite being here all these years; I know :/) so bare that in mind.

[dpJudas]

I see what you did with the sprite draw distance, but would such a thing be possible for lines too? eg lines that are too far from the camera are simply not drawn. I imagine they still need to be processed though (for LOS checks from monsters and things like that) ...

Short answer is, yes, such a thing is possible.

Long answer: There are generally three ways modern game engines treat things in the distance: 1) stop drawing it, possibly using fog, 2) use a lower level-of-detail mesh, 3) billboard it. Most games use all three methods.

Method #1 is by far the easiest to implement, but has the drawback that you can't do large structures in the distance.

Method #2 requires a lower detail version of the map mesh. It also requires safe transition points between the high level mesh and the lower level so that there won't be gaps where it switches from high to low detail. Theoretically this could be done in Doom, but its somewhat difficult because you not only needs to generate a lower level detail mesh, you also need to keep it up to date when textures, light, or sector heights change.

Method #3 works well for stuff like trees and other "thing" 3D models, but cannot really be done for a full map mesh.

[Graf Zahl]

Per-wall processing costs a lot less than per-sprite processing, plus this needs some alternative to not have it look like shit. In this case it's unlikely that much will be gained.

Seriously, if you need to cull sprites for performance there's already to many to begin with. Just have a look at BoA!

[dpJudas]

Per-wall processing costs a lot less than per-sprite processing, plus this needs some alternative to not have it look like shit. In this case it's unlikely that much will be gained.

Seriously, if you need to cull sprites for performance there's already to many to begin with. Just have a look at BoA!

About 50% of the software renderer is spent on lines and 50% on the sprites (for this particular map). Obviously this hints there's a huge performance issue with the sprite and particle processing, but it also means that you won't get more than 40-50 fps even if you made drawing the sprites completely free.

Btw., I'm not saying this should be implemented - just that it is theoretically possible.

[Graf Zahl]

The engine shouldn't be optimized for maps that use an approach that's this wrong. And although I like using Frozen Time for benchmarking I know fully well it's a complete outlier and not representative for what people normally play.

I'm far more concerned with BoA which is pushing the thinker loop beyond its limits. If it ends up with 7ms think time on my system that's simply too much. This is the biggest performance bottleneck in my book, not trying to render badly designed maps that defeat the clipper.

[dpJudas]

I generally agree with you on that, which is why my goal at the moment is just to fix the crime that the sprite rendering consumes so much of the total render time.

However, if a Doom engine could one day do a level-of-detail system it would unlock the ability to create large outdoor scenes. The fact that a lot of modders are attempting to do this is a clear sign that it is a desired feature, even if we have no known working solution that can provide this.

[Graf Zahl]

Sure, but the proper solution should be to split the BSP differently so that the contents of such open areas do not need to be split at every single linedef - at least with OpenGL. Most of the time spent in here is due to BSP traversal. For the software renderer such setups are utter poison, though.

[Nash]

However, if a Doom engine could one day do a level-of-detail system it would unlock the ability to create large outdoor scenes. The fact that a lot of modders are attempting to do this is a clear sign that it is a desired feature, even if we have no known working solution that can provide this.

Sure, but the proper solution should be to split the BSP differently so that the contents of such open areas do not need to be split at every single linedef - at least with OpenGL. Most of the time spent in here is due to BSP traversal. For the software renderer such setups are utter poison, though.

That would be nice if it could happen some day. I am even willing to accept any tradeoffs for such constructs (like, for example, if the map can't be as dynamic as fully-rendered maps... or distance fog, or no software rendere support, or whatever). And no, I'm not excited nor am I expecting this to happen. :P

[drfrag]

Where can I get old versions of risen3d? I'm trying to run eternity on ME but can't find an old enough version.

You could try an older version of eternity from here:
http://eternity.mancubus.net/ee-old/

There's also a more recent dos version by hail-to-the-rayzen:
http://www.vogons.org/viewtopic.php?f=5 ... 80#p590945

On culling of far linedefs i remember distant walls dissapearing in Doom, may be an old port already implemented this (doomlegacy?). Or am i just imagining things?
Wide open outdoor areas are pretty rare in Doom anyway, i would be happy to backport method 1 to ZDoom32 or LE (disabled by default), it's some sort of low detail mode after all.