ZDoom

Yeah that I can confirm but it's the ideal option for most of my shaders. All I can do is recommend that users keep bloom on. It's definitely better now than before though :cheers:

Careful, "beforebloom" will include the weapon sprite when bloom is off. Or at least I think so.

That's okay, I can live with bloom on as long as the weapons sprites stay out of the way of custom shaders :thumb:

Someone might be able to have a go at making shockwaves around explosions now 8-)

This is always enabled (when bloom is enabled). I don't think there is any situation where bloom on the weapon is better.

"beforebloom" changed slightly in the sense that the input to any custom shader at this stage now doesn't include the weapon sprite, but only when bloom is on.

Was already updated, I just didn't know it was [i]only[/i] for bloom. But!.. It totally works for my own shaders as long as I turn bloom on :)

(Now is there a way to turn bloom off again and keep it :lol: )

You don't need to do anything. The player's hand sprites just don't glow anymore from the bloom. If it doesn't work for you, try updating your devbuild.

I've looked around but can't find what's needed to enable this. Is there a new term that can replace "beforebloom" in GLDefs or is it a console command?

This was [already in]

One thing that could help is if the bloom ramped it's intensity down as the pixel's saturation increases.

I'd like to try that PSprite fix with FillSpectre whenever I'm back at my computer :wub:

Just to reconfirm; does this remove only bloom from psprites, or remove post processing completely? If it's the latter, then I don't think it'd look good with the various post processing shaders currently available. Just one example is the underwater view warp. It'd look weird if only the hands aren't affected.

Even if such weren't the case, I think world blooming not bleeding over the hands is weird. It'd look like the weapon sprite was just pasted on top of the screen, no?

[quote="Nash"]That's a global fix, right? Then some weapons with intentional glowing parts attached to them won't bloom anymore...[/quote]
Yes, it is global, although it doesn't apply to 3D weapon models. I didn't make it an optional thing because nobody should really want the weapon to be constantly glowing. If you want parts of a custom weapon sprite to bloom, you can just bake the bloom directly into its sprite. :)

[quote="Chris"]FWIW, an 'std::function' requires a heap allocation to construct, which seems pretty wasteful to do every frame when you know where the call's going regardless. The way that's done feels like you're trying to have FGLRenderer depend on state it doesn't know about.[/quote]
The memory allocation will not affect performance - it is one allocation per frame.

My primary motivation for using a lambda there is that I want to keep the EndDrawScene logic in the GLSceneDrawer class. I know I could have passed 'this' and 'lviewsector' as arguments and then called the function directly (after making it public), but I wanted the reader of RenderViewpoint to see directly what PostProcessScene needed, as a hint to what is wrong with the design of this function.

FWIW, an 'std::function' requires a heap allocation to construct, which seems pretty wasteful to do every frame when you know where the call's going regardless. The way that's done feels like you're trying to have FGLRenderer depend on state it doesn't know about.

[quote="dpJudas"]Here's a fix that removes the bloom effect from the psprites: [url=https://github.com/dpjudas/dpDoom/tree/bloom_psprite_fix]bloom_psprite_fix[/url][/quote]

That's a global fix, right? Then some weapons with intentional glowing parts attached to them won't bloom anymore... =P

Here's a fix that removes the bloom effect from the psprites: [url=https://github.com/dpjudas/dpDoom/tree/bloom_psprite_fix]bloom_psprite_fix[/url]

The biggest problem is that Doom's diminished light is not natural at all. It causes a situation where the weapon and anything straight in front of you is a lot brighter than the rest of the scene. To make matters even worse, sprites are given a greater brightness than wall and floor, increasing the chance they will stand out and exceed the threshold.

Since it isn't really an option to fix the light model, the second best option is to disable it for psprites as they are always so much more bright than the rest of the scene.