ZDoom vs. GZDoom

[Graf Zahl]

Probably not. Unless someone comes along and helps me. I've got far too little time to work on this... :(

[Dancso]

Graf Zahl said:

Whoo said:
You need to optimize the engine, seriously.

You need a reality check, seriously! Have you even read Myk's post above about Doom and hardware rendering? Doom will never *ever* be able to get the same performance out of modern hardware as newer games. Modern games optimize their data so that they can handle it with a relatively small overhead before passing it to the hardware. Doom can't do that. A lot of stuff has to be recomputed each single frame - and there's very little that can be done about it.

http://forum.zdoom.org/viewtopic.php?f=18&t=21478&p=421972

Is there a problem with doing whatever's possible to optimize? Hell, it could be an option to toggle on or off.

Or better yet, adjustable draw distance!

[Graf Zahl]

Cheap, shitty and generally a bad idea. Not going to happen - ever!

[phi108]

I think mipmapping helps performance in that regard. The areas are still drawn, but the texture isn't full resolution.

I'm not sure though, but I think mipmapping increases performance in GZDoom and the Source engine.

[ReFracture]

Gonna be honest: Outside of running stupid shit like nuts.wad, I've never managed to bring GZDoom to a low framerate.

What exists for GZDoom that gives most people performance issues?

[Graf Zahl]

On some extremely wide open maps the frame rate may break down, e.g. UTNT's final map. Another issue may be certain portal effects. They require a setup that can badly stall the hardware.

Disregarding that, none of these issues are coding related. They all are caused by the GFX card hitting the limit and no code optimization will make them go away.

The last few days I implemented VBO support for flat rendering (no walls yet) and the code execution time measurably decreased. But the frame rate did not increase because this is not the limiting factor.

[LexiMax]

esselfortium said:

Well, I for one can't wait to not be able to play any new GZDoom mods on my 2007 laptop that runs Doom 3, Half-Life 2, and Portal flawlessly. Bring it on.

It's funny that you bring this up because Half Life 2 and Portal both use...*gasp*...different rendering pipelines for older cards. Unless Graf is removing the old renderer anytime soon (hint: he's not), it's just like Half Life 2 defaulting to DX8 or DX7 mode when it detects DX9 is too hard on your system.

Whoo said:

You might not be able to get it as opitimized, but you certainly could do a hell of a lot better. Take a look:

Column A is Gzdoom, Column B is GlBoom

Didn't Doom have a 35fps cap? These are hundreds of frames per second.

Play prBoom+ then if it's so much faster for you. Besides, anything over 60 is unnoticeable unless you're a quake playing sperglord anyway.

[Baby Bonnie Hood]

I mainly stick to ZDoom. Not out of favoritism, but because I can't play GZDoom more than once per PC session (it'd BSoD my laptop if I tried to play it again a second time).

[entryway]

Graf Zahl said:

The last few days I implemented VBO support for flat rendering (no walls yet) and the code execution time measurably decreased. But the frame rate did not increase because this is not the limiting factor.

GLBoom-Plus can use VBO for skybox and flats. I have these results on map05 @ epic.wad with my config and Core2Duo 3.0 + GForce 8800 GTS:

glboom-plus_immediate - 272fps
glboom-plus_drawarrays - 282fps
glboom-plus_vbo - 282fps

[Graf Zahl]

Interesting.

My results are a bit different.

Immediate and VBO are nearly the same speed but glDrawArrays with a software storage buffer is noticably slower. And if I use glArrayElement performance breaks completely down.

What driver version are you using?

[entryway]

Graf Zahl said:

What driver version are you using?

The latest WHQL. 190.62 I think.

[entryway]

Graf Zahl said:

Immediate and VBO are nearly the same speed but glDrawArrays with a software storage buffer is noticably slower. And if I use glArrayElement performance breaks completely down.

Strange. glDrawArrays should be faster.

gl_sky_detail 8192 (SkyDome drawing code is from o-o-old gzdoom, but with support of VBO)
glboom-plus.exe -geom 640x480w -nosound -warp 12 (32 bits, trilinear, Aniso16x, AA4x)

immediate - 36 fps
drawarrays - 53 fps
vbo - 487 fps

[Starke Von Oben]

I've toyed around with Gzdoom, but to be honest if I want to make true 3D floors I'll edit Quake.