gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > Collision detection based on pixel color?

#83468 - Lini - Tue May 16, 2006 3:33 pm

How would I do collision detection based on pixel color? I want the shots to collide with a ship only if there are non-black pixels touching.

Would I do loops to check the pixel color? Is it even possible?

I'm using HAMLib/VisualHAM, so if anyone can help, I'd appreciate it.

#83479 - naleksiev - Tue May 16, 2006 4:29 pm

You know the ships position and the bullet position.
So here are X and Y of the pixel that you need to check

x = bullet.X - ship.X;
y = bullet.Y - ship.Y;

if x < 0 || y <0 || x > ship.width || y > ship.height // outside of the sprite
not collide
else
check what is the color in the ship sprite on pisition x, y. If you have animation check this for the current frame only

and you know if there're more bullets and ships just make this in loops

#83561 - tepples - Tue May 16, 2006 11:51 pm

Lini wrote:
How would I do collision detection based on pixel color? I want the shots to collide with a ship only if there are non-black pixels touching.

Would I do loops to check the pixel color? Is it even possible?

Yes, it'd be possible to check the pixel colors, but it'd be dog-slow. Is there a reason why you can't use geometric methods? What shape is your ship?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#83574 - shen3 - Wed May 17, 2006 1:31 am

You might search on google for pixel perfect collision detection.

1 fast method is using 1-bit bitmaps for each sprite, which can then be quickly checked for overlaps using bitshifts and boolean logic. This method allows for doughnuts, or gaps in the middle of sprites. These bitmaps will need to be generated by some tool.

another method is having a tool generate a list of start x co-ordinates + length for each row of each sprite, then using these to check the collisions. This doesn't allow for holes in the row, so it is less pixel perfect then the first method.

A really really slow method would be to check the actual sprite data for each pixel you are worried about. This can work if you are only checking a small number of pixels per frame, or speed isn't an issue for some other reason.

Shen

#83653 - poslundc - Wed May 17, 2006 6:17 pm

I'll just chime in agreeing with tepples that geometric collision is usually more than sufficient for the vast majority of games.

Pixel-level collision is slow and can even provide a worse gameplay experience in many situations.

Dan.

#88982 - Dracker - Thu Jun 22, 2006 5:51 pm

poslundc wrote:
I'll just chime in agreeing with tepples that geometric collision is usually more than sufficient for the vast majority of games.

Pixel-level collision is slow and can even provide a worse gameplay experience in many situations.

Dan.
A LOT of highly acclaimed commercial games use geometric collision. For instance, Metroid Fusion. (easy to tell in the Nightmare battle, where you can pass right through one of his "ears" without damage.)

Try making your non-black part of the ship a separate geometric area, and do collision detection on that.