I thought I may as well open source this as it may be useful for some of you.
Let's start with the all important caveats.
I'm not going to be showing you a load [ Or any in fact ] of benchmarks or examples, I can think of nothing more boring to do. Either take it on faith that it's fast, or just use it to look through and nick the bits that may be helpful to you. I'm not trying to prove a point with this that my code is so l33t. I've found it useful, if you do to then cool, we're both winners. If not, well you've not lost anything have you ?
Again another life's too short thing, I really can't be bothered with sorting out a license for this, is it MIT or is it GPL ? I don't really care, it's not something I hold close to my heart, it's a bit of code to do a job. If you do tinker with it and make it better it would be nice to share what you've done, if you make a game using it and you make a ton of money, great. A credit or even a shout about it would be cool, but if not, then I'm not going to hunt you down with an angry mob.
The only thing which would piss me off is people passing it off as they're own, but we've got a wanker free readership here so it's not going to be any of you guys, and there's not a lot you can do about the sort of idiots who would do that anyway.
There may be bugs, there was some experimental iPhone and pixel bender stuff in there which I've just ripped out. If you spot any thing dumb please flag it up, it would be nice to have a fixed version available here for people coming to this further down the line.
Ok, let's go over the usage.
The static Canvas class is the main part of it, it's what makes it tick. To set things up just do a simple,
stage is your stage ref ( Surprisingly enough ), next up is the size of the canvas ( The canvas is the bitmap which everything will be blitted into, the viewport property ), and are we going to be transparent or using a background ? You decide with a boolean. You can also pass a fill colour as the final parameter if you don't want to use a bitmap as the background.
Next in our hierarchy is the PlayField. Think of this as your container sprite. I don't know about you, but I miss working with layers in as1 via the timeline, so I've always simulated them with container sprites. PlayFields are pretty much that, eg
var defRect:Rectangle=new Rectangle(0,0,600,500);
From memory I don't think the engine actually does anything with the rectangle we pass to it, I think I was planning to do some simple clipping, but never got round to it, but pass it in anyway it doesn't do any harm.
When it comes to rendering the display, the Canvas class loops through all the PlayFields in the order they are added, so the gridPlayField in that example will be plotted first, then the baddiePlayField and so on. It's a simple way of simulating layers / depth.
Finally we're onto the Bob class. These are your Blitter OBjects, your software sprites. To create one,
var temp:Bitmap=new playerBM();
You just pass it the bitmapData you want, and then add it to your PlayField. The Bob class has all the properties you'd expect, and supports animation too ( So bob.gotoAndStop(bob.currentFrame+1) works, check through the class on how to pass it an animated sprite sheet ).
Where possible I've tried to make things as close to the display list as possible, there's no need to be forcing a new syntax onto yourself.
Like the PlayFields these are plotted in order ( The PlayField is basically just a list of its children ), so add them in the depth order you want, exactly like adding children to a sprite.
As with all blitter engines there are restrictions due to using copyPixels, so forget all about rotation and alpha and blendModes. A pity, and I did start with a ComplexBob class that used Draw() for those things, but to be honest it was a real arse ache, and it's quicker to attach the bitmap directly than to use draw ( The downside to that being the bitmaps have to be above the canvas, there's no way to slide them in there between PlayFields ).
There are quite a lot of properties and methods available to you in these classes, auto-complete is going to be your friend with this.
One last thing, the Canvas uses the RENDER event to refresh the screen, so there's no need to call anything in your mainloop, just by altering a bob's x position it'll refresh for you ( If you're not going to use the actual package, I'd recommend having a look at the Render event stuff, you should find it quite useful if you're doing something similar ).
Guess I should just link to it now, download me here.
As always abuse the comments. Just to sound a grumpy shit for one last time this post, this isn't some big open source project that I plan to expand and maintain, if you find bugs or even better come up with fixes, then yeah they'll be added with a great big bag of thanks from me, but this isn't my life's work. Feature requests are going to be ignored to be honest, it is what it is.