Performance overhead for running boom maps in zdoom?

[invictius]

Almost put this in legacy discussion but it's still something that can happen in current builds - I was struggling to get 60fps using zdoom on ancient aliens in parts, at 4k, but Prboom managed much more than that. So is there a performance difference we can put in a rough percentage?

[Graf Zahl]

No. It depends on various factors - especially which part of the engine is causing the performance hit.
Which renderer were you using? Software or OpenGL? And what type of hardware?

[drfrag]

PrBoom is actually faster, i don't know if this is related but there's an important slowdown in maps with a lot of potentially visible sprites on ZDoom based engines.
It's been discussed @vogons, apparently THAT GUY is working on a solution but i don't know if he's trying to reinvent the wheel here. So what do you think?

http://www.vogons.org/viewtopic.php?f=2 ... 20#p592007

[dpJudas]

GZDoom's software renderer implements a fix for that particular issue. It does this by building a list of DrawSegmentGroup structures for every 100 draw segment with the total clipping for that range. It provides roughly a 100 times speed up for that particular loop.

You should be able to do the same for ZDoom, although with the globals involved it requires quite a bit of effort.

[invictius]

Anyone know why I'm getting this error for ancient aliens in mbf 2.04? I don't expect it to run, I just wanted to load it for low-performance shits and giggles.

[Graf Zahl]

Doom originally required to have patches cover all columns in multipatch textures. This restriction was lifted in more modern ports and they do not report this as an error. So apparently AA got some textures of this kind.

[Graf Zahl]

You should be able to do the same for ZDoom, although with the globals involved it requires quite a bit of effort.

Those globals surely have made lots of things unnecessarily hard. But wait: Wasn't *performance* the main driver behind keeping them...???

[dpJudas]

You should be able to do the same for ZDoom, although with the globals involved it requires quite a bit of effort.

Those globals surely have made lots of things unnecessarily hard. But wait: Wasn't *performance* the main driver behind keeping them...???

Randi could probably do this optimization in ZDoom, but there's no way I would have been able to until after the refactor.

I probably should spend a little time profiling the higher level part of the software renderer and see if there are other low hanging fruit. So far I've only ever spent time optimizing drawers and it was only by chance profiling Frozen Time I noticed the sprite inefficiency.

[invictius]

Doom originally required to have patches cover all columns in multipatch textures. This restriction was lifted in more modern ports and they do not report this as an error. So apparently AA got some textures of this kind.

Segmentation violation in some sunlust maps - again, simply not made with ancient ports in mind? (winmbf also)

[Graf Zahl]

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.

[drfrag]

GZDoom's software renderer implements a fix for that particular issue.

Have you actually tried Planisphere 2? Here GZDoom 3.0.1 is actually 'faster' than older versions, i get 4 fps instead of 1. The severe slowdown only happens when looking at certain directions. OpenGL is also 'fast', 4 fps as well.

I don't think i would be capable of implementing it with my basic C++ knowledge, an obvious solution would be checking for distance to the player (client) and discard sprites that are too far (after all only 128 sprites were drawn at a time in vanilla).
May be prboom used some trick (nuts.wad runs much faster), that code AFAIK is from original doom modified by Killough with some Randi's optimizations (// Scan drawsegs from end to start for obscuring segs in the old r_things.cpp).

https://www.doomworld.com/idgames/level ... r/planisf2

[dpJudas]

I'll take a look when I get home.

I did try a short test again of Frozen Time last night and there dynamic lights seemed to have a very nasty effect on the overall performance (outside of the drawers). I didn't run a profiler to figure out exactly what was so slow about processing dynamic lights, but I'll certainly do that when I get a little more time. Another thing was that the linear filtering checks spent a lot of time doing log2 calls, even in the situation where filtering and mipmapping wasn't enabled.

By the way, 4 fps instead of 1 is actually 4 times as fast. While that won't help much on that particular map, it would help a lot on other maps where they aren't THAT sluggish.

[dpJudas]

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

So the results I'm getting are as follows:

Frame: 74.0 ms (13 fps)
Walls: 34.8 ms
Planes: 4.5 ms
Masked: 25.0 ms
Drawers: 6.3 ms

Very Sleepy CS reports the main offenders as:

VisibleSprite::Render: 25% inclusive (11% by RenderDrawSegment::Render)
SWRenderLine::Render: 30% inclusive (22% by SWRenderLine::RenderWallSegment)

While the sprites drawing does seem to claim a significant part of the frame, it is actually drawing the two-sided lines that claims a lot of that time. And as usual with these complex maps, the drawers are not the problem.

Edit: culling all sprites further than 5000 units away (like suggested) does help a lot, almost doubling the frame rate. That gives about 22 fps instead. Turning on r_scene_multithreaded then brings it up to 50 fps.

Edit 2: after spending some more time researching this, it is pretty clear the problem is kind of the same as what my original DrawSegmentGroup fix solved. The main difference is that this time the sprites are up front with a bunch of draw segments in the rear, while in Frozen Time it was opposite with lots of draw segments in front and sprites in the back (from where I did my benchmarks). Good news is that it is possible to make it work in both directions by making certain changes to the function that draws the full set of sprites.

[Graf Zahl]

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.

[drfrag]

Edit: culling all sprites further than 5000 units away (like suggested) does help a lot, almost doubling the frame rate. That gives about 22 fps instead.

I actually find this interesting to backport it into ZDoom, with an option in the display menu. I think sprites very far away from the player cannot be seen anyway.