Collision of Rotated Sprites
Ok. I realise collision detection has been discussed quite alot, but after doing a fair bit of searching through the forums and the web, I still can't find a solution to my problem.
I am working on a arial view car game (remember GTA 1 and 2?) and I am at the point where I need to handle collisions.
Most people seem to be using BoundingBoxes, which would work fine in a few situations, but in my case, drawing an axis aligned box around my rotating car would be far too inacurate.
I realise that the boundingbox class does not allow rotation as mentioned in this forum, so I am wondering if anyone is aware of an alternative solution.
I could solve the problem by creating a series of rotated square alpha images for my car to use when rotating, rather than rotating the texture programatically, then check pixels, however this is a very undesirable solution.
Can I draw a collision map of the contents of a boundingbox on the fly?
Is there a nice formula for checking collisions between rotated matrixes? Even so, I can't think how I would do pixel perfect collision detection.
Thanks in advance.
Lee.
[1134 byte] By [
Leedrick] at [2007-12-24]
Firstly anything that is a from above view means that all your collisions are in 2d so you can do almost everything as bounding rectangles.
Secondly you do not need to use a AABB, you can use a model aligned version (normally called an Object aligned bounding box OBB). The math for the collisions is a little more complex but since you are in 2d it will simplify it a bit more. Unless you really have to do pixel perfect collisions it is better to start with boxes - even if you jsut use the boxses to cut down on the actual collision tests.
Everything you need to know about collisions here http://www.realtimerendering.com/#colldet and I always find this useful too http://www.realtimerendering.com/int/
I'm afraid I don't have an example of sprite mask collision detection on me (I'm at work) but will try and sort something out soon.
I too am a novice so don't take what I say as gospel but the concept is sound. If one sprite mask overlaps another and you "AND" one mask with another, any remaining bits would indicate a collision has occurred.
You may already be using sprite masks to determine the transparency of the sprite itself. You could possibly re-use these to determine collision detection also?
cj.
Sprite masks were a necessity back in the days where you had to draw your own sprites to the display, however current hardware supports an alpha map in the sprite itself. You could extract the alpha map to get that which is essentially what ziggy does in his code with some optimisations.
The problem with any of these approaches is that when a sprite rotates you have to rotate the mask too and while rotating a sprite in hardware is trival, rotating the mask without the hardware is more of a problem. It would be much easier to define a vector based outline when the sprite is created and then use those for the collisions. They rotate easily - however automatic creation of them is not so strsaightforward.
