Codetopia

A place to talk about things related to XNA, .NET, and enterprise application development.
Welcome to Codetopia Sign in | Join | Help
in
Home My Book Blogs Forums Photos Files Roller

Chapter 28 Pixel-perfect collision

Last post 03-13-2008, 4:09 PM by groundh0g. 1 replies.
Sort Posts: Previous Next
  •  03-12-2008, 4:34 PM 433

    Chapter 28 Pixel-perfect collision

    Hi all and beyond,

    I was just wondering what would be the best way to use the results of a pixel perfect collision. For example, Right now I am working on a space game where you must fly a small spacecraft through a tunneling system inside an astroid which is in fact a huge sprite. My problem is I can't really tell what to do when there is a collision. Ofcourse I could always say go back to where you came from before the collision, but I really need some smoother solution where the ship would bounce of the wall instead of going back. I was thinking of using the closest pixel to the center of the ship to use as a sort of orthogonal direction on the wall, but checking every pixel on distance would be far to slow.

    anyone got any idea what so ever? I would really appreciate any comments.

    gr Vincent
  •  03-13-2008, 4:09 PM 437 in reply to 433

    Re: Chapter 28 Pixel-perfect collision

    The others may have some other ideas, but here's my lame take on it ...

    It'll be hard to create a general purpose implementation for this. Based on your description of the problem, you're thinking of a collision as being between two pixels. That's true if you just want to know IF two sprites have collided, but it's not enough information to know what to do after the collision. You need to know the slope of the wall at the point where the collision occurred.

    For a simple example that is easily generalizable, consider a pool table. Collisions in that environment are between circles (really spheres, but we're talking 2D here) and flat, parallel walls. The general-purpose response to a collision in that scenario is easy.

    Two balls collide if their centers are closer than a single ball's radius, and a ball collides with a wall if the distance from the closest point on the wall is less than or equal to it's radius. When a collision occurs, you can use simple formulas to determine the new direction and speed of the ball (angle of reflection, conversation of momentum).

    In your spacecraft-in-a-tunnel game, it's not quite that simple. You're actually concerned with the direction the craft is facing (in addition to the direction and speed in which it's travelling). And the walls aren't regular shapes, so the angle of reflection depends on the angle of the wall segment that was struck.

    For a tunnel, I'd take one of two approaches:

    1. Build my tunnels from (or augment my level data with) vector data, rather than pixel data. Think of the tunnel as a 3D mesh, locked in a single plane. When you detect a collision, dig a little deeper to compare the ship's location, shape, and mass with the angle of the two closes vertices in the wall's "mesh".

    2. If the tunnels are smooth (like a sewer system), rather than rough (like an cavern or canyon), you could run a line down the middle of your tunnel paths instead of mapping the walls to vector-based boundaries. Then, you can determine the slope of the wall at the point of impact using the tunnel's center line.

    Whatever implementation you come up with, you'll want to account for fringe cases like when the ship hits a wall head-on (or nearly head-on). In that case, it would be unnatural for the ship to suddenly reverse direction. You might want it to bounce back a little or explode.

    -- joe


    There are 10 kinds of people in this world -- Those that can count in binary, and those that can't.
View as RSS news feed in XML
Powered by Community Server, by Telligent Systems