views:

725

answers:

6

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.

+1  A: 

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.

Andy West
But what if my character is walking on a bitmap.I am drawing a bunch of tiles to one bitmap. pretty much the environment is considered to be one image. and then there is the sprite that sits on top. In this case, should I just check the tile position.
numerical25
Yes, just as Anon has said, testing against tiles with basic, primitive shapes like squares or rectangles is much more efficient than pixel-based collision detection.
Andy West
@Numerical: The idea is that you don't test an object's position against what you draw, you test it against your logical representation of the world. Bitmaps are just the end product - not something your game logic should depend on.
Kylotan
@Kylotan: Well put. It's similar to the way physics engines work (Havok, ODE, etc.). Physics calculations are done against a simple representational model that is not visibly rendered. That model is logically attached to the "pretty" 3D model that gets displayed.
Andy West
+3  A: 

"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.

Anon.
So I am guessing the best solution would be to check the tile position and see if it is walkable or not. if not, dont let me go within a certain distance of the tile. Thanks for your comments by the way
numerical25
If you have regular tiles, it's better to make use of that than it is to test for collisions against the pixels of that tile.
Anon.
have you done any bliting games or anything of that nature before?? If so, how much of the enviroment is blit objects and how many are display objects
numerical25
+1  A: 

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).

Allan
+3  A: 

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 .

AdityaGameProgrammer
+1 I've used this kit and nothing else compares (other pixel collision detection kits have odd bugs in corner cases (like nested objects or rotation))
Cameron
+1  A: 

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).

Grant Peters
+1  A: 
  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.

AdityaGameProgrammer
Actually, seeing how the graphics are done via bezier curves, you can get exact intersection points quite easily (complex maths to get the equation, but simple for the processor to chew through once you've done the math), combine that with bounds checking and you can do the collision tests extremely quickly, much faster than doing a blit like method between different shapes (though picking in a 2d environment is a different story). The discussion you higlighted doesn't really contain anything of significance (the method highlighted is a very basic idea) and I have done a similar implementaion.
Grant Peters
can you please provide a link to the Flash implementation of the method stated by you. i am unable to get around the time taken for math involved in this implementation and its pixel perfectness.
AdityaGameProgrammer