ZDoom

In case anyone is still looking for a solution, after the feature request was denied, I developed a limited-use (as in, what I needed it for) workaround by using the information in this thread about the renderer.

Faking Sloped, Transparent Geometry

Read the tag. Does it say "no" or does it say "later"? I already said, it's way too expensive to do more thorough sorting.

So... Are there any plans to rework the renderer in such a way that this wouldn't be out of the question in the near future, or should I just plan that it will never be a thing in the engine?

Rachael wrote:In the original Doom engine, sprites were never clipped by depth, they were simply sorted and rendered right over walls and planes

Depth buffer aside, that's how GZDoom also processes them. But Doom doesn't have any sprites that aren't facing towards the camera so a lot of the potential problems do not exist.

Rachael wrote:In the original Doom engine, sprites were never clipped by depth

That really depends on how you define clipped by depth. Yes, it didn't use a zbuffer but those the ceiling/floorclip values are effectively depth ranges by subsector.

In the original Doom engine, sprites were never clipped by depth, they were simply sorted and rendered right over walls and planes. The only time a sprite ever experienced clipping was when a post was behind either an obscuring 1-sided line or a visplane transition (i.e. 2-sided line with new sector properties).

I realize this philosophy breaks the overall aesthetic of a hardware renderer, but in the end it's not doing much harm.

If it was that easy...

Never forget that sprites can be camera facing sprites, billboarded sprites (X and XY), wall sprites and flat sprites. And all need to be handled differently, with potentially non-trivial splitting. With translucent models it even gets worse. Even now I do not perform full orientation-aware sorting because it'd be too costly.

In softpoly I slice the sprites into their subsector parts so that I can sort them by subsector. It is somewhat costly to do each frame, but the information could be cached (like dynlights) with a bit more effort. Not that I'm volunteering to do this - just saying.

The main problem with sorting is the sprites. If it was just geometry it could be sorted by subsector but since sprites can cross borders they infinitely complicate matters, especially if things like billboarding or flat sprites come into play.

For the foreseeable future, this will not change.

I am not Graf but I will predict it will take years, possibly decades, for anything to happen on this front, because the limiting factor here is CPU's which have seen very little change in the past decade.

My guess is that outright 'no'ing it may be translated into 'Don't hold your breath.'

Graf Zahl wrote:For the time being this is a 'no'.

Wait! So shouldn't this be put on hold, instead?

Ah, I see! Like I said, when I've screwed with GL it's been pretty straight forward, so I was wondering if it was something to do with ZDoom's process. So what exactly would need to be changed for this to be efficient?

This cannot be done because all translucent geometry needs to be sorted. And it needs to be sorted fast. Slopes will make this far more expensive with the current sorting algorithm so this is disabled for performance reasons.

For the time being this is a 'no'.

Hey, was trying to build a horizontal window into a ceiling today when I realized that this can't be done. I'm not sure why this isn't already possible, but I'd like for it to be possible. It seems like it should just be a call within the code to me, but I've never really looked at that part of the GZDoom code so I wouldn't know. Can anyone explain to me why this doesn't work, of not build in a way to make it work? :3