Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'm assuming that each call to your <code>Update</code> method you move the ball to a new position by adding the velocity vector scaled by the frame time, then test the new position. Is this correct?</p> <p>In this model the ball is occupying a series of point locations without passing through the intervening space. This type of motion causes a variety of problems due to an effect called 'Tunneling'. This happens when an object moves fast enough that it appears to pass through objects partially or completely.</p> <p>Imagine that your ball is moving vertically at 3 pixels per frame and is currently 1 pixel away from the edge of a block. Next frame, the ball will move to a position that is 2 pixels <em>inside</em> the block. Since the ball and the block can't overlap, this is an error. Perhaps not a <em>huge</em> error, but still not right.</p> <p>As you have discovered, the error really bites you when you get to the corners. If the ball's new position is overlapping the corner of the block it becomes more difficult to determine the correct action since the closest edge of the block may not be the one that you passed through (conceptually) to get to where you ended up.</p> <p>The solution to this is call Continuous Collision Detection. Each time you move the ball, you have to check the entire path of motion to determine if a collision occurs.</p> <p>The simplest method - although certainly not the fastest - might be to use something like <a href="http://ericw.ca/notes/bresenhams-line-algorithm-in-csharp.html" rel="nofollow">Bresenham's Algorithm</a> to plot the positions your ball occupies along the line of motion. Bresenham's will give you a reasonable line of motion with integer steps - one step per pixel. These steps translate to coordinates that you can use to detect collisions.</p> <p>You can speed things up slightly by pre-calculating whether it is <em>possible</em> for a collision to occur, and if so with what. If you have 100 blocks on the screen you don't want to check every one of the for every step. You can narrow the range by calculating a rectangular bounding box for the total movement (current position to end position) and build a list of all blocks and other objects that fall within the box. No results means no collisions, so this is a good way to short-circuit the expensive operations while also making them less expensive in the end.</p> <p>There's a lot of work to do to get it perfect, and a reasonably large amount to get it close enough. Google <code>continuous collision detection</code> and <code>game physics tunneling</code> for more information on the topics.</p> <p>If you can get away with it, something like [Box2D] or Farseer will give you some interesting options for handling this. Of course you'll probably spend about as much time re-tooling your game around a physics engine as you would have solving the original problem :P</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload