On Fri, Apr 2, 2010 at 10:46 PM, Tyler Nielsen <tyler.niel...@gmail.com>wrote:
> Kai, > > Let me start off by saying, enjoy your easter. if you can't get to this > for a few days, no big deal. > > Ok I know this e-mail is from a while ago, but this I found the problem > with jumping and it relates directly to this. Basically we have a position > of the tile you stand on when starting of: [256, 480, -5] - [384, 624, 0]. > When we check for a collision (in collide_with_objects) we call > object_in_bbox, which takes the position and adds SolidMinPos([0,0,-5] in > this case) and doesn't find the collision until we fall too far. I sort of > found this out already (but didn't realize the significance) when I modified > the line: > shape->collide (collisionData, > (*i)->Min-(*i)->get_object()->entire_min()); > > In doing that I 'normalized' the position on the objects (0,0,0) so when it > adds shape later it is correct. > > Basically there are two ways of fixing this. One option is to change the > definition of EntireMinPos and SolidMinPos, so they are always relative to > the lowest values. (In the case above, SolidMinPos would then be 0,0,0). > But I'm afraid that will have far reaching effects that I can't anticipate. > Two, I can subtract out entire_min when we are getting the solid_min and > solid_max from chunk_info. We are already doing it in a few other places, > so maybe I can clean the whole thing up a bit as I go. > > I just wanted to run the whole thing by you and get your take before I go > too far down this path. > > Tyler > Hmm as I wrote this I realized there was a simple fix for the jumping issue. We may still want to clean things up a bit though. I don't like just subtracting EntireMinPos because it doesn't seem clear reading the code why that's happening. I'll try to clear that up. Tyler
_______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
