Page 8 of 13

Re: SpriteShadow: Duke3D-like Shadows v1.7a [performance upd

Posted: Wed Dec 19, 2018 9:20 am
by Tekish
When 1.7a is used with Universal Gibs, this happens whenever a monster is gibbed:

Image

Re: SpriteShadow (Duke3D Shadows) v1.8 [slaughtermap friendl

Posted: Wed Dec 19, 2018 11:39 am
by Nash
Update December 20th 2018 (version 1.8)

- Implemented max shadow distance to help performance with slaughtermaps
- Fixed a null pointer access

HolyHell.wad, MAP05 with 20,000 monsters, is now actually playable on my machine!

Re: SpriteShadow: Duke3D-like Shadows v1.7a [performance upd

Posted: Wed Dec 19, 2018 12:33 pm
by AFADoomer
This line...

Code: Select all

		else if (caster.CheckIfSeen())
...causes an effect where if the centerline of a monster is out of the player's sight, but a portion of the body and/or the shadow is still in view, the shadow will freeze in the current location (despite the monster still moving) until the centerline of the monster is back in view. Maybe use CheckSightOrRange instead, so that the shadow always draws within a certain distance of the player?

EDIT: OK, that was with 1.7a, but 1.8 has the same issue...

EDIT2: I've changed the check to

Code: Select all

		else if (caster && caster.CheckSightOrRange(512))
with no issues - you could probably reuse the cvShadowDistance CVar here instead of 512.

Re: SpriteShadow (Duke3D Shadows) v1.8 [slaughtermap friendl

Posted: Wed Dec 19, 2018 1:09 pm
by Tekish
Yes, I saw this happen in 1.8 as well.

Re: SpriteShadow (Duke3D Shadows) v1.8 [slaughtermap friendl

Posted: Thu Dec 20, 2018 1:14 am
by Armaetus
Oh nice, perhaps higher monster count monsters combined with Droplets would improve performance now :) Would actually be useful to me, especially when recording.

Re: SpriteShadow (Duke3D Shadows) v1.8 [slaughtermap friendl

Posted: Thu Dec 27, 2018 10:11 am
by m8f
I wonder if there is any sane way to make shadows not be visible from below. Right now this is my only nitpick for this mod.

Re: SpriteShadow: Duke3D-like Shadows v1.7a [performance upd

Posted: Fri Dec 28, 2018 11:25 am
by Nash
AFADoomer wrote:This line...

Code: Select all

		else if (caster.CheckIfSeen())
...causes an effect where if the centerline of a monster is out of the player's sight, but a portion of the body and/or the shadow is still in view, the shadow will freeze in the current location (despite the monster still moving) until the centerline of the monster is back in view. Maybe use CheckSightOrRange instead, so that the shadow always draws within a certain distance of the player?

EDIT: OK, that was with 1.7a, but 1.8 has the same issue...

EDIT2: I've changed the check to

Code: Select all

		else if (caster && caster.CheckSightOrRange(512))
with no issues - you could probably reuse the cvShadowDistance CVar here instead of 512.
CheckSightOrRange call is quite expensive, though... think time shoots up a lot just by doing this.

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Fri Dec 28, 2018 12:24 pm
by Nash
Update December 29th 2018 (version 1.85)

- Declaring this mod to now require GZDoom version 3.7.0 to fully take advantage of JIT compiler
- Updated ZScript directive to 3.7.0
- Fixed shadows to update properly when partially blocked from your line of sight
- Even more optimizations, it runs even faster now!
- Don't draw shadows when your view is under them
m8f wrote:I wonder if there is any sane way to make shadows not be visible from below. Right now this is my only nitpick for this mod.
Let me know if what I added in v1.85 solves this issue.

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Fri Dec 28, 2018 10:05 pm
by m8f
Wow, great!
Nash wrote:Let me know if what I added in v1.85 solves this issue.
Yes, it does.

One question: if early return is added after "bInvisible = true;", will it mess with clean-up? If not, it will probably improve performance even more.

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Thu Jan 03, 2019 6:54 pm
by Firebrand
This looks quite good :) and it doesn't add too much of a performance hit when being used on big maps, nice work!

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Sun Jan 13, 2019 9:31 pm
by MrJohnny
Just noticed that all it takes for shadows to spawn is for an actor to have the +ISMONSTER flag. Some mods make use of this to achieve certain effects, so it might be worth adding other conditions that must be met before the shadows are spawned to avoid conflict with other mods. A flag like "+COUNTKILL" should do the trick.

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Sun Jan 13, 2019 9:48 pm
by Nash
Pompous Seed wrote:Just noticed that all it takes for shadows to spawn is for an actor to have the +ISMONSTER flag. Some mods make use of this to achieve certain effects, so it might be worth adding other conditions that must be met before the shadows are spawned to avoid conflict with other mods. A flag like "+COUNTKILL" should do the trick.
Using a monster flag on something that's not meant to be a monster. Coming from this community; why am I not surprised?

This is the kind of stuff that makes Graf's blood boil... :mrgreen:

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Mon Jan 14, 2019 2:06 am
by Gez
But then monsters that don't count for kills (and yeah, those exist and are legitimate, for example for passive wandering creatures, or invincible turrets, etc.) wouldn't get shadows. So it'd still not be compatible with mods.

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Tue Jan 15, 2019 11:36 pm
by Rip and Tear
I have found an issue: Hexen’s Stalkers still have shadows when they are underwater. I haven’t look into the code yet so I’m not sure, but I suspect that the +INVISIBLE flag not being accounted for.

Re: SpriteShadow (Duke3D Shadows) v1.85 [more optimization!]

Posted: Wed Jan 16, 2019 10:17 am
by NightFright
Is it possible to have a version without the menu entries actually (maybe with values you can edit directly in the script files instead)? Somehow I preferred the "load and forget" approach from the 1.6 release. I like autoload stuff to be invisible.