Why are ZDoom and GZDoom still separate ports?

[Graf Zahl]

---

Perfomance test shows that glboom is 10x faster (!) than GZDoom.

I have no idea how you managed that but 10x faster is pure and utter nonsense. That may happen on isolated maps that don't play well with ZDoom's play engine, but those are rare.
On average the speed difference is approx. 1.2x to 1.3x, which is caused by GZDoom's need for more complex geometry processing. The basic renderers of both ports are very similar as they share the same roots.

If you got a 10x difference something else is on - you need to post more info instead of a screenshot.
For example:

- what mod were you playing?
- what settings were you using?
- what's your hardware specs (CPU anf graphics card!)
- what add-ons had been loaded?

[Nash]

What map is that? How come it's slowing down the engine so much. :S

[Monsterovich]

http://www.doomworld.com/idgames/?file= ... 9/5l1c.zip

My videocard is old, but...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 6200/AGP/SSE2/3DNOW!
OpenGL version string: 2.1.2 NVIDIA 304.117

[_mental_]

Just a quick test: using 640x480 resolution I have 4 to 5 times higher FPS in GLBoom-Plus than in GZDoom Like ~400 vs. ~100
i7 3770 3.4 GHz with GeForce GTX 680.

[Monsterovich]

FrozenT.wad

---

GLBoom+

GZDoom 1.9

GLBoom+ is 3.5 ~ 4x faster on this map. GLBoom has nice performance to play, in GZDoom - slideshow.

[Graf Zahl]

Just a quick test: using 640x480 resolution I have 4 to 5 times higher FPS in GLBoom-Plus than in GZDoom Like ~400 vs. ~100
i7 3770 3.4 GHz with GeForce GTX 680.

What map? What settings? Keep in mind that with such recent hardware the engine is strictly CPU bound and the engine just can't be 5x slower than PrBoom. Even on mid range maps it's not doing enough for that.

For the record:

I can render the bridge scene of FrozenT.was with 38 fps in GZDoom 1.9 and with 45 fps in GZDoom 2.0.
On the cave scene of P:AR's E1M6 I get 250 fps.
That's with a Geforce 550Ti on a 3.2 GHz i7 (I don't know the precise type.)


As for the Geforce 6200, hard to say where the engine gets stuck. Do you have any shader options in the GL menu and if so, what are they set to? Don't forget that the Geforce 6xxx series had piss-poor shader performance, on my ancient system with a 6800 even activating a minimal shader caused 50% performance breakdown, and using a shader that actually did something useful was impossible.

[_mental_]

What map? What settings? Keep in mind that with such recent hardware the engine is strictly CPU bound and the engine just can't be 5x slower than PrBoom. Even on mid range maps it's not doing enough for that.

MAP01, everything by default.
I was also surprised with such difference in performance. Although, I have no possibility to investigate it further at the moment.

[Nash]

http://www.doomworld.com/idgames/?file= ... 9/5l1c.zip

Wow this map is pretty intense. :O I think the slowdown is caused by the grass sprites. I'm averaging between 30-40 FPS under normal gameplay in this map. It's architecurally impressive though... I wish Doom could handle these kinds of open maps. :(

[Graf Zahl]

What map? What settings? Keep in mind that with such recent hardware the engine is strictly CPU bound and the engine just can't be 5x slower than PrBoom. Even on mid range maps it's not doing enough for that.

MAP01, everything by default.
I was also surprised with such difference in performance. Although, I have no possibility to investigate it further at the moment.

Ok, but the problem must be on your side. I easily get 500+ fps on that level with GZDoom 2.0.

[Graf Zahl]

http://www.doomworld.com/idgames/?file= ... 9/5l1c.zip

Wow this map is pretty intense. :O I think the slowdown is caused by the grass sprites. I'm averaging between 30-40 FPS under normal gameplay in this map. It's architecurally impressive though... I wish Doom could handle these kinds of open maps.

The mass of sprites is definitely a factor. It runs at 67 fps in the most sprite heavy places for me and 1/3 of the entire time is spent processing the sprites. On a weak CPU this will kill performance for sure.

[Monsterovich]

As for the Geforce 6200, hard to say where the engine gets stuck. Do you have any shader options in the GL menu and if so, what are they set to? Don't forget that the Geforce 6xxx series had piss-poor shader performance, on my ancient system with a 6800 even activating a minimal shader caused 50% performance breakdown, and using a shader that actually did something useful was impossible.

This is not shaders 100%, but why did you disable SWGL shader on older videocards, without the way to turn it on? It doesn't cause performance breakdown for me.

[Graf Zahl]

Too many compromises for newer cards. The shaders in GZDoom don't work well with first generation shader capable hardware and when I wrote the code these cards were already on their way out. In other words: A lot of work for the benefit of a handful of people. I have better things to do, especially since the shader-free code works fine. Of course, trying to play maps that overtax your system unsurprisingly doesn't work out that well.

How much RAM do you have, btw? This can also be a contributing factor in performance breakdown.

[Monsterovich]

How much RAM do you have, btw?

Videocard RAM?
256 mb

My system RAM is: 1 gb + swap

This can also be a contributing factor in performance breakdown.

What factor?

[Graf Zahl]

I did some performance tests myself with PrBoom+, using FrozenTime.

GZDoom 1.8.6 produces 39 fps.
GZDoom 2.0 development produces 51 fps
PrBoom+ 2.5.1.3 release build produces 99 fps

Now, there's one very important thing to note here: Entryway uses Intel's compiler which I do not have access to (it costs $699) - building the same source with Visual Studio produces 71 fps.

So for this clearly heavily CPU bottlenecked map we got a speed factor of 1.4.

I did some checks where GZDoom loses this time.

Biggest surprise: most was lost in the timer calls for the performance display - so this is now disabled unless the display is on or the 'bench' command is running. For me this increased FPS from 51 to 55.
I also did some optimizations with draw list sorting, texture binding etc. which managed to shave off yet another half ms, leading to 57 fps.

But I guess that's it. After doing this I have a 4 ms difference between GZDoom and PrBoom+ on Frozen Time, looking across the bridge. These 4 ms are used for:

1 ms for decal processing (even though none are present in my test it still needs to check every wall for it, all 5000+...)
2 ms for increased complexity with coordinates due to slopes which PrBoom+ does not have. GZDoom simply cannot assume anywhere that the z coordinate at the left and right end of a linedef are identical.
0.5 ms for more thorough sorting of translucent stuff.
The rest gets spread across several minor things which are neccessitated by ZDoom features.

Of course none of the above cannot be changed but it's what I have been saying all along: A renderer that's restricted to somewhat simpler stuff will always be faster of both are written with the same efficiency.

So @Monsterovich: Something must be wrong on your system that GZDoom tanks this badly. Have you tried running v1.8.6 without shaders (i.e. launching with the command line option '-sm2')?

[VGA]

GzDoom also has fragglescript support, right? Any other changes?

Also, Graf Zahl, I tried that GzDoom 2.0.02, it seems to work fine on my gtx260 but with reduced performance. I did a benchmark at start of "5till L1" using the same ini and instead of 50fps average I get 36. Is it normal? I tested against 1.9pre-664-g7fedaf9, dynamic lights enabled, vsync off.

If useful to you, in which thread should I post the results?

Random question: Why is loading of .deh .bex lumps disabled by default? Doesn't that break some old wads?