Soft sprite clipping

[Rachael]

For now - it is still No'd.

[Graf Zahl]

This is "No" because there is no workable solution to this. To render like this nearly all the advantages of hardware rendering have to be forfeited. Even in the best case scenario with no 3D floors and no portals it'd require more setup and draw calls.

[phantombeta]

This is "No" because there is no workable solution to this. To render like this nearly all the advantages of hardware rendering have to be forfeited. Even in the best case scenario with no 3D floors and no portals it'd require more setup and draw calls.

Not sure if it'd actually need that much more setup for the actual feature requested here - that is, soft sprites, not vanilla-like sprite clipping*. Portals could pose a problem, but I don't think 3D floors can.
I actually wanted to try implementing this, but the renderer code is... Ehhhhhh... It doesn't seem very pleasant to work with.
Another thing I'd like to try is dealing with the depth buffer portal seal issue, as I have an idea on how to do that, but I have no idea where it even does that in the code.

* (the stuff about vanilla-like clipping was some kind of tangent, not the actual feature request here.)

[Graf Zahl]

What bothers you about the renderer? I don't really think you'll find anything more workable elsewhere.
Regarding the depth buffer portal seal, that is necessary, otherwise you can get unpredictable sprite bleeding. Keep in mind that sprites are rendered per sector, so some can be behind a portal. And if the distance is right and the portal not sealed, you will see them bleed into the portal. This pass is done in the code that finalizes a portal, it renders the portal again with depth write enabled and stencil set to clear, both in the same pass.

[phantombeta]

What bothers you about the renderer? I don't really think you'll find anything more workable elsewhere.

I dislike C++, and, to me, it makes things like these look unnecessarily ugly and complicated. (Sometimes due to its syntax, sometimes due to pretty common C++ practices)

Regarding the depth buffer portal seal, that is necessary, otherwise you can get unpredictable sprite bleeding. Keep in mind that sprites are rendered per sector, so some can be behind a portal. And if the distance is right and the portal not sealed, you will see them bleed into the portal. This pass is done in the code that finalizes a portal, it renders the portal again with depth write enabled and stencil set to clear, both in the same pass.

Yes, it's necessary, but it should only be written to the actual hardware depth buffer, not the depth buffer used by the shaders. Speaking of which, I'm guessing GZDoom doesn't even have one, and just uses the hardware depth buffer.
Having a depth buffer texture has some nice things, such as allowing linear depth, which is... Well... A lot better than screenspace depth wrt. precision. It also allows you to selectively include things in it - for example, with one, you can seal the portal in the hardware depth buffer, preventing bleeding, while keeping the depth buffer texture used for shaders unmodified, allowing you to get rid of the mess with the SSAO portals stuff, and allowing depth buffer access to the custom post-processing shaders.

(I'm mentioning the linear depth stuff because I've noticed the SSAO can sometimes have some nasty depth precision issues. Here's a screenshot with bias set to 0 so that it's more obvious:)

[Graf Zahl]

For that you'll indeed need another buffer, currently it does use the hardware's depth buffer.

And regarding C++, what language would you prefer? Don't expect things to look clearer there, I think for what it does the code is as clear as it can be, considering it has to drive 3 very different backends.

[dpJudas]

The SSAO pass does use a linear depth buffer, but yes it is created from the "hardware" depth buffer instead of being output by a shader. Note that the precision of the buffer is typically 24 bit (for Nvidia) and 32 bit (for AMD with vulkan) with a 64k far plane. Thus the most horrible examples from that link does not really apply. You're welcome to change the shader to output linear depth directly of course.

Also, could we please keep the "language is crap" part out of this? I'm quite tired of having to read that. I could start every post about how I think D is a dead end language, but I don't because grown ups should be able to discuss technical solutions without such pointless noise. GZDoom is written in C++. Deal with it or send the PR converting it all to something else. Most of what makes the render code messy has nothing to do with the language anyway, but rather 20 years of history and different compromises required by OpenGL, GPU hardware and Doom C legacy during that period. Long lasting codebases are always messy.

[Graf Zahl]

Most of what makes the render code messy has nothing to do with the language anyway, but rather 20 years of history and different compromises required by OpenGL, GPU hardware and Doom C legacy during that period. Long lasting codebases are always messy.

And it's still a lot less messy than other renderers for old games I have seen. Trying to do anything advanced with PrBoom's GL renderer or (God forbid!) EDuke's Polymost is a futile undertaking, for example. The renderer is complex, because it's doing a lot of things, but since it is cleanly separated into high level game data processing and low levell API access, it is rarely necessary to work on both levels simultaneously.

[phantombeta]

Also, could we please keep the "language is crap" part out of this? I'm quite tired of having to read that. I could start every post about how I think D is a dead end language, but I don't because grown ups should be able to discuss technical solutions without such pointless noise. GZDoom is written in C++. Deal with it or send the PR converting it all to something else. Most of what makes the render code messy has nothing to do with the language anyway, but rather 20 years of history and different compromises required by OpenGL, GPU hardware and Doom C legacy during that period. Long lasting codebases are always messy.

Where did I say C++ is crap? I said I dislike C++ and find some of the syntax and certain common practices from it ugly, all of which is clearly my own personal opinion. (And that's not even considering the fact that the only reason I said it in the first place was because Graf asked me what bothers me about the renderer code)
And sure you could. That's your opinion, and you're perfectly allowed to have and express it - there's even quite a lot of truth in it. I love D, but I'll never claim it has no faults - for example, Windows support for it is treated like a second class citizen, and the whole thing with Tango vs. Phobos back in the D1 days has certainly tainted public perception of it. It's certainly a mostly dead language wrt. mainstream adoption, but that won't really make me stop using or loving it.
Getting this worked up over someone making such an extremely minor remark about their opinion is just extremely unhealthy IMO.

[Rachael]

phantom - I think you need to calm down a bit. Latching onto and then arguing about really minor details really isn't doing anyone any good.

Try and look at it from another perspective - dpJudas has been using C++ for decades now, likely longer than some people on this forum have even been alive, and while the language itself isn't without its flaws, it's certainly truckloads better than some of the crap we have to use today, especially if you have an inkling of a desire to get into professional programming. That could be a whole nother rant, and it'd be a way worse one.

I'm closing this thread because I see nothing good coming out of this, and I want to stop this before it actually becomes a major argument.