blog @ pebbl

Yes, it is true... and no I haven't converted Pebbl from a JavaScript game in to a bespoke CMS platform or anything mad... Instead I've decided to modify my Canvas Theory library so that it no longer uses Canvas as it's primary rendering system. Now this might seem a little bit illogical for something that started out as a Canvas & HTML5 experiment, but trust me I know what I'm doing ;) The new off-shoot library will be known as SpriteTheory.

Reasons?

Why? you may ask... well actually you most probably wont, but considering Blogs are a bit pointless if there is no need for explanation I'll ignore that statistical likelihood. The main reason for the change is purely due to optimisation, and also so I can prove wrong those out there who deem Flash (and it's contemporaries) to be extinct.

Most coders who claim Flash to be a dead parrot, and that HTML5 is the saving grace of all, have not tried to recreate what is achievable with Flash in HTML5. They have most probably just bundled together a nice slideshow and said "Hey... what was it we needed Flash for again?"... worryingly, some may not have even got that far and prefer to just mimic statements made by others. The fact of the matter is that Flash does a hell of a lot more that what is possible with pure HTML5 & JS - and it does it a hell of a lot faster. But anyways, before I start going off on one, I'll get to the point. I am not pro any particular technology, I just state what is and isn't possible at the moment (that may change of course). What seems not to be acceptably possible currently is to get good performance when running a sprite system using a full-screen canvas element across all the top browsers.

Excuses...

What...? I hear the non-existent critics expel in chorus. Not fast enough? But what about all the game emulators out on the web... or the 3D demos? Well, it seems that nearly all the emulators I've seen operate on a pixel by pixel basis (or small sprites) and usually on canvas elements with dimensions of about 320x200... tiny. This is not what I wanted for Pebbl, I wanted the full area of the browser to be in-use. And well, any 3D environment I've come across using Canvas is either hardware excelerated (using 3D context) or put together in a very specific and limited way... I wanted Pebbl to be 2D and not limited at all.

After spending some time developing a Canvas specific library, I found that no matter how optimal my code was, the clearRect and drawImage methods of the Canvas Element were taking most of the rendering time. So no matter how good I was with my code, I'd still always be limited by something I couldn't alter. As I said before this may change in the future, we shall see. But after finding this out, and making sure I was using my own "only draw what's needed" and "only clear what's changed" system, I was still finding slow-down after implementing less than half of what I wanted to. I was also finding that the frame-rate was wildly different across each browser. This was not good enough, plus it also seemed a bit pointless, when browsers implement their own redraw system anyway.

Conclusions...

So, after a bit of kicking myself for trying to re-invent the wheel and not going for the more elegant solution in the first place, my new library now works based on old-school absolutely positioned HTML Elements with CSS Transformations and Canvas enhancements. The Sprite interface is nearly almost the same, so I shouldn't have to do to much rewriting, all I have to do is dump most of the Canvas draw stuff, and optimise for dealing with HTML Elements instead. No more redraw problems, or slow-down. My main reason for going down the Canvas route in the first place was because I wanted to have pixel-perfect collisions and pixel affects. Considering most browsers handle the creation of many small Canvas elements with ease, and allow these Elements to be treated like any old DIV Element, I don't need to use a full Canvas "Stage" as-it-were and can instead treat each Sprite that needs the advanced methods as a separate Canvas element.