EUREKA!!

October 28, 2007

I had a moment of epiphany for the collision detection of my game. And it works! Perfectly! With over 100 objects on the stage. No lag what so ever from what I can tell.

How it works

Pretty easy actually, once I thought about it. Each sprite on the stage has a corresponding collision sprite, just like in the old system. The flaw I ran into was that I had to either A) Draw a separate collision buffer for each of the objects on the stage (resulting in lag from redrawing an image multiple times) B) if I drew a single map, then the object would collide with itself, since it would register it’s own collision sprite. The solution was so simple I can’t believe I didn’t think of it earlier.

Right now, the collision sprite is automated by the code. When I create a new sprite, a collision sprite is automatically made for it. The collision sprite is exactly twice the size of the normal sprite with a color of 0x88000000, IE semi-transparent. This way, the sprite will only detect a collision if the sprite interacts with another collision sprite. The value of a single collision sprite is not strong enough to stop it.

I’ve also created two functions to update sprite registration points (right now it’s just set for the middle of the image) along with updating a collision sprite. This way, in the future, when I start creating background images, I can make a custom collision sprite so that it doesn’t fill the entire screen.

You can see all this here. Pressing the space bar will show you the collision buffer instead of the frame buffer.

On a side note, it does seem that WordPress doesn’t like Safari, so I’m going to have to switch back over to Firefox when I want to post on WordPress. No big deal, just an inconvenience.