Projectiles jump over ledges

[Hirogen2]

Observed this for long, but what exactly causes this to happen?

[Enjay]

What is the problem? I don't see anything unusual happening.

When the level starts, the fireballs pass over the "bridge" and I don't see any obvious deviation at all in their path. If I raise the obstacle by 1 unit (or more), they hit it and cannot pass over the bridge. If I lower it, the fireballs continue to pass over the bridge unimpeded. In Zdoom I can see the sprite graphics extending into the floor of the bridge, as expected, and in GZdoom they get clipped but, other than that, I can't see any obvious problem at all.

[CaptainToenail]

If sprite clipping is set to always, projectiles do indeed seem to change direction slightly, this is probably what he observed

[Enjay]

Ah yes, that will probably be it.

[Hirogen2]

That was it indeed. Thanks guys!

[Graf Zahl]

Ok, what precisely was going on here? Is there something I can fix or not?

[Hirogen2]

The sprite TROOU0 is quite badly offset (the coordinates stored with the lump). Something like 4 pixels too low in my subjective view — compare with PLAYW0. Other sprites may be affected too. Setting sprite clipping to always nicely worked around those glitches — especially since in GL mode the sprites seem to be (legitimately) cut off by the floor plane.

[Gez]

A simple solution is to autoload a little wad which contains the offending sprites modified with a more appropriate offset.

[Hirogen2]

Another would be to have the sprites not clipped by the floor, like it happens in software mode. Not sure if that is possible or feasible though. Since I only took note of this for projectiles, maybe the "sprite clipping" option could be enhanced to carry an "always but projectiles" option besides "never", "smart" (what does that do btw?), and "always".

[Gez]

Another would be to have the sprites not clipped by the floor, like it happens in software mode. Not sure if that is possible or feasible though. Since I only took note of this for projectiles, maybe the "sprite clipping" option could be enhanced to carry an "always but projectiles" option besides "never", "smart" (what does that do btw?), and "always".

Yeah but then that may break other things, such as floorhugging projectiles. If there is a bug in a data file, the best cure is to correct the data file, not to create a workaround in the code, which will require another workaround because it'll break something else, and in turn this new workaround the workaround will require another workaround which.... You get where I'm going.


As for clipping sprites exactly like software does, if it were as simple as that I'm pretty sure this would already be in GZDoom.


And it seems this thread could be considered both [Not a bug] and [Not ZDoom].


PS: Smart clipping adjusts only the sprites for players, monsters and pickups. It doesn't adjust corpses other than ice corpses.

[Enjay]

Ok, what precisely was going on here? Is there something I can fix or not?

IMO, nothing to fix. With sprite clipping set to always, the imp fireball sprite is raised so that the bottom of the sprite sits on a floor at a height just tall/low enough for the projectile to pass over it. So, as the projectile passes over the floor, the sprite jumps up so that it is not clipped by the floor and then back down as the projectile passes off the floor.

With sprite clipping set to smart or never, this doesn't happen. Given that the sprite is doing what the settings say it should (ie it is always being moved to not clip into the floor) it seems like GZdoom is doing what it has been told to.

The TROOU issue is separate (but why "always" was being used). It is offset quite low - being set 5 units into the floor (quite a lot for a short sprite) but as has been said, that's a [Not Zdoom] thing. BTW, the equivalent PLAY sprite is set 4 units into the floor (so not a huge difference between it and the TROO one). However, the shape of the sprite graphic itself makes the effect less obvious as the PLAY sprite has a fairly narrow bit at the bottom which won't be so obviously missed when clipped compared to the relatively wide base of the TROO graphic.

[Graf Zahl]

I have added an offset modification long ago but never wrote a definition file for it.

I just added one that only addresses the IWAD sprites not affected by the 'smart' setting. Hopefully with this present it's not necessary to use 'always' to avoid certain problems.