Sprite Collisions

Started by
7 comments, last by malborojones 12 years, 11 months ago
I have just about everything sprite wise set up now (translation, scaling, rotation etc.) and it's all working perfectly. I have a basic collision detection set up that just checks the sprites rect and that works fine for square non-rotated sprites, what I'm wondering is how to go about detecting collisions on more complicated shapes and adjusting everything to work with scaling and rotation

I've seen one way in which you read the pixels into an array where transparent and opaque pixels are different values e.g. 0 and 1 but I have no idea how this would work for sprites which rotate after the textures loaded, plus I have no idea how to get the pixels of an image one by one yet tongue.gif
Just wondering how your views are on this? Where do I start? What's the fastest way? it doesn't need to be pixel perfect but I'd like it quite close. Any links to some detailed tutorials?

Thanks, Mal ^_^
Never refuse a cup of tea, that's how wars are started.
Advertisement
paruse the math and physics forums, there's always good things there.

Also you could look into "axis aligned" collision, or "rigid body physics". Sorry I'm not a physics guru in the slightest, but these are the types of topics I google when I need to write collision code over again or refactor my own workings.

*edit* also for alot of my physics requirements, I tend to fall back on already built libraries... I prefer box2D just cause I'm used to it. but I've heard chipmunk is pretty fast (I also believe box2d was originally based on chipmunk). I use Box2D in my framework and it was pretty easy to wrap it up to plug into my existing code.
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.
Just took a look at box2D, it's not quite what I'm looking for, I've already got some basic rectangle collision, that's the only thing I could use from box2D, I don't see how that would work with images?? I can see it coming in handy with the more physics based collision.

What I'm looking for is a way to tell if images are overlapping, I don't really want any physics atm. box2D could help with rotation e.g. rotating a box around the sprites centre and using it for collision but what about if a sprite isn't actually touching the sprites coloured parts? I don't think I'm making much sense today rolleyes.gif
Never refuse a cup of tea, that's how wars are started.

Just took a look at box2D, it's not quite what I'm looking for, I've already got some basic rectangle collision, that's the only thing I could use from box2D, I don't see how that would work with images?? I can see it coming in handy with the more physics based collision.

What I'm looking for is a way to tell if images are overlapping, I don't really want any physics atm. box2D could help with rotation e.g. rotating a box around the sprites centre and using it for collision but what about if a sprite isn't actually touching the sprites coloured parts? I don't think I'm making much sense today rolleyes.gif


Collision detection is physics. Also box2d supports polygons, or you could even just build you body out of several smaller shapes. Unless what you want is actual pixel perfect collision, then yes, You're going to have to compare pixels, and not shapes. That doing basic shape detections first will help limit the amount of pixels you have to compare.
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.
Yep, I think I'll use box2D for the basic collisions from now on but how is the pixel testing done? I have no idea where to start unsure.gif
Never refuse a cup of tea, that's how wars are started.

Yep, I think I'll use box2D for the basic collisions from now on but how is the pixel testing done? I have no idea where to start unsure.gif


box2d doesn't do pixel perfect collision, it a rigid body physics library. Do you really need it to be pixel perfect? Other than games like 'Worms' I doubt there are many games that use perfect collision. Take for example the majority of FPS games. The model they use to do collision with the player, tend to be inaccurate enough that you can actually hit the target without hitting the visual representation of them. Aslong as you build your shapes close enough to the visual form, the player will never notice what is going on behind the scenes.
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.
I know, but it's more or a 2D game engine I'm building, basically I want there to be a choice of pixel perfect or just simple box collision. Anyway it isn't that much of a necessity at the moment, I might just add the box2D stuff to the simple collision I have now and come back to it later.
Never refuse a cup of tea, that's how wars are started.
Pixel-perfect 2D collision is much more complex than bounding-box collision, ESPECIALLY if the objects are able to rotate or scale. The general method is to have a bitmask for each object, which is then shifted to match their relative positions and then ANDed together - if two objects overlap, this will result in a bitmap that contains a "1" for every pixel that overlaps. If the objects are able to rotate and scale, that means the corresponding bitmasks have to be rotated and scaled as well - which often means writing a software rasterizer just to deal with this (although it's possible to make use of the GPU to assist with this).

(Another option is to store the left and right extents of the object for each scanline - but this method only works with vertically-monotone objects, and is not practical with rotating objects.)

The simplest option is give each object a collision shape defined by a set of several bounding boxes (this is the technique used by 2D fighting games, because it provides more accurate collisions for complex shapes and allows different parts of the object to have different collision properties) or, even simpler, bounding circles (since circles are rotationally invariant, collision detection is no harder if the objects can rotate, and additionally, circle collision is incredibly simple - if the distance between the circles' centers is less than the sum of their radii, they're colliding).

It's possible to make use of hardware acceleration to assist with per-pixel collision - but I doubt there are libraries for this, which means you'll be writing the shader code yourself.

The simplest option is give each object a collision shape defined by a set of several bounding boxes


Yup, it was something like that I was thinking, and maybe use something like box2D to make a body of boxes/circles which are attached and get them to rotate around the sprites pivot at the same time as rotating the sprite.

I did some tests with DarkGDK last night and realised that it doesn't even support pixel perfect collision, I was pretty sure it did before but I must have been imagining things x)

Anyway, thanks for the advice, I'll have a play around with box2D today and just improve on my box collision. ^_^
Never refuse a cup of tea, that's how wars are started.

This topic is closed to new replies.

Advertisement