It will be interesting to see if these sorts of techniques will become more useful in the future. The iPhone, Palm Pre, and all Android enabled phones come with good javascript support which means--depending on processing requirements--they could all support this sort of game out of the box. Does this mean that javascript based RIAs will be an increasingly attractive alternative to native apps?

Hey, I'm the author of this library. To be honest I have never tried to use ExCanvas or any other Canvas replacements scripts for IE with this library because I supposed it would run really slow. Thanks for the tip, I'm going to try it out.

I worked on this several months ago and never really had a second look because of lack of time. New job and all. I always wanted to come back to this though and polish some stuff like sound support (would have to be flash i guess), mouse support, some optimizations (did some tests creating space invaders and found some very real possible improvements, by for example using the experimental canvas.drawString available in some of the nightlies of (proper) browsers), and some other minor quirks.

If anyone has any questions or just wants to discuss something with me about the internals or possibilities, you can contact me at tommy@extjs.com

I started writing Asteroids in Javascript is anyone's interested: http://users.tpg.com.au/_dp//dave_asteroids.html

Still a work in progress, but it's the first thing I've written in JS.

3rd time in one week: please add the one line of HTML to that page that you'll need to support IE as well.

You're mistaken that IECanvas will make your game slower in IE than it is in Firefox. Test it out, and you'll be surprised. IE has a much better rendering engine than FF, and even with the added overhead of converting all canvas calls to their SVG equivalent, it's still noticeably faster.

So yeah, please fix your thing. It's one line of HTML fer cryin out loud!

(nice effort, by the way)

Am I reading this right? Are you actually saying ExplorerCanvas (canvas on top of VML) is faster than native canvas in firefox, webkit, etc?

I have some experience with this -- my site uses canvas / ExplorerCanvas quite a lot -- ExplorerCanvas is both buggy and extremely slow for any kind of animation. Particularly long running animation (as in games). I wish it wasn't so.

VML may or may not perform well, but it's a different kind of api than canvas. In VML, like SVG, you're intended to draw a bunch of shapes and then manipulate them. To animate a circle crossing the screen, you draw the circle and the move it every tick. The library manages the redraws, etc.

With canvas, you redraw every frame. So, to animate that circle you draw it in a different position every tick.

If you run canvas on top of VML you end up redrawing a lot of extra elements which get reinserted into the dom at every step.

They're just fundamentally different approaches and the impedance mismatch kills ExplorerCanvas's performance. If this has changed recently, btw, I'd love to hear about it!

Yes. At least that's what I've observed in my attempts to get Firefox up to speed in Twiddla. Here's a benchmark that you can run to compare for yourself:

http://www.twiddla.com/demo/rendering-performance-canvas.htm...

On my machine, IE will render 170 boxes per second. Firefox bogs noticeably after a couple seconds and finishes at around 60 boxes per second total.

Minor correction to the above, thanks to another thread here on HN: replace SVG with VML, and IECanvas with ExplorerCanvas (excanvas.js).

I'll try to let the author of the article know. I was sharing this article and I am not the author of the article.

JavaScript is a good language for game development, provided you have a decent underlying media layer. The browser is not a good media layer. HTML Canvas, timing, input, and audio are all miserably inconsistent and hackish across browsers. Just use Flash.

Although this might be OK for devices like Palm Pre with Palm's webOS where you won't have other options for games, at least not in the beginning.