DRD Team

I'm not sure about the technical term, but what is it that makes GZDoom's edge blending look like it's "vectorizing" the the borders of the sprites? to me, it always looked unpleasant and very stamp-like compared to the classic smoothing technique still offered by other Doom engines and pretty much every game from the 3DFX era.

Can you manage something like this?



JDoom


GZDoom + Smooth sprite edges

Thanks.

I can only guess what you want because, honestly, I can't make much sense of your post.

If my guess is correct you may play around with the gl_mask_threshold CVAR. Maybe it helps you get what you want.

Hmm, no luck with gl_mask_threshold. What does it do anyways?

Just look at the pictures, can you tell the differences between the edges of the cacodemon sprites?

If you have any high-quality rescalers (eg. HQ2X) enabled, disable it. They band colors so that harsh changes (eg. full alpha to no alpha) are more sharp and not as blurry like in the first pic. There's also the Smooth Sprite Edges option under Preferences in OpenGL Options.

Though personally I prefer the latter look. It also bugs me when sprite edges blur with what's behind it (and from a technical stand-point, masked sprites like that perform better if the edges don't blend with the background, since they can be sorted near to far with depth testing/writing, reducing overdraw, and the card doesn't have to do additional work to alpha blend them).

Ok let's try again.

JDoom blurs out the edges of the sprite in a way it just seems to "blend" with the background in a very natural way. GZDoom does apply some blurring as well, but the sprite just doesn't seem to "blend" with the background like in JDoom, in fact, you can actually tell the limits of the blurring effect.


GZDoom - JDoom

Can you see it now?

Sussudio wrote:Hmm, no luck with gl_mask_threshold. What does it do anyways?

Just look at the pictures, can you tell the differences between the edges of the cacodemon sprites?

Yeah, I noticed that it wasn't used in the place where sprites are drawn. Since I probably had a good reason for that I added a new CVAR, gl_mask_sprite_threshold. Set this to a very small positibve value (not 0!) and you should get what you want.

Chris wrote:Though personally I prefer the latter look. It also bugs me when sprite edges blur with what's behind it (and from a technical stand-point, masked sprites like that perform better if the edges don't blend with the background, since they can be sorted near to far with depth testing/writing, reducing overdraw, and the card doesn't have to do additional work to alpha blend them).

Actually, I don't depth sort non-translucent geometry. Every test I made indicates that sorting by texture yields better results than sorting by depth.

Graf Zahl wrote:Yeah, I noticed that it wasn't used in the place where sprites are drawn. Since I probably had a good reason for that I added a new CVAR, gl_mask_sprite_threshold. Set this to a very small positibve value (not 0!) and you should get what you want.

Thanks, can't wait for the next svn

Just tried it...works wonders! Now, do you think it would be that much of a trouble to include a similar cvar for textures with transparency?

Graf Zahl wrote:

Chris wrote:Though personally I prefer the latter look. It also bugs me when sprite edges blur with what's behind it (and from a technical stand-point, masked sprites like that perform better if the edges don't blend with the background, since they can be sorted near to far with depth testing/writing, reducing overdraw, and the card doesn't have to do additional work to alpha blend them).

Actually, I don't depth sort non-translucent geometry. Every test I made indicates that sorting by texture yields better results than sorting by depth.

I remember reading once about a technique that was used.. you would do a depth-only render pass first, since disabling color-writes would let it work very fast (no fancy per-pixel lighting calculations, bump-mapping, or other pixel shader effects). The opaque/masked surfaces would then have zero overdraw when color writing was re-enabled, and as long as the color-enabled pixel shaders don't write a depth value, OpenGL can early-out and skip the shader processing for pixels that are hidden. And when you have processing-heavy pixel shaders, 16x Aniso Filtering, etc, trying to cut as many unseen pixels you can from being processed will vastly improve speed. Obviously, though, it won't benefit surfaces that use alpha blending (eg. sprites/textures with blurry edges vs sharp edges, and translucent geometry and textures).. those still need to be sorted far to near and drawn over top of the opaque/masked scene.

1st pass (unsorted opaque/masked geometry):
color-write off, alpha-blend off, alpha-test on, depth-write on, depth-test on, stencil-write on, stencil-test on

2nd pass (unsorted opaque/masked geometry):
color-write on, alpha-blend off, alpha-test on, depth-write off, depth-test on, stencil-write off, stencil-test on

3rd pass (sorted translucent geometry):
color-write on, alpha-blend on, alpha-test on, depth-write off, depth-test on, stencil-write off, stencil-test on

Anyway, just an anecdote about something I remember reading in relation to depth-sorting and rendering efficiency. No idea how well it would work for GZDoom.

I already tried that some time ago, didn't work. It was slower than the current method.

JDoom


GZDoom

Just an example of what I meant with my previous comment.

I wont it too blending