Wednesday, May 21, 2008

AS3 Blitting and Collision Detection

After figuring out Blitting (caching everything onScreen into a single bitmap), I have been struggling with how to tackle collision detection. Since everything has been compacted into a single bitmap you would have to figure out the collisions by using the data alone. After picking Jesse Warden's brain for a bit, it seems that you either have 2 options.

1. You use a tile based system. This would be great tile-based games... (duh). And it would be great for the background/foreground of a sidescroller since they are going to be tiles anyways.

But I am not excited about using this for the characters/enemies/missles/etc of a side scroller. I feel it would be too restrictive to the characters to contain them within a bounding box and it would be a bigger hassle than it would be worth.

2. This brings us to option 2. Which is to use the blitting for the background as I mentioned above, but then use sprites/bitmaps for everything else. I will still try to cache as many animations into bitmaps as possible, but I will let them remain as their own display object on the screen and not merge them with the background. That way I can still do the hitTest and I will not be restricted to bounding boxes that a complete tile based system would create.

5 comments:

Al said...

Generally in a game your physics and graphics are independent of each other.

So your game loop might look something like this:

function enterFrame(e:Event):void
{
// make everything move
doPhysicsStep();

// see if anything is colliding
while(isColliding())
{
// resolve your collisions
resolveCollisions();
}

// last but not least, render it
render();
}

Then you can blit your graphics at full speed without worry of any overlap or any need for sprite hitTests or so on.

HTH

Ickydime said...

I am with you on separating the steps, but how are you going to check isColliding() w/out either restricting your character to a geometric shape or by using sprites and hitTest?

If my character had a simple geometric bounding box I could check to see if it was hitting something using math. But how would I check for a complex character that is constantly changing and moving? It seems like it would need to be on the stage in that case, which is why I am leaning towards option 2.

Al said...

The problem with hitTest is your graphics will be seen to visibly intersect before you resolve. This is ugly, and can quite often lead to things getting stuck, either in a recursive loop or just stuck in a wall for instance.

For the geometric version:
First of all I would check all bounding boxes/circles for an intersection. This is a really quick test to make.
(It can be sped up even further if you have a vast play area using various techniques such as http://lab.polygonal.de/articles/recursive-dimensional-clustering/).

If that check returns true you then have the option of testing in greater detail. At this point you could have your shape broken down into smaller circles/boxes/polygons and then test against them.

However, if your object is anything other than a box or a circle, collision detection isn't going to be your problem! Resolving the collision properly will be. For the most part simple geometric shapes are enough for fast paced games.

If you want realism and want a solid physics engine, which will allow you to de-couple your graphics from your physics head here:

http://box2dflash.sourceforge.net/ and the forums, http://www.box2d.org/forum/index.php.

Ickydime said...

Thanks for your advice and suggestions. I appreciate it. I will check out the physics engine this afternoon.

I updated my stance and made a new post. Please check it out here.

Tink said...

You might find http://www.tink.ws/blog/as-30-hittest/ useful