For high-res texture/sprite projects, sprite-fix patches, music add-ons, music randomizers, and other graphic/sound-only projects.
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Sprite shadows are now built directly into the engine as of GZDoom 4.6.0!
You can enable it in the Display Options menu, or you can use SpriteShadows v2.0 to enable sprite shadows without user intervention (user still has the option to turn them off).
Lastly, you can enable or disable sprite shadows on actors individually by using the +CASTSPRITESHADOW and +NOSPRITESHADOW flag!
Requires GZDoom 4.6.0 or higher!
Update May 23rd 2021 (version 2.0)
- Update mod to utilize engine-native sprite shadow rendering.
- Relicense to MIT.
Spoiler: Old Updates
Update July 10th 2019 (version 1.9)
- GZDoom version bump to 4.1.3.
- Do not serialize shadows. This means the shadow actors do not get written into saved games. Might help with multiplayer saved game stability.
- Github repository added.
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
Update December 20th 2018 (version 1.8)
- Implemented max shadow distance to help performance with slaughtermaps
- Fixed a null pointer access
Update December 19th 2018 (version 1.7a)
- Experimental performance update
Update January 26th 2018 (version 1.6)
- Fixed crash that could happen sometimes when a monster is killed or destroyed from the map
Update June 14th 2017 (version 1.5)
- Shadows no longer draw in front of players and monsters (thanks ZZYZX for implementation idea)
- Mod renamed to remove Duke3D from the name
Update June 14th 2017 (version 1.4)
- Fixed player shadow build-up in hub-based maps
- Fixed not being able to see other players' shadows
- Fixed shadows not staying firmly on moving lifts
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)
Have fun!
Though not required, I would appreciate it if you credit "Nash Muhandes" if you add the event handler-based mod (SpriteShadow v2.0) into your mods or standalone games. No need to ask for my permission to use it; just credit me!
Yessss! I've wanted something like this for a long, long time!
Nash wrote:Since extending Actor isn't allowed in ZScript, making this work with ANY monster in any mod is going to be tricky
Honestly, making this work with EVERY actor may not actually be a good idea - not every actor will look good with this, resulting in weird things like shadows for fire on torches etc.
Kinsie: I think I can limit it to actual living monsters by just doing a check for the +ISMONSTER (bIsMonster in ZScript) flag, although of course this won't be 100% fool proof against people who are doing hacky things with Things that aren't supposed to be monsters but are still flagged as such...
TerminusEst13: Have fun! When/if I update this to be more modular, I'll update this thread. I don't think the way I did it in that proof of concept is the best way (I can't imagine copy/pasting all that into every monster definition... a better way would be if this thing just works in the background with minimal code)
Additionally, I'm not feeling too good about that hack I did to force the shadow to be drawn under the monster (that is, spawning the shadow -> spawning a copy of said monster -> destroying original/map-placed copy of monster, in that order)... o_O
Yeah, there's definitely a lot of avenue for tweaking to make things more streamlined, but I think that's half the fun of things like this. It's like a puzzle game!
You'll probably solve it first, but I still like fiddling and experimenting.
Thank you very much again for this!
Last edited by TerminusEst13 on Wed Jan 18, 2017 4:22 pm, edited 1 time in total.
Yes, because if I don't extend Actor, I'd have to end up coding the functionality and a bunch of "replaces" for EVERY kind of monster (what I am doing in the latest version of the WAD in the OP). And it won't cover mod monsters without manual intervention.
The whole point of putting it in Actor is so that every monster in any mod, ever, will have the functionality, because when it boils down to it, everything you place in the map descends from Actor.
Simply checking for bIsMonster is enough to filter the effect to only happen on actual, living monsters... should be a non-issue, in most cases. So don't worry, the shadows won't be spawned for items, decorative stuff, etc...
(and again, I am already doing a monster check in the WAD in the OP - this shadow won't appear on the player, even if you give yourself the item - it will only appear on monsters)
Nash, I gotta say this is a gamechanger. It looks good in screenshots, but actually playing is incredible. I never knew how much I needed this until now. This tiny change makes Doom look so much better.
Thank you! I really want to make this modular and be autoload-friendly, so I'll just wait for "extends Actor" to be possible.
I also could submit it as a GZDoom feature but I think that's way out of scope for base engine functionality.
EDIT: Found a bug
Monsters that disappear when dying (Lost Soul, Pain Elemental) will leave their shadows behind despite their corpse not existing anymore. Will be fixed for next version