Duke4.net Forums: Bug with masked walls - Duke4.net Forums

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Bug with masked walls

User is offline   Helixhorned 

  • EDuke32 Developer

#31

As of r4264, the two-and-a-half cases of improper sprite <-> maskwall ordering should be fixed. In hindsight, it seems pretty obvious how the behind-outside case could be made more precise:

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.



View PostPlain 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).
0

User is offline   Helixhorned 

  • EDuke32 Developer

#32

View PostHelixhorned, on 25 January 2014 - 05:45 AM, said:

we assume that it can't contain cycles like A occludes B occludes C occludes A

Oops, no we can't:

Attached Image: sprite_occlusion_cycle.png
(This obviously doesn't render correctly in classic.)

I was wrongly assuming that this would only be a problem with "sloped sprites" by only thinking about 3 sprites at once.

EDIT: Exercise 3: find the mistake and bad wording in my preceding post. Damn I suck :(.
0

Share this topic:


  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options