GZDoom needs a new programmer

[entryway]

The only place where zdoom (and gzdoom) is really slower than prboom is nuts style wads. It still infinitely faster than all others modern ports like jdoom and vavoom which are 0 fps there, but can be 3-5x slower than prboom easily. But who cares about nuts.wad?

[Spleen]

The only place where zdoom (and gzdoom) is really slower than prboom is nuts style wads. It still infinitely faster than all others modern ports like jdoom and vavoom which are 0 fps there, but can be 3-5x slower than prboom easily. But who cares about nuts.wad?

I thought nuts.wad was limited by the speed of the thinker, rather than the speed of the renderer. I thought that the problem maps are renderer intensive maps such as Sunder.wad maps 9 and 10 - they only run at 20-30 FPS on my ATI HD 4890 in GZDoom, but they run perfectly on GLBoom+. What is the reason for the 3-5x speed difference between your renderer and Graf's? Thanks for the info!

Ohh. Not to change the topic but I think everyone who has had a stab at Graf blame his bad/dirty/stupid code, but has anyone of them even touched the source? I bet if they saw what complications were involved they'd keep their trap shut, but eh... That's life

I'm not one of the people who claims that Graf made a stupid renderer. I appreciate all he has done for the community, and wish he hadn't quit. I also don't claim to be able to do nearly as much as he can. However, the one thing I have done with the renderer is fix a bug in the mirror code in the old renderer. Graf blamed this on drivers, instead of investigating which revision it broke in. With a proper investigation, it would have been clear that it was buggy angle caching code which he introduced in a certain revision. If he has no time, it would have been acceptable to say "Sorry folks, I don't have time to investigate this bug", but for some reason he just pretended nothing was wrong. That is just being dishonest.

[DaniJ]

Up to now I have deliberately stayed clear of this debacle because it seemed out of place for me to comment on it. I'm sure most are aware that Graf and I have had our differences in the past and we rarely see eye to eye on many topics. Now, I've no experience what so ever with the GZDoom codebase but I think I have a fair idea of its overall design, gleamed from previous discussions and what-not. With that said, I would like to offer the following opinion for what its worth:

On the whole, there is nothing wrong with the way GZDoom's renderer works. It is after all fundamentally the same as pretty much every other current GL rendering source port (Doomsday included). For the most part the issues ATI users are facing appear to be born from the fact that their drivers are much less forgiving of slight divergence/non-adherence to the letter of the OpenGL specification. Is it right to blame ATI for that? No, not really. However as GZDoom was not developed on ATI hardware it is understandable that Graf would reach that conclusion when the latest great optimization idea or new feature doesn't work out when tried there.

As has been stated several times in this thread, the GZDoom renderer is a lot faster than Doomsday. This is plain for anyone to see. Its faster because it has been better optimized for more modern hardware (utilizing shaders for example) and that is to Graf's credit.

However my opinion is that so far there is no GL rendering source port that is truly designed for modern hardware from the ground up. Modern hardware demands a fundamental change in approach, namely; batching and caching (in bulk) geometry and other such data. Graf has stated previously that he tried it and it didn't work out but that only means the way he approached it wasn't right for GZDoom. It does not mean that it isn't the right direction and it should be abandoned.

Those criticising the GZDoom renderer for not batching geometry have every right to do so and whats more, they are entirely valid points.

However this has nothing to do with the fact some ATI users cannot use the port.

[entryway]

What is the reason for the 3-5x speed difference between your renderer and Graf's?

ZDoom is *also* slow on nuts.wad. So it is not a problem of gzdoom at all.

[dark-slayer-201]

What is the reason for the 3-5x speed difference between your renderer and Graf's?

ZDoom is *also* slow on nuts.wad. So it is not a problem of gzdoom at all.

I think it runs fine on ancient zdoom.

[entryway]

I think it runs fine on ancient zdoom.

Probably.

With the latest zdoom on computer on my work (Dual Core E5200 @ 2.5 GHz) I get 1-2 fps in few seconds after shooting. With PrBoom (software renderer, -complevel 2) I have 50+

But you can make PrBoom slow as zdoom on nuts.wad with 'helping' of MBF option "help_friends 1" in cfg.

[Spleen]

What is the reason for the 3-5x speed difference between your renderer and Graf's?

ZDoom is *also* slow on nuts.wad. So it is not a problem of gzdoom at all.

Wouldn't nuts.wad be limited by the thinker rather than the renderer, though, because of all monsters active at the same time, making it a poor benchmark for the renderer? I'm guessing the slowdown is due to the extreme complexity of ZDoom's thinker processing functions, due to all the different DECORATE functions that were added. Unlike Sunder maps 9-10. which have extremely complicated level geometry, but not as many monsters active at the same time.

I'm wondering about the speed difference on Sunders maps 9-10. On GZDoom, they are extremely slow even when no monsters are active, but on your GLBoom+, they work fine.

Thanks!

[entryway]

Unlike Sunder

On start position of map10 I have 38 fps with gzdoom and 58 fps with glboom+ (GeForce 9500GT). 2 fps with the latest jDoom, btw. Not a big difference at all in consideration of how much gzdoom is complicated than glboom. Also glboom+ has unresolved issue with interpolation (I really can't understand it) and 60 fps in gzdoom feel more smooth than 90 in glboom+ (vsync is 100 for me). I tried to fix it with new method of interpolation ("interpolation_method 1" in config) in glboom-plus 2.5.0.7.test, but it looks like a crutch anyway.

[Spleen]

Unlike Sunder

On start position of map10 I have 38 fps with gzdoom and 58 fps with glboom+ (GeForce 9500GT). Not a big difference at all in consideration of how much gzdoom is complicated than glboom. Also glboom+ has unresolved issue with interpolation (I really can't understand it) and 60 fps in gzdoom feel more smooth than 90 in glboom+ (vsync is 100 for me). I tried to fix it with new method of interpolation ("interpolation_method 1" in config) in glboom-plus 2.5.0.7.test, but it looks like a crutch anyway.

Thanks for the info!

[Mr. X]

So is source code only needed or can i possibly upload compiled released versions?

[Gez]

Thanks, but I think we have all that we need already on the source/binary front.
http://sourceforge.net/projects/zdoom/files/

[Doom-stn]

[Edit by Eruanna: Translated from Spanish]

I am very sorry that the creator of GZDOOM, Graf Zahl, to stop working for the draft GZDOOM anymore.
Everyday always entered the page to see new updates GZDOOM, for me the best source ports that and seen it, but shit you goddamn life. Graf Zahl again I hope to continue their best project called "GZDOOM."

[RaVeN]

GZDoom must be alive anyway =0
This is best source port for wad games,
this is first place in my mind.
I am using only gzdoom, this true.
One thing which lacked is blend animation
http://www.youtube.com/watch?v=GHCs9NX7iaM
Awesome port, thanx for all hard work.

[Daniele C.]

Sorry people but Graf acted really childish, and furthermo people was giving right suggestions/critics to him. This is the truth, so please stop licking his ass. He turned shoulders to the community many times. So thanks for all the good fish, and thanks for stepping back.

I am an experienced developer, I can help at merging patches from ZDoom but I wouldn't be useful for new implementations (perhaps for code checking, yes); please contact me if I can be of some help

[timmie]

To be perfectly honest, Graf is right about Doom maps not playing nicely with modern cards on current engine implementations. Each surface can have a different texture and there generally aren't any areas you can safely batch together (pretty much because of the first point). This leads to basically the perfect storm for poor performance.

That said, if I were to look at making a new version of ZDoomGL, I'd probably start by looking at virtualized textures and generating a texture atlas at runtime (megatexture tech, if that helps). That way you could batch pretty much whatever geometry you wanted (break the map up into PVS areas or whatever) and focus on optimizing updating those batches for dynamic geometry and streaming in texture data. I'd probably also look at a deferred renderer to make it easier to handle a large number of dynamic lights (and make it somewhat easier to add proper shadows).

But that's only if I was actually looking at making a new OpenGL renderer. Personally I don't really have the time nor desire to do that anymore.

Graf is probably worn down like I was when I stopped working on ZDoomGL. Responding to the whims of a community over a couple years does that to you.