3D performance. Which port?

[johnfulgor]

Hello all,
I developed a relatively detailed level for gzdoom, using 3D floors, high-resolution textures, and dynamic lights. Unfortunately I experienced a performance degradation, which forced me to remove part of the map. Is there another game engine supporting hardware acceleration? In case yes (like I suspect), are their graphic performance noticeably different?
Thank you.
John

[Gez]

If you want 3D floors in your map, you have the choice between four different OpenGL renderers: EDGE, GZDoom, Vavoom, and Doom Legacy.

If you accept losing 3D floors, you can add Doomsday, Risen3D and GLBoom+.

Feel free to look here for more info.

[kristus]

Gez said:

If you accept losing 3D floors, you can add Doomsday, Risen3D and GLBoom+.

Risen3D has had 3d floors longer than GZdoom afaik.

[wesleyjohnson]

I would suspect that all the ports using SDL for their OpenGL are going to have the same performance. It depends more on your video card engine, which system you have, and how good the video card support is.
And if you get your video support working good (for an overly large wad), then half of your users will have it mediocre.

[Graf Zahl]

wesleyjohnson said:

I would suspect that all the ports using SDL for their OpenGL are going to have the same performance. It depends more on your video card engine, which system you have, and how good the video card support is.
And if you get your video support working good (for an overly large wad), then half of your users will have it mediocre.

You couldn't be more wrong. ;)

First, when it comes to OpenGL, SDL is nothing more than an encapsulation of the system specific stuff. GL is always used directly and SDL is not a performance factor

Also, even though the hardware is a major factor, another one is the algorithms used to process a level and how the geometry is sent to the hardware, nothing of which is in any way related to SDL or the hardware.

All tests so far show that GLBoom+ is the fastest GL renderer, followed by GZDoom. (The reason for GLBoom+ being faster is the lesser complexity of the supported features.)

All the others trail by a significant margin. One interesting thing I noticed is that the more data the engine tries to keep precalculated and cached, the worse the performance gets. CPU-cache misses are a very significant factor here.

[Megamur]

I always wonder why community-created programs never seem to run as well as retail releases. GZDoom seems to run worse than DOOM³ on my rig, which just boggles my mind. It doesn't look even as complex as GLQuake, so I don't get it.

[DaniJ]

It could have something to do with them being hobby projects. You don't honestly expect little one-or-two man development "teams" to compete toe-to-toe with their commercial counterparts, do you? Commercial game development teams are generally several orders of magnitude larger and spend 40+hrs a week doing it.

COD:MW (lets say) 100 developers working 40 hrs a week.
Doomsday 2 developers spending on average about 6 hrs a week.

COD:MW = 4000 man hours a week
Doomsday = 12 man hours a week

[sirjuddington]

It's also because the way doom works isn't at all optimal for 3d accelerated graphics.

[Xaser]

SlayeR said:

It's also because the way doom works isn't at all optimal for 3d accelerated graphics.

This. Doom's rendering engine is still Doom's rendering engine, whether it be in GL or software. Its methods simply aren't optimized for the kind of detail we see in today's games.

[Graf Zahl]

Not to mention that several modern Doom levels (like KDiZD) are magnitudes larger than what modern games have to offer.

It just adds up and the inability to optimize the rendering sure doesn't help.

Anyway, I have no problems playing such maps with 100 fps in GZDoom at 1280x1024 on a 3.5 year old system with a relatively underpowered Geforce 8600.

[ReFracture]

Performance problems in Doom ceased for me in most things when I got a new system back in 2007, which was the first computer I had that was fast enough to play Doom 3 or Half-Life 2 smoothly at high settings.

And yeah, GLBoom+ is fast, it's the only engine out there that you can actually start a game of nuts.wad on map01 and not have it turn into a slide show (unless you put it on nightmare).

But that's an extreme example.. there isn't anything else at all that I play Doom related that is too complex or full of too many monsters for GZDoom to play smoothly.

[Megamur]

Graf Zahl said:

Not to mention that several modern Doom levels (like KDiZD) are magnitudes larger than what modern games have to offer.

I contest that. HL2 had pretty big maps. Heck, even DOOM³'s maps weren't tiny, and games like Far Cry, Crysis and S.T.A.L.K.E.R. are just massive in general. And even if the amount of area that can be ran through is smaller than in KDiZD maps, there's so much more detail in the architecture than the mostly-flat-surfaced, fake 3D layouts of DOOM maps. That doesn't really explain anything to me.

Maybe it's because it isn't true 3D? Maybe if DOOM were constructed out of real 3D polygons, graphics cards would be able to handle it much better.

[Graf Zahl]

The main factor is number of polygons - and that's considerably higher in large Doom maps due to the way the level has to be constructed.

Much of what can be seen in modern games actually has a lot less geometry than one may expect - and of course it is often much better optimized for modern hardware.

In large Doom maps you may easily end up with 20000+ draw calls and that's just not something that can be done without a performance hit.

[Maes]

Heh DOOM: the next GPGPU benchmark for the 21st century? That would get rid of some of the draw call overheads ;-)

[Graf Zahl]

Sadly, Doom is particularly ill suited for GPGPU.

The main problem is simply that the map geometry can change so you can't just create a static mesh that's efficient to handle. And since this all is on the game logic side, how could parallel processing help speed that up. You'd spend more time setting it all up than just drawing it.

[Spleen]

Graf Zahl said:

Sadly, Doom is particularly ill suited for GPGPU.

The main problem is simply that the map geometry can change so you can't just create a static mesh that's efficient to handle. And since this all is on the game logic side, how could parallel processing help speed that up. You'd spend more time setting it all up than just drawing it.

If one isn't worried about demo compatibility, would it be possible to parallelize the computationally intensive parts of the game logic itself? Not the whole thing, just the few functions that eat up the most clock cycles.

[esselfortium]

Graf Zahl said:

The main problem is simply that the map geometry can change so you can't just create a static mesh that's efficient to handle.

This is an interesting possibility that never occurred to me before you mentioned it. Would it be possible to detect doors and other movable structures, and keep them separate while creating a static mesh of all the rest of the map?

[Megamur]

Awesome. Now the people that actually know something about how game engines work (i.e., not me) are starting to think this stuff through. :)

[chungy]

This conversation comes up quite a few times over the years :P

[DaniJ]

esselfortium said:

This is an interesting possibility that never occurred to me before you mentioned it. Would it be possible to detect doors and other movable structures, and keep them separate while creating a static mesh of all the rest of the map?

Short answer: Not easily because you cannot predict the outcome.

Long answer:
In DOOM, pretty much all line special logic is designed such that effects are dependent upon the current world state at the time the special is executed. For example, one special may lower a floor in one sector and consequently any door specials that use a relative height offset will have a different outcome than if the door is opened before the floor is lowered.

This behavior means that it is not possible to pre-simulate.

However, it would be possible to re-run the logic after each world geometry change. The problem is that some maps are so dynamic that this process would likely cause even more performance problems than simply assuming all geometry can change at any time.

[hawkwind]

Graf Zahl said:

All tests so far show that GLBoom+ is the fastest GL renderer, followed by GZDoom.

According to my tests, yes glboom+ is the fastest. I found on my system running nuts.wad without all the eye-candy and both 800x600 in windowed mode that I got 18fps with risen3d and 12fps with gzdoom. A 50% increase with risen3d.

[Gez]

The bottleneck in Nuts is not so much the rendering as the AI processing.

[Graf Zahl]

DaniJ said:

However, it would be possible to re-run the logic after each world geometry change. The problem is that some maps are so dynamic that this process would likely cause even more performance problems than simply assuming all geometry can change at any time.

That's precisely the results I got when trying it out. Even just caching the intermediate data GZDoom creates each frame causes so many cache misses that it's slower than just recalculating it each frame.

And ZDoom's features make it even harder to determine if a sector is static or not so you end up with even more overhead.

hawkwind said:

According to my tests, yes glboom+ is the fastest. I found on my system running nuts.wad without all the eye-candy and both 800x600 in windowed mode that I got 18fps with risen3d and 12fps with gzdoom. A 50% increase with risen3d.

What Gez said. If you want a real rendering performance stress test, load MAP09 of Hellcore 2 and climb on the steeple from where you can look across the whole town. For plain Doom features performance this is probably the best you can get.

[entryway]

Gez said:

The bottleneck in Nuts is not so much the rendering as the AI processing.

Did you try to understand why zdoom is so slow after awakening all monsters in comparison with prboom? 150+ fps vs 4 fps. Is it related to "monster over monster" ability or what?

[Graf Zahl]

No idea which code makes it so slow. Someone would have to take out a profiler and check where it spends all this time.

[hawkwind]

Graf Zahl said:

If you want a real rendering performance stress test, load MAP09 of Hellcore 2 and climb on the steeple from where you can look across the whole town.

Now that was interesting. In this instance I got 29-30fps for gzdoom and 23-24fps for risen3d.

... while at it, when I typed idbeholdl, instead of going fullbright, the screen had a green tinge to it. Is this a bug or intentional ? zdoom does not have this problem.

[Edward850]

It's intentional. If you want to disable it, go to display options -> OpenGL options -> preferences and switch off 'Enhanced night vision mode'.

[Graf Zahl]

hawkwind said:

Now that was interesting. In this instance I got 29-30fps for gzdoom and 23-24fps for risen3d.

What's your hardware specs?

I get 67 fps on that scene with GZDoom and 72 fps with GLBoom+ on a Geforce 9600GT, 1280x1024 on a first generation 2.4 GHz Core Quad.

Anyway, looks like Risen3D is quite good performance wise.
I get 19 fps with EDGE and 9 fps with Doomsday 1.8.6 on that scene (all enhanced features switched off.)

[entryway]

Graf Zahl said:

No idea which code makes it so slow. Someone would have to take out a profiler and check where it spends all this time.

glboom-plus:
http://prboom-plus.sf.net/glboom_nuts_vtune.png

gzdoom:
http://prboom-plus.sf.net/gzdoom_nuts_vtune.png

FBlockThingsIterator::Next
http://prboom-plus.sf.net/gzdoom_nuts_vtune_01.png
http://prboom-plus.sf.net/gzdoom_nuts_vtune_02.png

[Maes]

hawkwind said:

According to my tests, yes glboom+ is the fastest. I found on my system running nuts.wad without all the eye-candy and both 800x600 in windowed mode that I got 18fps with risen3d and 12fps with gzdoom. A 50% increase with risen3d.

Actually, in maps like nuts.wad other things such as extra actors code and possible O(n^2) degenerations are involved. Even glboom+/prboom+ can go VERY slow on nuts.wad if you have MBF's "help friend" option on.

Other that that, sprite drawing overhead can be significant, but seeing how even MochaDoom can handle nuts-wad like scenes (where only drawing is involved), and how most ports slow down once you wake the monsters up, there is a trend inversion causing most of the time to be spent in the logic than in the rendering.