I'm suffering really low framrates in gzdoom at some points, it's particularly noticeable in nuts, but also in some of the megawads I've been playing (map 27 of Slaughterfest 2012 for example, which has over 10K monsters).

The odd thing is for most levels I don't seem to have a problem.

System specs :

AMD FX-8120, 8GB RAM, AMD Radeon HD6850, Windows 7 64 bit.

The think is it used to run on my old system (also an AMD CPU, but with an Nvidia 8800GT graphics, though that was 32bit XP).

That's odd. I got a similar system, just a bit weaker and it runs super-fast. Overall it's correct, though, that ZDoom's play engine has problems with such large amounts of monsters. It has nothing to do with the renderer, though. There's something in the play code that's stealing the time.

Can it be that the latest drivers got messed up? I haven't updated mine for over a year now.

Some OpenGL drivers just aren't happy with all that sprite pushing, and the bottleneck might become OpenGL rendering itself. There was an old thread which showed how in timedemos of nuts-like levels, the software rendered version of ZDoom (and prBoom+) beat GZDoom and glBoom+ fair and square, sometimes even with a factor of 3:1 or more. Things might have changed since then, but it once was a valid point which might be worth considering. The very least, can the OP post a benchmark between ZDoom/GZDoom for the same level, same conditions? Perhaps with recording a timedemo.

Something one must always bear in mind with such a comparison is how efficiently elegant the vanilla software rendering algorithm is. Certainly there are some less than optimal areas, given particular video modes but for the most part it is very well optimized. The flat flooding algorithm, for example, will often outperform a GL solution which has to pump triangles through a general purpose rasterizer. It stands to reason that at certain resolutions and with specific map geometries, vanilla will outperform even highly optimized hardware GL renderers given a half-decent CPU. And thats not a "cop out".

DaniJ said:
Something one must always bear in mind with such a comparison is how efficiently elegant the vanilla software rendering algorithm is. Certainly there are some less than optimal areas, given particular video modes but for the most part it is very well optimized. The flat flooding algorithm, for example, will often outperform a GL solution which has to pump triangles through a general purpose rasterizer. It stands to reason that at certain resolutions and with specific map geometries, vanilla will outperform even highly optimized hardware GL renderers given a half-decent CPU. And thats not a "cop out".

I don't think that this has any merit these days. If you just create a vertex buffer for each sector and render it all in one go there's no triangle pushing left.

This isn't in GZDoom's release code but I once did some tests with it and it brought some nice speedup - the only problem being that it all becomes rather useless once dynamic lights come into the picture. Of course, even that may have changed with more modern hardware.

On my system at least GZDoom handily outperforms the software renderer on any maps I tested with so far.

FireFish said:
i suspect that a lot of OPENGL source ports for doom use 'direct rendering' which is never used for advanced graphics rendering by any modern up to date game company.

That's because direct mode is not adapted to the much higher level of complexity used by modern up to date games. For relatively simple geometry like the typical Doom level, the supposedly higher performances when rendering aren't enough to compensate the greater overhead. Graf experimented a bit with VBOs but it generally didn't give enough of a performance boost (in fact, it was even slower in some cases) to merit pursuing the renderer rewrite further.

it is kind of interesting to read that non stop cpu usage to stream all the 3D data to the graphics card, is faster for simple doom and doom 2 geometry instead of doing one big stream, and letting the card handle the rendering from there on.

The problem is simply that the CPU won't deliver enough data to make the GPU run at full load. It's sitting idle for most of the time. On modern hardware GZDoom is strictly CPU bound so obviously any approach that requires more CPU power will be slower.

Of couse my tests were made 5 years ago and the approach I used wasn't the best so some slight speedup is certainly doable. But since most of the time is not spent rendering but processing the data on the CPU side (i.e. tasks that'd still have to be done when using vertex buffers) there's only little room to gain.

With complex enough map geometries, just performing the standard Doom's BSP traversal at each tic can become a significant portion of the total used CPU time. Adapting the visuals to OpenGL on top of that certainly isn't cost-free, and there's a "break even" point above which you lose just as much if not more by going OpenGL/3D than if you just left everything software rendered. And that's without counting enemy logic and visible sprites...

Maes said:
and there's a "break even" point above which you lose just as much if not more by going OpenGL/3D than if you just left everything software rendered. And that's without counting enemy logic and visible sprites...

Sorry, but here I disagree. I've yet to see a map that renders slower on GZDoom with hardware rendering than on ZDoom on my machine, unless some weird hacks (like the skybox windows in Super Sonic Doom) are used.

About the BSP traversal you are correct, of course. Streamlining the renderer may help on AMD cards, though, because they spend a lot more time inside the GL driver but on NVidia the maximum possible speedup would be around 10-15% maybe, because that's normally the time being spent in the actual code that transfers the data to the driver - and even most of that can't just be omitted, it just has to manage the vertex buffer and upload that later.

doomguy93 said:
Nuts.wad will not run properly on either zdoom, gzdoom, skulltag, or zandronum. It is meant to be run on Boom.

I think this only applied to old versions of ZDoom. E.g. ZDaemon can handle survival maps with monster hordes just fine (unless they really overdo it, like maps with multiple Icon of Sin spawners that get to 20000+ monsters in a few seconds)

Even some version of prBoom+ couldn't handle it well, which turned out to be a MBF feature (something about "friend aid" or somesuch) which caused an O(n^2) degeneration of the gameplay code. Ironically, simpler sourceports without MBF features just require a linear increase in CPU power to handle an increased number of monsters (assuming other limits don't break first). E.g. I was surprised to find that Mocha Doom ran nuts.wad just as well as prBoom+, and significantly better than ZDoom and plain prBoom O_o

However, as soon as you turn on anything OpenGL or Direct3D, the tables might be reversed once more: in addition to the gameplay code itself, you add another potential bottleneck (the OpenGL pipeline). YMMV depending on rendering code, driver revision, OS and GPU, of course, but in general an improvement in performance is not a given in maps with extreme visuals. E.g. even if you can play nuts.wad in GZDoom "fine", I dare you to do it with full GL lights on....yup, not so great now, huh?