DRD Team

when i made a monster with a scale of 2.0, his feet were in the floor. . so too high scale makes a monster's sprite go in the floor a bit.
this bug started happening in 9.25 I think (since i tried gzdoom 9.21 and it doesnt occur there)

Check the offsets of your monster's sprite and also what you have the "Adjust sprite clipping" value set at (OpenGL menu). If your adding new sprites - for GZDoom, I always make sure they are offset so that their Y value is the same as their height. This means the bottom of the sprite sits exactly on the floor. Lower values than that will stick the sprite below the floor slightly and perhaps scaling is confusing the clipping adjustment that GZDoom does?

Enjay wrote:Check the offsets of your monster's sprite and also what you have the "Adjust sprite clipping" value set at (OpenGL menu). If your adding new sprites - for GZDoom, I always make sure they are offset so that their Y value is the same as their height. This means the bottom of the sprite sits exactly on the floor. Lower values than that will stick the sprite below the floor slightly and perhaps scaling is confusing the clipping adjustment that GZDoom does?

i tried the clipping adjustments but it doesnt work. and the sprites are all fine. as i said this doesnt happen in previous gzdoom versions. only in 9.25 and later and it only happens with monsters with a high scale.

Well, it does seem that versions 25 onwards are less forgiving of offsets than previous versions (see the other thread that related to this). However, I have a sprite that is 216 units tall, scaled with a factor of 0.4 and correctly aligned. It sits perfectly on the floor just as it should and just as it has in all versions of GZDoom.

Enjay wrote:Well, it does seem that versions 25 onwards are less forgiving of offsets than previous versions (see the other thread that related to this). However, I have a sprite that is 216 units tall, scaled with a factor of 0.4 and correctly aligned. It sits perfectly on the floor just as it should and just as it has in all versions of GZDoom.

hmm that might be the cause. anyway im talking about BIGGER scales not smaller. not something like scale 0.4 but something like 2.5 (since smaller scales works fine for me also.. no matter how big the sprite is)

It seems that I fixed a coordinate miscalculation when I changed the renderer's coordinate system to world units. One particular calculation for the sprite clipping code scaled improperly in the old code but doesn't in the current one.

The old code apparently lifted objects too far out of the floor when they got cut off. The new one treats cutoffs of -10 and lower as intentional lower placements and doesn't lift such objects up. It seems to be the same effect responsible for the other sprite placement (non-)bug reported recently.

one more question. i made an imp with a scale of 2.0 (the whole reason why i posted this bug) but his sprite is also a bit in the floor. does this mean i need to transfer all of the imps sprites to my wad to fix it or is there some special command for this?

I can't tell anything without seeing the sprite.

Graf Zahl wrote:I can't tell anything without seeing the sprite.

there are no sprites needed. it uses the normal doom imp sprites. (which works just fine on scales smaller than 1.0)

The problem is that the code that lifts the objects up treats a value of -10 as a threshold. Everything that extends deeper into the floor is not lifted. In many cases these are items used for some special effects and the code can't differentiate between something scaled out of proportion and something that genuinely needs a large offset. I might be able to change this so that for large scales the amount of pixels is used but don't expect this too quickly. This isn't something I'll update for.

Graf Zahl wrote:The problem is that the code that lifts the objects up treats a value of -10 as a threshold. Everything that extends deeper into the floor is not lifted. In many cases these are items used for some special effects and the code can't differentiate between something scaled out of proportion and something that genuinely needs a large offset. I might be able to change this so that for large scales the amount of pixels is used but don't expect this too quickly. This isn't something I'll update for.

ah thanks . i can wait.