Pixel Perfect Collision
Here's a challenge that's way beyond me at the moment :
Engineer pixel perfect collision without the use of any special game programming functions or libraries.
—hartnell
Pixel Perfect Collision
Forum
» Making Games / General Programming
» Pixel Perfect Collision
I don't really know, but I think I may need something like that for TrackDown.
The sight of the enemies- I want them to only be able to see you when you're actually in front of them, not just whenever you're in the vicinity. So for that I need to at least be able to take the rotation of the enemy into account rather than just a normal square collision check in the area.
Well, here's a tutorial which actually describes both how to do it as well as how to do it as fast as possible using bitwise operators AND, OR and shift.
Basically you first make a bit-mask of the two sprites, so that each bit represents 1 pixel. Then when the two bounding boxes intersect (a quick test) i guess you calculate the common area of the two colliding bit-masks and using the shift operator for aligning the two bit-masks you can test the area of intersection very quickly. It's maybe a little complicated.
Here's a little quote:
The idea is to identify the common area of the two masks, and then perform a bitwise AND to check if they share a common ’1’- bits. This way we can check 32 bits at a time which speeds up the test enormously
Personally i would rather creating a polygon around each of my objects and then test if these collide mathematically. Doing so allows me to rotate my sprites easily without it effection collision detection.
I have a great book about real time collision detection, so if you want to try this, let me know :)
In 1990 the Amiga magazine 'Amiga Format' ran a 7 part tutorial on professional games design.
They discussed Collision Detection in part 6 using the 'Bit-Mask method', mentioned by u9.
I've taken all 7 parts of the tutorial and uploaded them here. (5.72 MB)
You're the man! This reminds me of the good old days. And for all of you programmers out there, if anything, the golden coin of this series is found on part 4, page 2:
NEVER use 'magic numbers' in your source such as the statement […] you may remember as you are working on the project, but what about in a year's time when you come back to re-use some of this source?
P.s. Magic numbers are numbers used in your code. All numbers in your code should always be defined as constants, both for re-usability and readability.
Matt, you rock. :)
Magic numbers are numbers used in your code. All numbers in your code should always be defined as constants, both for re-usability and readability.
I know this… but I can't seem to follow the practice. :)
—hartnell
yeah, me too… I'm terrible at using magic numbers (i.e. i use them all the time).
Yeah, I also use them often. But it's funny, just recently it came to my mind the fact that I shouldn't use them as much as I should (as in, before I read your post about it).
Keeping things as variables also makes it a lot easier to change said magic numbers when you need to, then you only have to change the variable rather than go through the code and change each instance of the number.
Well, it's just a way to optimize the detection. You could also just use normal bitmap images and compare the pixel for pixel in the two images where they overlap. The bit-mask just speeds this process up as a 32bit cpu can AND 32 bits each cycle which corresponds to checking 32 pixels.
/forum/t-25495/pixel-perfect-collision#post-
