Sprite clipping failure

I have determined the cause of the FreeDoom Imp sprite clipping problem for the software renderer.
(The FreeDoom Imp sprite has a tail that can be seen through floors and at other times.)
It is a software renderer problem only.
The problem affects prboom too and I expect many other ports, especially those close to vanilla.

It actually affects most of the sprites, it is just most visible with the FreeDoom Imp. Sprites with large guard bands of transparent on each side seem to be immune because the clipping error involves pixels that do not show.

In R_DrawSprite, there is a test of seg scale against sprite scale.
This test causes the bug by rejecting a line segment that is further away than the sprite, from the clipping.

Consider a floor with two holes, one of which contains an Imp. The imp is clipped by the sides of the hole. We the viewer are looking at the hole a little to one side, so the hole sides are clipping the sprite too.

The bug is triggered if there is a vertex on one side of the hole, such that the sprite is just closer. The further line segment will have both of its vertexes further away than the sprite. This causes R_DrawSprite to reject it based on scale tests upon those endpoints. However, this line segment still needs to clip parts of the sprite that extend out in that direction. It is actually the floor that extends from that line segment that should clip the Imp tail. This floor can extend from the line segment all the way to the viewer.

Consider the second hole, behind the first. It also has seg that that are subject to the same tests. However, the floor that extends from it terminates at the edge of the first hole, and because of that it must NOT clip the sprite.

I have not found a way to correct this bug.
It looks like it will be complicated.

Makes sense, however, I would love to see a screenshot of exactly the scenario you describe - it's difficult for me to visualize.

A screenshot is hard to get, it happens so quick and erratic.
It is better to look at the wad yourself.
The tail is visible through the floor to the right of the pistol.

The test wad: http://www.speedyshare.com/files/30052792/imptail.wad

DoomLegacy screenshot:
>doomlegacy -iwad freedoom.wad -file imptail.wad
http://www.speedyshare.com/files/30052809/imptail_dl.pcx

PrBoom screenshot: http://www.speedyshare.com/files/30052822/imptail_pr.bmp

wesleyjohnson said:

The problem affects prboom too and I expect many other ports, especially those close to vanilla.

I've just tried with ZDoom and Eternity, both ports which have greatly modified the software renderer.

And well, both are affected by the Freedoom imptail glitch too.

So I think it's safe to say it affects all software renderers out there.

One can also observe this with the Arch Viles arms.

I thought it was to do with part of the sprite clipping into the sides of the hole because it's wider than it's hitbox.

I have not YET seen it from an original sprite. I wonder if the id guys noticed this and fixed by limiting their sprites, because it would be so difficult to fix the code.

It appears that it would require adding code to clip the sprites with floors to fix this (ceilings too probably).

I think it was the other way around: They never noticed because their sprites did not significantly exceed the bounding boxes.

I think the sprite graphic width relation to the monster size does make a difference. The monster size keeps the sprite away from the sides of the hole. If all the graphic pixels are within that distance, it is much harder to get a situation where they must be clipped.

The Imp tail trails out after it. It would be hard to draw an Imp with such a tail and keep in within the monster size box. A few of the other monsters also have appendages.

However, that does not explain all the visual effects, which sometimes show as a sliver of the body of monsters. The body would be expected to be within the monster size box.

Having to fix DoomLegacy to get monsters unstuck from walls (some TNT monster placements overlap the wall considerably) I expect that the engine may have few pixels overlap with the wall before it stops the monster. Thus there is a few pixels of the sprite graphic edge that may be exposed to this clipping failure. Best explanation that I can think of right now. Anyone else got an idea ?

Oh, that problem. Fixing it might be expensive and might break some effects. I'll investigate further.
A clue: Open the imp tail.bmp image and draw a vertical line from the right of the tail all the way up. See where it touches that groove? That column is key to the clipper deciding to draw the sprite. But, of course, the thing's width should attempt to match the sprite sizes better.

In that image, the edge of the hole is broken into two by that little step. The farther seg I was talking about is the edge of the hole on that upper step. That seg is over the visible imp tail.
By scale comparisons, its end points are both farther away than the sprite itself. But as you can see, clipping from that seg is still needed.