[r300] 32bit png sprite offset shows improperly

[carlcyber]

In the example file, the offset for all the baron of hell pngs are correct. And it works well in zdoom. In gzdoom, those baron of hells dance up and down.

Demostration file

In zdoom


In gzdoom

[Graf Zahl]

'smart' sprite clipping currently does not work with images that have so much empty space below their bottommost pixel.

[Enjay]

The problem here is the amount of empty space you have left at the bottom of the sprites. GZdoom is trying to compensate for the known issue of "floor clipping" of sprites and moving them up to avoid the bottom of the sprite being cut off. The jumping effect only happens if sprite clipping in the options menu is set to "smart". If you set it to never, then the sprites all sit low, if you set it to always then they all sit high.

IIRC, there is some code in GZdoom to try and catch situations where extra empty space may have deliberately been added to the bottom of sprites. My guess is that yours are right on the border of this particular bit of code - some falling within it and some without. Anyway, the fix is to remove the dead space below the feet of the barons in your pngs. Do that and they should all sit correctly regardless of how you have the sprite clipping option set.

[edit] Or you could say it in on sentence like Graf did. [/edit]

[carlcyber]

I originally made a black glow around the sprite (only have to modify the alpha channel), then I found this problem.
Now I get it. Thanks for your explanation.