SpriteShadow v2.0 (now built into GZDoom 4.6.0!)

[dpJudas]

Well, I wouldn't implement shadows this way because it could cause the shadow sprite to overlap a nearby sprite.

What you are describing sounds a bit like glPolygonOffset, except just for sprites' depth sort value. It is essentially just a value to add - in the software renderer to VisibleSprite::idepth before sorting is called. I don't think this will be very good for shadows, but maybe it will be useful for other things. Either way, it probably just requires a idepth += actor->ZDepthSortOffset at the right location.

[MrDowntempo]

Could the original Sprite be subtracted from the shadow? That would make the shadow transparent where the original Sprite shows up which would make the shadow seem like it was behind the Sprite

[ZZYZX]

Well, I wouldn't implement shadows this way because it could cause the shadow sprite to overlap a nearby sprite.

I'm pretty sure that's what Duke does. Perfect compatibility! .

[Nash]

Plus there's this Nash's modular clothing that actually requires having actors on the front of the base one.

Yeah about this - every day I get the funny feeling that this is relying on some undefined behavior (I basically control the layer order by specifically defining the spawn order of the clothe pieces) and one day this will just stop working and my characters will start running around with their bodies being drawn in front of the clothes...

[Major030]

Sorry for being a noob but how do i use this mod? The .zip file had no pk3 or WAD in it so idk...

[Nash]

Major030: Just drag the ZIP on to gzdoom.exe

And actually, my file was packaged wrongly (I meant to give it the PK3 extension, not ZIP :< My bad, will fix for next version)

[Major030]

i did that and i got this error message
Script error, "dukeshadow 1.2.zip:zscript.zsc" line 1:
Unexpected identifier
Expecting end of file or 'include' or 'extend' or 'class' or 'struct' or 'const' or 'enum'Execution could not continue.1 errors while parsing dukeshadow 1.2.zip:zscript/dukeshadow.zsc
EDIT: nvm it works on gzdoom 2.4 but not the devbuild i have, strange.

[Nash]

If I had a penny... :P

Please use GZDoom 2.4: viewtopic.php?f=1&t=55739

[Major030]

omg you sent that as i edited my post lol, btw great mod

[Nash]

Update March 25th 2017 (version 1.3)

- Fixed shadows not appearing on players when exiting and entering new levels
- Fixed player shadow build-up in multiplayer
- Your player's own shadow will no longer be drawn in first person (very evident in laggy multiplayer games - the shadow's position cannot update seamlessly with the prediction-adjusted player position)

[MrJohnny]

Okay, so... have the shadows always had issues with lifts? I haven't checked this out in a while, so I just popped in and decided to see how the new version works. I discovered that if a monster is on a moving lift (up or down), the shadow "lags" behind the monster, and doesn't catch up until the lift stops. As the lift descends, the shadow hovers in the air; as the lift ascends, the shadow sinks into the floor.

EDIT: It seems that adding +MOVEWITHSECTOR fixes the problem.

[Hellser]

Update March 25th 2017 (version 1.3d)

Fixed that for you.

But honestly, I quite like the concept of this mod. Keep up the great work, Nash.

[Nash]

Mini update coming soon. Will fix the lift bug and a bug that accumulates the player's shadow in hub levels (I could sworn I already fixed this...)

Thanks for the idea, Hellser. >8D

[sylandro]

I think I found another bug. When playing cooperative, I cannot see the other players' shadows, only my own (the same goes for them: they can only see theirs and not the other players). I did a printinv and everyone has the Z_ShadeMe item, Also, when a player respawns, the shadow becomes visible. It's weird.

The monsters are working fine, though.

[Nash]

Thanks! That's probably some noob-tier (on my part) if/else oversight I suspect. Will be fixed in next version. :D