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

Share this post


Link to post

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!

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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).

Share this post


Link to post
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

Share this post


Link to post

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?

Share this post


Link to post
Graf Zahl said:

What driver version are you using?

The latest WHQL. 190.62 I think.

Share this post


Link to post
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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now