pixel collision detection for flash

Question

I was told the pixel detection is costly for regular windows games. Is this the same for flash ?? Or would pixel detection be lighter compared to other detections flash has to offer. Flash has the getPixel32 method which makes it easy for detecting pixels. If I am bliting my game, would it be wise to use getPixel32 for collision detection. Or should I just check for specific tiles ??

Is getPixel32 limited to the display object it is in ?? In other words, can I detect any pixel regardless of what layer it is on in the display list.

And lastly, I probably can figure this out on my own but I want to ask first to save me some time. But does anyone have any code or good sources on how to go about doing this if it is reasonable.

Answer 1

In just about any environment, I'd rather use primitives like rectangles and circles instead of pixels for my collision detection. You can usually build a reasonable representation of your sprites out of such primitives and get a real performance boost.

Answer 2

"Pixel perfect" detection is costly. Regardless of the environment.

Basically it involves first doing fast checks to eliminate as much as you can, and then walking through the pixels one-by-one checking for an overlap.

If you can get "good enough" collision detection without resorting to counting pixels, then do that instead.

Answer 3

the CDK by Corey oniel is pretty decent http://www.coreyoneil.com/portfolio/index.php?project=5. in his site you can see from the examples it handles a good amount of objects well. ave used it for my collision system and it was handling the detection pretty well.
i too am of the general idea to use the pixel perfect collision detection in games to make them more realistic. else like a majority of the flash games out there look like very badly pulled fake punches .

Answer 4

1. Alan, I would have to disagree because the pixel perfect collision detection isn’t costly depending on the method you use.
2. grant peters the traditional "pixel perfect" implemented well using blitting, would be far better than pixel perfect" collision calculated via concave collision algorithms You can follow the discussion here http://www.actionscript.org/forums/showthread.php3?p=959885#post959885
3. Generally speaking when dealing with pixel perfect collision detection depending on where you need it it’s a 2 step process based on the math involved

1. Detect collision-pixel perfect – done based on blitting its not costly for a good amount of objects. You can see it here

2. Handling the reaction after Pixel Perfect Collision – eg calculating angles, >proximity and such . a A proximity based reaction handling . b Reaction handling to ball –ball interactions.

Answer 5

To build on the ideas already listed here, you could indeed use a circle as the bounding object since collision detection is quick with them.

Then if a hit is detected you can then perform per pixel detection. This way you don't have to always be calling the expensive per pixel detection but will still ensure per pixel accuracy (if your game requires it).

Answer 6

I've got no hard evidence to back this up, but flash is predominantly a vector graphics application, hence, the "pixel perfect" collision can be calculated via concave collision algorithms (often they just break it up into a series of convex shapes. This means the collision detection could in fact be extremely fast (compared to traditional "pixel perfect" methods).

While implementing my own flash renderer, this is how I've handled the collision detection as it seemed the most natural due to the data I already had. It would make little sense to write a lot of specialized code to do something similar (ala the traditional methods of pixel perfect) with less accurate results (you don't want it acting differently just because you have it set to a lower image quality or zoomed in/out).

My advice, do a stress test on a minimum spec machine, if it's not fast enough, then implement a faster version (or possibly try implementing an acceleration structure of some sort, such as a quadtree).