[Added] Sprite shadows

[Nash]

This adds Build engine-styled sprite shadows directly into the engine. Inspired by my very popular mod, SpriteShadows (which is in turn, inspired by the Build engine games :P). Most likely more than 10k downloads since 2017; too bad I never kept the old versions around to document their download counters, but they were all 4 digits.

This feature is meant to supersede the mod version.

- Works for both software and hardware renderer
- New actor flags: +CASTSPRITESHADOW to enable sprite shadows on an actor, and +NOSPRITESHADOW to forcefully disable sprite shadows on an actor

New CVar: r_actorspriteshadow

0 = sprite shadows will never be rendered
1 = default - no sprite shadows rendered unless actor has flags set explicitly
2 = always on - will forcefully draw shadows for living things (monsters and players)

Pull Request

[Redneckerz]

The refined variant of GShadow Resurrected, this is such a winner feature to have directly in-engine that i can see this be plenty used for mods and it would be well worth to advertise this as a killer feature.

[Graf Zahl]

How does this handle with portals? I couldn't see any code in there dealing with casting shadows across portal boundaries.

[Nash]

Does this not take care of floor portals, and this take care of wall portals?

I tested it with arookas' portal.wad and it seems to work for both wall and floor portals... also in both renderers (though the portals themselves kinda look off with the software renderer but that's not related to the sprite shadows)

If these aren't it, please clarify what portal handling exactly do you mean. Admittedly everything I'm doing here is very new ground for me.

[Graf Zahl]

If you tested it it should be ok - I was asking because sprites need special splitting on portal lines.

hw_fakeflaz does not do anything with portals, it's for Boom's deep water sectors.

[Nash]

Yes, it's confirmed to work. In both images, the player and the archvile are both standing between portal boundaries. I have intentionally (for the purpose of these screenshots) hardcoded the shadow to be ultra-stretched to prove that it works - notice how the shadows are drawn correctly across portal boundaries.

Additionally, I've made one important change - I hope the commit message is self-explanatory.

[vsonnier]

Hi Nash,

I'm really looking forward to use this "baked-in" version of Sprite Shadows, especially if it has a better performance. Speaking of which, the current actor-based Sprite Shadows in Black Edition have the following features that may be interesting to keep in some way:

- Not displaying Shadows for monsters (+CASTSPRITESHADOW in the future) far enough from players. Your original Sprite shadow did that also of course.
- In BE, casings and magazines are given the +MONSTER flag to give them shadows too, a subtle addition for magazines in particular. Casings are small in comparison, so truth to tell the effect is much less noticable.
- The Sprite Shadow is removed / destroyed after a time if :
-- The monster is dead, supposely on the ground (your previous version does that too)
-- The casing and magazine has been spawned for more than 5 seconds, so is technically lying on the ground. (where the shadow is almost invisible). This is a good optimization for chainguners spawning tens of casings each time !

The reason of all these tweaks being the same : do not display Sprite Shadows when they are invisible in practice. Is the new implementation use some form of optimization for perfomance with similar tricks ?

[Nash]

The engine version doesn't suffer the same limitations as the mod version (which is caused by the overhead of being Actor-based) so most of that won't apply here. Only thing I brought over is render distance, that's enough to reduce the draw calls and make slaughtermaps like Okuplok fully playable with minimal performance impact.

Is the new implementation use some form of optimization for perfomance with similar tricks ?

They are done in the sprite drawing passes of the renderer. Basically, it's done at the same place in the code that the engine uses to render sprites.

[vsonnier]

Only thing I brought over is render distance, that's enough to reduce the draw calls and make slaughtermaps like Okuplok fully playable with minimal performance impact.

That is indeed a hell of a benchmark ! The drawing distance test is really where the perfomance gain was anyway, so I'm looking forward to use the final version

[Marisa Kirisame]

Important: Will models get blob shadows or something like that?

[Nash]

Important: Will models get blob shadows or something like that?

Didn't I already answer this on Discord? :P

No, models are out of scope for this PR.

(Plus, even if I did want to blob shadows, which would require me to make a separate PR - (as I've answered on Discord) I would want to do it in a way that it uses an actual projected decal, not some lazy way that just draws a round sprite. It should be a decal so that the level geometry would clip the blob properly. This is how it looks like in Quake 3, for example. Ultimately, this is beyond my skill because I don't know how to draw decals on floors and neither does the engine currently support such a thing)

[Graf Zahl]

not some lazy way that just draws a round sprite.

I think this really needs fixing in Exhumed...