On Fri, Jan 9, 2009 at 10:05 PM, Kai Sterker <kai.ster...@gmail.com> wrote:
> For all three cases, it should still be possible to figure out which > object is in front and which is behind, which would allow for flawless > rendering. The current idea for that is to "change" objects so they don't overlap and run them through the same algorithm once more. Not entirely sure how "change" could look like. > I also believe that fixing the renderer uncovered a bug in the > collision code itself or -- more likely -- the code that retrieves the > objects to test for collision. Fixed that shortly after sending this email, as the cause was pretty much obvious. It's related to a design decision that bit me a few times already. Thinking about a redesign once alpha 3 is out. The problem lies in the representation of object shapes. Basically, the object sprite is assumed to sit a (0,0,0) and the actual shape is then relative to the sprite position. If an object is placed on the map, it's sprite has an absolute position in worldspace. However, the bbox is always at an offset to that position, so you see a lot code like pos.x() + shape.x() to compensate. Problem is, the bbox is used much more often than the sprite, so this is not only an annoyance, it's also a hit on performance. A better design would be to have object bboxes always start at (0,0,0) and rather specify an offset for the sprite. But first of all, complete the rendering. Might have some time for that tomorrow :-). Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel