ZDoom

I like this idea a lot.

I'm pretty sure the bigger challenge here would be the [i]states[/i] part, not rendering.
[quote="Rachael"]A little "hack" would be to smidge the higher overlays in front of the back ones, but that might be observable, the sprite clipping would be a bit weird on the walls even if you used perspective math to correct it, and it also does not guarantee that you'll be able to avoid Z-fighting at any sort of distance.

Not saying it's impossible - just that any implementation that runs on the hardware renderer would probably be glitchy.[/quote]
I don't think this is a problem at all. Last I checked, sprites can already be in the same exact (GZDoom) XYZ coords without glitching out.
I'm also pretty sure GZDoom disables Z-writes for drawing sprites, as that would have pretty bad results... So the only thing that determines the rendering order for them is the order they're drawn in, and as such, they can't get Z fighting between each other.

[Edit] Just checked and yep. Depth test enabled, depth write disabled.

[quote]Unless, of course, the texture was composited before it was sent to the renderer - which would simply slow down rendering, especially if a lot of such sprites were shown in the scene.[/quote]
That can easily be done on the GPU itself, though.

Reminds me of [url=https://forum.zdoom.org/viewtopic.php?f=18&t=60224]this[/url]. Spoiler warning: it was noed.

[quote="Major Cooke"]I wonder how hard this would be to make. It'd be very nice to have, I agree.[/quote]
A lot less simple than screen overlays, since world drawing has to respect Z-space.

A little "hack" would be to smidge the higher overlays in front of the back ones, but that might be observable, the sprite clipping would be a bit weird on the walls even if you used perspective math to correct it, and it also does not guarantee that you'll be able to avoid Z-fighting at any sort of distance.

Not saying it's impossible - just that any implementation that runs on the hardware renderer would probably be glitchy.

Unless, of course, the texture was composited before it was sent to the renderer - which would simply slow down rendering, especially if a lot of such sprites were shown in the scene.

I wonder how hard this would be to make. It'd be very nice to have, I agree.

Heh, this could be nice to get rid of the hacks I use to have models with different per-part render styles. I like it.

I propose a change that'll allow overlays for other non-player/weapon actors as well, allowing multiple sprite layers to be rendered in the world for the same actor (higher value overlays are placed over lower-value overlays, like with A_Overlay). One such place it could be used is with depicting battle damage on a monster as it's being torn apart by a hail of bullets.