Chimera Posted October 18, 2016 Share Posted October 18, 2016 This is a bit of a simple question I feel, but I have been struggling to get it right for a while. I am using super simpler AABB collision in my rect based game. I have a bouncing rect which behaves funny when it collides with the player, who is also a rect. The ball 'sticks' and bounces a bit inside the player before bouncing away. I don't have gravity at the moment, or any advanced collision logic. All I am doing is inverting the x or y vectors based on whether the bouncing ball hits the top or sides of another rect. I feel like to resolve this issue I should get the displacement value from the overlapping rects and then 'push' the overlapping rect (the ball in this case) away from the second rectangle by using the displacement value as a positive offset. To do this I feel like it would be cleaner to separate the collisions to different sides, or corners? Does anyone have any experience in implementing a slightly more advanced version of AABB? Quote Link to comment Share on other sites More sharing options...
mattstyles Posted October 19, 2016 Share Posted October 19, 2016 You just need the size of the intersection to be able to 'push' one object away from the other, but, you may have a bigger problem. Normally you'd have some variant of this sequence of events: * Decide where to move next * Check that location is available * Perform the move So, in your issue (as you've described it) you have all the action occurring over two ticks, or, two iterations through the above sequence. Given that you're inverting the velocity of one of the objects, you should only collide once, i.e. if a x movement of 10 brings the ball inside the player (collision) then a movement of -10 in the next tick will move it out again (no collision). This isn't what you're describing though. It's almost like you're checking collisions more frequently than updating movement, which you should avoid (rendering less frequently is fine, but the simulation needs to perform all steps, usually in a set order). However, there is an additional case here, where both entities are moving, which I suspect might be your issue. A 'push' to resolve overlaps sounds reasonable and I'm pretty sure that is exactly what many physics libraries do. Obviously the less overlaps you create the better, it also makes your bounce code more complex as you'd need to work out the resultant velocities of the 2 (or more) entities for each collision, simply inverting an axis or two won't help. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.