Troy GilbertGamedev 2.0

This looks pretty expensive! I wonder if some caching could be used to avoid lots of the expensive work in here. I’ll bet a lot of this would be made possible if you knew what kind of assets you were using. For example, if your assets never resize, you could probably keep using the same BitmapData over and over. Just a thought. Thanks for the article!

I’m trying to make a simple car game where the player uses the keys to make the (rectangle) car go around the track. When it hits the wall (for now) I just want it to back up at a certain speed so that the user can correct it and continue around the track. I’m using your class, calling it in a function that’s fun on an ENTER_FRAME and it works fine, to an extent.
I’m having problems though, because, obviously, in a car game the car doesn’t always face the same direction: it gets rotated. What happens to me is that when the rotated car hits a wall, sometimes it gets stuck in the wall and doesn’t bounce back. Any ideas as to what I need to do differently so it bounces back no matter the orientation?

This collision detection code is not best-suited for this scenario. For what you’re describing, I’d recommend checking out one of the rigid body physics solutions. Box2D is well-maintained, well-documented, and has a healthy featureset. APE, which would handle the scenario you’re describing, is very, very easy to use (though doesn’t appear to be maintained any more).

I can't figure out how to use this class :( I figured out Skinner's class perfectly, since it's AS file followed a structure I'm used to work with. This, I can't. How do I pass the movieclips to be tested and how do I return them?

Thanks for your work.

Well I think I got it. But nontheless, this solution still doesn't solve the rotation problem. My transparent objects, when rotated and still separated by as much as 20px (joined by transparent pixels of course) performs true on the hit test. Am I doing something else wrong?

Thanks!

[...] can use a pixel-perfect collision method (such as this one), but these are very slow — you’re making Flash check every single pixel of one object [...]

Hi, i'm just using your detection script.
First of all, i'd like to say it is great, works very smooth.
Second, considering the topic of this blog you shouldn't endorse nor advice using CDK as i come directly from it, and i call tell you is very heavy, the drop perfomance is noticeable.
CDK is good, and has plenty of funcitons, but for gaming is not suitable.

Question:
I was looking at the code of this detection script, but as i dont really underestand it so much, i cannot judge how perfomance-friendly it be.

So i dare to question you some things:
-do you thing it has a good preformance, do you think could exist some others ways to achieve perfect collition detections with a huge amount of perfomance difference?
-Trying to get collition detections with pixelPrecise=false attribute is better than hitTestObject?

Great, thax

This runs great so long as I don't set the “pixelPrecise” argument to “true”. Once I do that then the collision rectangle never get made, its width and height remain at 0. I think I'm implementing this correctly and I've toyed with the tolerance and with various colliding objects, all to no effect. When the boolean is set to “false” this runs like a dream. Much faster than the CDK, which I've also used and was disappointed with the ridiculous lag.

This runs great so long as I don't set the “pixelPrecise” argument to “true”. Once I do that then the collision rectangle never get made, its width and height remain at 0. I think I'm implementing this correctly and I've toyed with the tolerance and with various colliding objects, all to no effect. When the boolean is set to “false” this runs like a dream. Much faster than the CDK, which I've also used and was disappointed with the ridiculous lag.

YOU RULE

THANKS :D

nice code but it doesn’t seem to work well with rotated mc’s

I’m seeing something similar to what Evan’s seeing. Take this example:

var wrapper:Sprite = new Sprite();
addChild(wrapper);

var glyph:Sprite;

var existingGlyphs:Sprite = new Sprite();
for (var i:uint; i < 50; i++)
{
glyph = new Clef();
glyph.x = i * 10;
existingGlyphs.addChild(glyph);
}
wrapper.addChild(existingGlyphs);

glyph = new Clef();
glyph.y = 20;
//addChild(glyph);
//wrapper.addChild(glyph);

var collision:Rectangle = PixelPerfectCollisionDetection.getCollisionRect(glyph, existingGlyphs, wrapper, true);
//var collision:Rectangle = HitTest.complexIntersectionRectangle(existingGlyphs, glyph);
existingGlyphs.x += collision.width;
trace(collision);
addChild(glyph);

Notice that glyph is not added to the stage until after the collision detection. The traced output is (x=-14, y=-26, w=0, h=0). However, if I add the glyph to wrapper before the detection, the output is (x=-9, y=-25, w=22, h=48) which is correct. Note that these “glyphs” are symbols with a registration point in the center. I’ll try to dig into it a bit but if you post a fix that’d be awesome to hear about.

yep pixelPerfect = false returns a 0 width/height rectangle. Any fixes? I’ll dig around and see if I can’t fix it myself.

Ah, nevermind, works like a charm; parent cannot be the stage object or a Sprite. Use a MovieClip.

Men! Try use “this” on commonParent:DisplayObjectContainer argument.
I used stage but didn´t work.
With “this” all works fine!!

Wow! Thanks man! Much better performance than the Collision Detection Kit.

[...] Troy Gilbert’s Pixel-Perfect Collision [...]

Hello !

Actually, it’s possible to optimize it a little bit :)
intersectionRect is useless, it’s defined by the bounding box of the tested object.
Math.floor is useless too if you base the whole work on  bitmapData.
Matrix calculations are useless too : only 4 substractions is needed. 
BlendMode is useless : if you base the find-color function on static colors, you can easily know (via trace) what color you’re looking for if collide

Here is an exemple :

//1) At the beginning, before the collision detection process :

//bgData is the bitmapData of the background
//mcData is the bitmapData of the moving object

var bgData:BitmapData = new BitmapData(100, 100, true, 0xff123456);var mcData:BitmapData = new BitmapData(100, 100, true, 0xff987654);

//We assume that the position of the background  are 0,0
//mcx = the position x of the moving object 
//mcy = the position y of the moving object

var mcx:int = 75;var mcy:int = 95;

//I set defined colors to my objects//I want a red-color with 0.5 alpha for the backgroundbgData.colorTransform(bgData.rect, new ColorTransform(0, 0, 0, 1, 255, 0, 0, 255));
bgData.colorTransform(bgData.rect, new ColorTransform(1, 1, 1, 0.5)); 

//and a green_color with 0.5 alpha for the moving object 

mcData.colorTransform(mcData.rect, new ColorTransform(0, 0, 0, 1, 0, 255, 0, 255));
mcData.colorTransform(mcData.rect, new ColorTransform(1, 1, 1, 0.5));//I set a new Rectangle  and a new Point that I will use in collision detection processvar rect:Rectangle = new Rectangle();var pt:Point = new Point();//I get width & height of background into variablesvar bgw:int = bgData.width;var bgh:int = bgData.height;//now, still at start, I want to know what will be the collision colorvar test:BitmapData = mcData.clone();test.copyPixels(bgData,mcData.rect,new Point(),null,null,true);var collisionColor:int = test.getPixel32(1,1);//2)now that all is ready, I can process the collision detection fastly :)//I’m looking for bounding  intersectionsrect.width = bdw – mcx;rect.height = bgh – mcy;if(rect.width < 0 || rect.height doesn’t colliderect.x = mcx;
rect.y = mcy;var productData:BitmapData = mc.clone(); productData.copyPixels(bgData, rect,pt, null, null, true);trace(“collisionRect = “+productData.getColorBoundsRect(0xffffffff,
collisionColor , true) );++