DarkkOne wrote: ↑Sun Feb 19, 2023 2:19 am
Okay, is there a readme or more detailed description of each of the options somewhere? I've been trying to figure out, for example, what the "Sprite -> Shadow" toggles do. I don't see an obvious difference where I thought I would (in the appearance of the shadows cast by players and monsters). And just in general, I'd like to read up on as much of it as possible, so I can tweak it. It looks gorgeous over all, but I'm weird and certain artifacts just kinda distract me, so I kinda want to try to tune it to like... look as good as I can without the bits that catch my eye necessarily being there anymore.
Also, it suggests that "0 = inf" for the amount of shadows, but I keep noticing that like... I only cast one player shadow, and it'll hard jump from one position to another as a new light source becomes the shadow-casting light source. Is that expected? I would've thought with 'infinite' shadows, I'd just have a shadow for each light source that had LoS on me, basically.
Thanks for commenting and kudos.
I haven't gotten around to an explanation of the options. On the list.
Sprite -> Shadow refers to how the player casts a shadow on a monster when close enough to do so. Cheap and subtle.
The number of shadows refers to the number generated, since these are expensive. Each shadow has a thinker checking for the brightest light source. Dual Shadows changes from one shadow per caster to two, so the maximum shadows per caster is two. This is true for the player as well, although you may not see it. These shadows often can look jittery depending on the light sources; I think this happens when two similar light sources are the same distance apart. Normally this isn't a big deal with everything moving.
Shadows are updated based on visibility to the player as you suggest, although it isn't line of sight. Anything in front of the player within the shadow distance updates its shadow position to reduce thinker chewing. (We want for example shadows cast around corners in front of the player.) This is also true for extra dynamic lights. These are also limited by whatever might be blocking the shadow. This is to avoid situations where a corpse might cast a shadow when a monster is standing in front of it, for example. All of this is to reduce thinker chewing in any one sector.
Thinkers iterate through everything
of a certain class and are relatively inefficient. I've wondered if its worthwhile creating different light source objects for moving light sources such as missiles versus static light sources such as decorative lights. I'm unsure that would improve performance. Currently items are eliminated based on some simple calculations before applying a hit scan to the source, but it's still relatively expensive when there are many shadows in view.
Keep in mind that shadows in close proximity to a wall will also cast shadows on the wall, which creates another actor albeit one without a thinker. Shadows can be limited by sprite size, but this will lead to some odd effects depending on the geometry and whatever tricks are used to achieve a certain effect. Shadows are FLATSPRITEs or WALLSPRITEs and can't be clipped, so they extend upward or outward to their length regardless of geometry. Note there is also a FLATSPRITE bug in GZDoom regarding Z-order sorting that makes some sprites overlap the caster sprite (I think that's the issue). There aren't any ZScript workarounds for these issues. Ideally, for example, a FLATSPRITE should bend and cling to flats and textures. But they are just sprites.
As a universal mod I have coded very little specific information, so you'll also see shadows for flames and a few other oddities. Can't be helped as is.
The above is also true for GZDoom's built in sprite shadows, of course. They've just been squished and always pushed back a little to avoid these issues.
Hope that rather long explanation helps. Let me know if there are other options you are curious about.