Sorry for the gratuitous pun but I couldn’t resist 
I’d been meaning to do this for a while but this weekend I replaced my BitmapData based renderer for my game with one that utilises the new hardware accelerated graphics of Flash Player 11 (formally Molehill). Rather than getting into the low level code required to make a custom renderer I decided to use one of the 2D frameworks that the Flash community have come up with. I chose the excellent ND2D by Lars Gerckens because it seemed to have all the features I’d need and the demos blew my socks off (press space to cycle through the demos on that page)! I like Lars’ implementation of Sprite Clouds (a group of sprites with a common texture), they work perfectly for game entities like projectiles and particle effects.
My renderer is un-optimised (I was eager to get something up and running as soon as possible without doing too much refactoring) and I’ll be making some changes to bring the game more in-line with the ND2D display list paradigm, but I think its a good start. I’ve noticed a huge performance boost already, the game is running at a smooth 60fps on my PC now. The next step will be to up the game viewport size as this was previously limited by how many tiles I could render every frame using BitmapData.copyPixels() without performance suffering. I’ve also noticed that screen tearing has completely disappeared (it was a real pain when using the BitmapData method).
If your planning to get involved with Flash Player 11 game developement then there are a few things to bear in mind when designing your application structure. The biggest one is that all Stage3D content is rendered on a layer (or layers) below the main flash stage. So, regardless of where your ND2D world is added to the display list, your game content will be behind all other display objects. As a result you need to cut a hole through all display objects that make up your UI (backgrounds etc) so the Stage3D content can shine through. Another thing thats worth implementing from the get-go is a time based (rather than frame based) update system. This is standard game dev practice but I’ve only just got into it. Instead of moving items the same distance every frame (I believe) it is better to move items based on the time since the last frame was rendered. All ND2D sprites have a step() method that accepts an ‘elapsed’ parameter. The ‘elapsed’ param is the number of seconds since the last update and all movement should be based on that (“sprite.x += 1 * elapsed” rather than “sprite.x += 10″). The resulting movement is much smoother as it compensates for variation in the number of milliseconds between updates caused by CPU/GPU usage.
Dabbling with this framework has got me really excited about the possibilities that will arise when this version of Flash Player penetrates through the market enough to start using it for client projects!
