Troy GilbertGamedev 2.0

I've finally gotten around to updating my pixel-perfect collision detection post (which is by far the most popular post on this blog with 48+ comments and a double-digit percentage of all my pageviews). Of course, now that I've gotten around to updating it there's not much point, as others have improved upon and trumped what I had. So, I'll just provide a quick recap of their pursuits (and my version of them).

First, The Actionscript Man grabbed my version, Grant Skinner's (which mine was indirectly based on), digested them, then spit out a new one that eliminated some draw calls. He even made a nice little app that lets you toggle between the various versions and compare them. The only drawback of his version is that it assumes the two objects have the same parent.

Next, the venerable Tink posted his version that uses the same technique as The Actionscript Man but factors a more complicated parent-child relationship. Tink's still assumes that both objects are on the stage. His code also gets bitten by a bug I've run into related to localToGlobal and nested SWFs (though I still haven't explored it enough to write about it yet), as discussed in the comments. Tink added an "accuracy" parameter that basically scales the bitmap used for testing up and down. I've not found this makes enough of a performance difference to warrant the dramatic differences it can make in a pixel-perfect test.

So, I updated my version to include the rendering method Tink and The Actionscript Man used, and included the "common parent" math my original one had. The upside of my version is that it doesn't care whether your objects are on the stage or not, just that they share a common parent.

Finally, if you really want some sophisticated, fully-featured, pixel-perfect collision detection *and* handling, check out Corey O'Neil's Collision Detection Kit. I haven't used it yet, but it looks pretty comprehensive with good performance.

I discovered last week that scale-9 grids only apply to a DisplayObject and its content, but not its children. At first, I thought, "what!? why not!? that's dumb!" But, after a bit a reflection I realized that it would be *very* tricky to cascade a scale-9 transformation down a display list. I'm not going to attempt to explain why, but just imagine the scenarios where child DisplayObjects straddle the scale-9 grid and you'll realize it quickly moves into "very hard" (and likely slow) territory.

For my scenario, though, the child DisplayObjects simply provided some runtime configurability that once set could be "baked in." This allows you to take the shortcut of flattening the display list to a single bitmap, then applying a scale-9 grid to that. Unfortunately, the Flash Player doesn't allow you to set a scale-9 grid at runtime, probably due to some pre-calculations it does or special structuring of the data.

Searching for answers along these lines I ran across this fantastic post from Ahmed Nuaman:

Scale Any DisplayObject with My ‘ScaleObject’ Class

His theory was dead-on: take a DisplayObject, render it to a bitmap (to flatten it), cut that bitmap into 9 pieces, then override your new class's width/height properties to apply the scale-9 math to the individual pieces.

What I didn't really like was the roundabout way he solved the problem. First of all, the code was far too verbose for my tastes. It also wasn't self-contained, relying on an external bitmap utility function. But most problematic was the use of shapes with bitmap fills: I may be wrong, but I don't see any advantage to this, and it has the distinct disadvantage of being more complex that straight bitmaps and likely less efficient internally in the Flash Player. So, I fixed all that.

NOTE: The width and height properties specifically don't call the super setters. Doing so causes Sprite to attempt and scale its contents by adjusting scaleX and scaleY.

I'm pretty sure I've mentioned Picnik before. I got a reminder this evening about updating my expired credit card (for my annual premium). So, I visited the site. I hadn't been in probably six months.

I know they use Flex to build the site (which is what we use for Mockingbird). I haven't read anything about what specifically they do (though, I'm about to go googling that after I post this). Whatever they're doing, it's silky smooth.

For all those folks that say "why do we need Flash on the web?" send them to Picnik. They'll tell you that you can do most of that stuff in JavaScript (not anywhere as smoothly with most web browsers). They'll argue that an app like that should be native -- except that if it was the development cost would have been significantly higher and it would be functionally less useful for users who use multiple machines. The point is that Picnik was made in Flex, by incredibly talented designers and developers, and it was not made in those other environments. There are clearly advantages to the Flash platform that don't exist elsewhere, and those advantages are critical for the right application. Best tool for the job.

I know we made the right decision with Mockingbird (to have it built on Flash). I may be tempted at times by the extra horsepower others may offer -- but in the end, the Flash development environment and distribution platform is a warm, comfortable embrace.