GZDoom 3.7.2 modern vs Zandronum 3.0

[Darkcrafter]

There was a post on one of brutal doom facebook groups that declared superiority of Zandronum on GZDoom. I tried to compare them to each other using Brutal Doom mod with my own maps that are in development now. Yeah, Zandronum was a bit faster but then something bad happened to the maps!

Here is the playlist: https://www.youtube.com/watch?v=NIQj9F4 ... nO&index=3

You can also see what the maps are intended to look and play like without "Brutal" word to them.

I found out that Zandronum doesn't support custom floor and ceiling slopes, has a limited 3d floors setup, lacks support for some line specials (you can't enter the cave at Jerkin Meat map), doesn't render stacked sectors (No I don't want to use an old thing based method there).

So it might be faster just because it doesn't render all of the geometry

[Dancso]

Zandronum is built on top of GZDoom and it has fallen behind by a lot so it's not surprising that Zan 3.0 runs worse as it's based on a relatively old version of GZDoom.

[Darkcrafter]

I don't like how some people produce a conclusion too quick. They didn't test the both ports good enough and kill for it by the way, in zandronum, dynamic sky box didn't work properly, it was still static it also lacks support for sloped 3d floors.

[Graf Zahl]

Zandronum may be faster on older hardware. Some of the more recent optimizations and extensions in GZDoom may not play nicely with outdated graphics cards. On a recent card that has full OpenGL 4.5 support it is very unlikely that Zandronum is faster, the two major optimizations that were done over the last year will make sure of that because they easily make up for the increased processing needed for certain other features.

The gist of it is, Zandronum is old, so its optimal target hardware is also that of a few years back, AFAIK it still contains the old OpenGL 2.x renderer. That means, it is missing the entire postprocessing chain - and this is what makes it faster on older hardware, but on the other side also means, it is missing tons of modern render features.

[Darkcrafter]

And that limits map design a lot. With amd hd 6770 I get 200FPS when playing old style doom maps without much fancy stuff. With brutal doom on regular maps in idle it's still 200FPS, when there are some monsters and lite fight it's around 150, when there is a lot of gibs, monsters and explosions it drops to 45. To me it's enough to stick with GZDoom. As you can see framerate drops significantly on big maps with literally big 3d floors

Is it like it renders any linedef even if they're not "seen"?

RenderingSchematics.png

In brutal doom it's 19FPS, without it it's 45.

Screenshot_Doom_20190301_121727.jpg

[TDRR]

I probably have posted this hundreds of times but, if you need performance then go with ZDoom LE or ZDoom32 instead of Zandronum. More stable, a bit faster, and many more features.

[Darkcrafter]

Thanks, I just checked it out. So far it has more features than zandronum but it lacks portals. With brutal doom on official '94 maps it's around 500+ FPS but when it comes to these maps it's only 1 fps of difference it also doesn't support stacked sectors. So I still stick to GZDoom.

[TDRR]

Thanks, I just checked it out. So far it has more features than zandronum but it lacks portals. With brutal doom on official '94 maps it's around 500+ FPS but when it comes to these maps it's only 1 fps of difference it also doesn't support stacked sectors. So I still stick to GZDoom.

I'm not sure if something is wrong in your end. ZDoom LE has perfectly well working stacked sectors here.

EDIT: Ah, you mean the line-portal based ones. ZDoom32 does have them, if you really want them.

I meant it as an alternative to Zandronum, not GZDoom.

[Arctangent]

Is it like it renders any linedef even if they're not "seen"?

Not just linedefs. The only real way that the engine knows that geometry shouldn't be drawn is if it's being blocked off by a single-sided line, since those will, by their very nature, always block absolutely everything behind them.

[Darkcrafter]

Exactly. It's getting really interesting how quake 1 solves this problem, if it does at all. DirectX9 Mark V, Mark V software and DarkPlaces just fly even with my old config. I am assured it uses BSP and maps precompilation but what if the same could be done to doom? Maybe original 2D nature of the doom engine is what needs to be abandonded some day.

[phantombeta]

Exactly. It's getting really interesting how quake 1 solves this problem, if it does at all. DirectX9 Mark V, Mark V software and DarkPlaces just fly even with my old config. I am assured it uses BSP and maps precompilation but what if the same could be done to doom? Maybe original 2D nature of the doom engine is what needs to be abandonded some day.

The problem here is not Doom being "2D". The only thing that could be said to actually be 2D here is the BSP, and the BSP being 2D is not why hardware renderers for Doom are so slow.
Hardware renderers for Doom are slow because the level geometry is 100% dynamic. Anything can change at any time - textures can change and scroll, ceilings and floors can raise or lower, texture offsets can change, etc.
This is not a problem with Quake, where the geometry is fully static (AFAIK). This means the level geometry can be uploaded to the GPU once, while with Doom's highly dynamic level geometry, you have to traverse the BSP and send the level geometry to the GPU every frame.

[Darkcrafter]

I would never call doom's geometry that dynamic. In Quake geometry moves too, ceilings can crush, moving platforms (not only vertically like in doom), doors that move horizontally when open or closed. As far as I know scrolling textures shouldn't be that resource demanding? I think I should try converting those maps to quake and see what I get.

[TDRR]

I would never call doom's geometry that dynamic. In Quake geometry moves too, ceilings can crush, moving platforms (not only vertically like in doom), doors that move horizontally when open or closed. As far as I know scrolling textures shouldn't be that resource demanding? I think I should try converting those maps to quake and see what I get.

In Quake, though, you don't need to send the BSP twice because moving geometry are literally entities disguised as brushes.

[phantombeta]

Exactly. Those are actually entities, which are separate from the (completely static) BSP-based level geometry, and their models can also be uploaded to the GPU only once. After that, all you need to do is animate the entity or change its position.
In Doom, moving ceilings and floors all change the actual level geometry, which is something that you can't even do or shouldn't do often in other engines.

[Darkcrafter]

Ok, then using the quake approach would benefit a lot? A map compiler just creates entities out of sectors and moves them around anyhow?