GZDoom discussion (Version 2.3.1 released 2016/jan/7)

[dpJudas]

I'm not sure how to best calibrate the exposure thing to be honest. If you want to effectively disable exposure, set gl_exposure_base to 1.0 and gl_exposure_scale to 0.0. That will make only overbright things bloom. Nothing in vanilla Doom will now bloom, since nothing there is overbright.

If want less than overbright things to bloom, set gl_exposure_base to something lower than 1.0 while keeping scale at zero. The problem with doing this is that then the snow scenes in BoA will bloom everything as those scenes use white all over the place. So the exposure defaults are set to tone down the bloom for very bright scenes.

[ZZYZX]

Perhaps just use exposure for bloom calculations, but render normally?

[dpJudas]

It already does that if you keep the tonemap setting off.

[ZZYZX]

Oh, so I had tonemap at 1 and didn't notice. Thanks.

[drfrag]

Bug report here:
GZDoom 2.3.2 + brutalv20b.pk3 + brutalv20c_UP.pk3. I don't think this happened before: if you get killed while deselecting a weapon when you resurrect the new weapon appears briefly but then dissapears and you can't shoot nor change weapons. Reproducible with the kill command but not deselecting the chaingun, i guess becouse deselecting it is fast. This doesn't happen in vanilla.
http://www.moddb.com/mods/brutal-doom/a ... cial-patch

[Rachael]

If you aren't going to post it on Mantis it probably will never get fixed because there's so many posts on this forum it'll just get lost in the shuffle.

[drfrag]

I couldn't register some time ago, i got an error.

[wildweasel]

I couldn't register some time ago, i got an error.

Try it now, there were some plugin-related(?) issues that were messing up the email confirmation messages that should be fixed now.

[Rachael]

If you have a messed up confirmation email try requesting a new one by resetting your password.

[drfrag]

Reported, thanks.

[camaxide]

Ok, I'll throw out a likely silly question. Does GzDoom "build" the level as 3D in any way?
I'm thinking into why dynamic lights does not cast shadows (surfaces does not block light) - I assume it's due to the 2,5D nature of Doom - but still need to ask, as shadows from surfaces would have been really nice.

[Graf Zahl]

No, it doesn't. And that's precisely why shadows and such are so hard to do.

[camaxide]

Also, do we have any know how about what bottlenecks performance in gzdoom? I get much better performance with it than zdoom, but the strange thing is that on maps where I run down to 80 FPS etc. I notice that no cores on my CPU seem to ever go above 30% while playing Doom, and the GPU never goes above 20% usage. If I ramp up Bloom and AO Gpu goes up to about 30% on hard scenes, while fps drops down towards 50. So it seem it makes a toll on the GPU, but how come neither CPU not GPU is really making a sweat, still performance is bad?
I ask because I really like these new graphics settings that came about now like the bloom and the AO, but it seem to kill FPS at my system (and my system isnt a bad one)

[ZZYZX]

GZDoom's playsim is singlethreaded, i.e. uses one core. Also, a lot of lag is due to transferring data back and forth, which doesn't count as "load" by your utilities.

[dpJudas]

What graphics card do you use and at which resolution do you play at? Note that the AO in particular is quite expensive on the GPU side of things, especially if you put its quality setting at max and use a high multisampling setting. Cranking up the AO portal slider can be a true killer on a map where you can see a lot of portals.

About the CPU and GPU usages, what is going on here is that the main GZDoom rendering is CPU bound. That means the GPU is bored and waiting for the CPU to feed it more walls and floors. The AO on the other hand is very much GPU bound, but it only runs after the entire scene has been rendered. So you get the worst of both worlds here - first the GPU is bored waiting for the CPU, and then afterwards the GPU is very busy AO'ing while the CPU is bored.

One last thing about CPU usage percentages: most applications only use one core for various reasons (in GZDoom's case it is because access to the OpenGL context needs to happen on one thread). If you have 4 cores, then a value near 25% CPU usage means that a single core is maxed out. Even if you take something like QZDoom's multithreaded software renderer, you'll typically never see 100% CPU usage because about 30% of the time the other cores are bored waiting for the main render thread to feed them with stuff to do.