r4264 said:
Improve determination of when a sprite should be drawn before a masked wall.
Concretely, in the "behind, outside" case, draw the sprite early if any of its
2 or 4 corner points are behind the masked wall, and inside the cone or on the
other outside.
Concretely, in the "behind, outside" case, draw the sprite early if any of its
2 or 4 corner points are behind the masked wall, and inside the cone or on the
other outside.
Plain Simple Garek, on 18 January 2014 - 05:36 AM, said:
Assuming that eventually the mask drawing system is going to be restructured, would it also be possible to fix all those clipping issues in classic where floor aligned sprites etc overlap each other depending on the viewing angle?
On one hand, this is a separate issue -- sorting the sprites among themselves. More broadly though, it can be seen as an instance of a similar problem, namely that for a given set of geometric objects, it can be easy to partially-order that set (i.e. totally-order certain mutually disjoint subsets), but hard to find a total order on the whole set.
The basic problem with incorrect floor sprite drawing is this: Build sorts all sprites by the 2D Euclidean distance of the eye to the sprite, projected to the viewing ray. In this sketch, that's d*cos(a):
^ y | x +---> +---0 sprite | / d*cos(a) |a/ d := dist(eye, sprite) |/ ----------v----------
There are various problems with such an ordering. First, it changes dependnig on the player angle. That could be remedied by using the distance directly instead, but it would still remain incorrect for a set of floor-aligned sprites: the right way to order them is by considering only the z distance between the eye and the sprite, i.e. by the function abs(sprite z - eye z).
Well... one now has the fun task of finding a suitable comparison function between any two sprites inducing an ordering that the real "occludes" relation would give (we assume that it can't contain cycles like A occludes B occludes C occludes A).