How to stop hardware renderer cutting of bottom of sprites

[MartinHowe]

This has been asked in the past, but every reply I can remember seems to require a degree in computer graphics to understand it. I'm a programmer not an artist or mathematician. I just about know what a vector is. The image below is a non modified stock burning barrel, no ZScript or DECORATE involved, only DOOM2.WAD is loaded. You'd think ZDoom would at least leave things of id's own alone!

So please, can anyone tell me how I can say to the engine: "DO NOT MESS WITH MY SPRITES. LEAVE THEM THE HELL ALONE!"

Please?

[Enjay]

The problem is that the affected sprites have offsets that put the bottom of the sprite below the floor line.
The software renderer just draws the sprite on top of the floor (you can see similar effects when mid textures are offset down into the floor/up into the ceiling).
The hardware renderer can't do that.
So, the options are
a) move the sprite up so that the bottom of it sits on the floor. However, this makes the actor appear taller.
b) accept the fact that anything offset below the floor will get cut off.

There are a few options in the GZDoom menu to address option a). From memory the options are something like - move nothing up, move monsters only, move everything.

And just for completeness, here are some graphics that I made many years ago to explain it.





and an example from Doom2 map02 that clearly shows the health bottles and zombie lowest few pixels below the floor (not in the hardware renderer obviously).


So, no, to answer the question, you can't get 100% vanilla appearance, but you can set things to show the whole sprite if you want that to happen.

Personally, when I am making new sprites, I try to make them so that the bottom few pixels are reasonably level (i.e. not with one foot much lower than the other, for example) and I give them offsets that places the bottom pixels on, or near, the floor line. Such sprites will look much the same in hardware or software.

[MartinHowe]

And just for completeness, here are some graphics that I made many years ago to explain it.

Thanks, Enjay, that makes more sense now. I knew about the offsets but never understood what they were for; something to do with perspective, I guess. I get when monsters are walking downstairs and so on, but why it was done to items, I just don't know.

The hardware renderer can't do that.

But why can't it? Surely the programmer has complete control over how the image is rendered when they program the graphics card. Or would it mean having to replicate software rendering on each sprite anyway? What a mess. Presumably newer games, using models, don't have this issue.

The options for sprite adjusting at the moment are Always, Never, Smart, Smarter, Forced Perspective. The first two are obvious, but maybe the devs can explain what the others mean.

[dpJudas]

The modern GPU does not give the programmer complete control over how an image is rendered. The acceleration works by forcing certain constraints on the program and then accelerating the hell out of that specific method. Simply put, the GPU can only draw triangles. Either not clipped at all, or clipped by the depth of what was drawn prior, using something called a zbuffer. Every sprite you see if made out of two triangles billboarded to face the camera when drawn by the GPU.

Essentially the problem is that the software renderer does visibility clipping in a different way than the GPU hardware. Technically speaking with the GPU being correct - the sprites in Doom always went into the ground - the software renderer's simplified rendering strategy just didn't clip it. There are strategies a hardware renderer could use to emulate the clipping but its not trivial. GZDoom never implemented it and thus the only option left is to either clip them into the ground or move them upwards. The various modes you list is what strategy it uses to try offset the sprite to not get the zbuffer to clip them.

[MartinHowe]

The various modes you list is what strategy it uses to try offset the sprite to not get the zbuffer to clip them.

Thanks

Experimenting, I've found that Forced Perspective gives the best results for me, but would like some sort of description of these modes and what they actually do; they're not described in the Wiki.

[phantombeta]

They're actually described in the wiki, just buried in an obscure page (link), except for Forced Perspective.
"Smart" and "Smarter" both apply some checks so not all sprites are pushed up off the ground.
"Forced Perspective" is a newer one that emulates the effect by, AFAIK, offsetting the sprite towards the camera so it isn't clipping, and changing its size so it looks the same size it would at the correct depth. The downside is that it can have issues with clipping.

(namely, I've noticed monster sprites clipping through thin walls sometimes. They specially have a tendency to clip through those "fake walls", where you put a texture in the middle texture slot of a two-sided linedef so the player can't see through it, but monstes can pass through)

[MartinHowe]

They're actually described in the wiki, just buried in an obscure page (link), except for Forced Perspective.

Thanks, phantombeta

So my comment previously, about having to replicate software rendering on each sprite anyway, in fact seems to be roughly what Forced Perspective (in essence) actually does.

[phantombeta]

So my comment previously, about having to replicate software rendering on each sprite anyway, in fact seems to be roughly what Forced Perspective (in essence) actually does.

It's not really what the software renderer does. The software renderer occludes the sprites based on the lowers and uppers of the walls, floors and ceilings can't actually occlude anything in it.
The "Forced Perspective" option is a hack to vaguely replicate the look through forced perspective tricks, but like I said, it has issues with sprites clipping through thin walls. (this isn't an issue in the software renderer)