While in the midst of the some new rigid-body physics experiments (a continuation from my previous post on Jakobsen-style position based dynamics: here) , the hooplah around the iPad and Apple getting all ‘The Hills’ on Adobe provided a welcome excuse for trying something with a completely different perspective. With the tech world’s lips aflutter and teeth agnashing about HTML5 and it’s impact on the web, we decided to use a couple days between projects to dig in and see how we could translate our Flash awesomeness to something a little more worthy of having a lower case i before it.

But before we get into the meatliness of this post, lets look at a couple of works in progress for my next physics post:

If you’re saying they look exactly the same then I’ve done my job.  If you’re nosy and like to right-click a lot you may have noticed that only one of the above demo’s has a Flash context menu (needless to say, if you see less than 2 examples you need to change your browser).   That’s right, one is done in Flash, the other in HTML with Javascript, but the real sleight of hand here is that they were done using the same program and the same core data structures.

With a fairly simple physics experiment already built in Flash with Actionscript 3,  I decided to give it a go recreating it using the hot new canvas element offered up by HTML5.  I was pretty confident that my Flash drawing library would be easy to translate over to the vector drawing context of the canvas element, and my math utilities were fairly platform agnostic, but there was one big, toothy, loosely typed shadow lurking in the water… Javascript.  The thought of returning to the Actionscript 1 days of prototype chaining was nothing sort of dreadful, and flipping through object-oriented programming in Javascript examples conjured up images of getting dentistry done during the Spanish Inquisition.  Then along came haXe…

Though its quite old now, I had been curious about using haXe for Flash development for quite some time after seeing numerous posts about it on polygonal, and here seemed to be the perfect excuse to give it a try.  While the haXe language offers up some great features not even available in Actionscript, most importantly it promises a single, standardized language that can target and compile to numerous platforms, which Flash and Javascript are just a couple of. Oh, and it’s completely integrated with FlashDevelop, monumental.  It really seemed too good to be true, but there was no other way to really find out then to jump in,  belly-first.

From Actionscript to haXe

The first task was obviously to port my AS3 codebase to haXe, to get a feel for the shift between those two.  Being based on the same specification as Actionscript, the transition was woefully painless and required barely any documentation references.  If anything it was tedious because things were THAT similar, but to that end there are tools for converting AS3 classes to HX classes that do a surprisingly good job (I used as3tohaxe).  Within no time all the hard work that went into my math and display libraries was available for use within haXe, and I was publishing out to a swf (with an amazingly fast compile time).

haXing out to Javascript

Expectedly, things got a bit more tricky when it came time to switch the target to HTML/Javascript.  While my core tools remained unchanged throughout this process, I needed to create alternate versions of my drawing lib to target HTMLCanvasRenderingContext2D objects rather than flash.display.Graphics, but I was still able to handle both within FlashDevelop using haXe, with full type information (after creating an ‘extern’ wrapper for the rendering context, more on that later) and compile errors to subtly remind me I’m no computer.   After spending a decent amount of time deciphering the w3c canvas element docs I was making sweet vector drawings within HTML using an analogous library to what I use in Flash, and with a simple ctrl-Enter I was playing with physics in my browser complete with a multitude of trace statements.

Am I conveying how amazingly simple this is?

Well, there is a catch  (maybe a few): the canvas and its context objects are not available in haXe. However, they have added a some tools to help overcome this obstacle with a little additional typing, but no rocket science.  Due to the fact that Javascript isn’t a compiled language, the definitions aren’t actually available until runtime.  To this end haXe has a keyword ‘extern’ which indicates to the compiler that the actual class will be defined at when the application has run, such as the case with custom Javascript classes or libraries or ones that just aren’t included in the haXe API.  While haXe also allows you to just throw type safety out the window, having code hints when working with an uknown such as the canvas rendering context, it helped to do the little extra work to define the API, which was readily swapped out for the real thing come runtime.

Likewise haXe doesn’t save you from those wonderful browser implementation issues that plague the web, but there are extern libraries available for tools such as jQuery to make your DOM event life a little easier.

Final Thoughts…

While this experiment wasn’t a full exploration into using haXe for Web2.0 and on, I was left with the impression that there is some great potential to close the gap between Actionscript and Javascript development using haXe.  It definitely isn’t a perfect solution either, there were some nuances of Actionscript that I missed during the process and getting away from the timeline is impossible for some projects.  But as a tool to bridge the gap between platforms, haXe does an amazing job.

Oh, and to get rid of that stupid text-selection cursor you can just attach an onmousemove event to the canvas.

Next up: Position-based rigid body physics using a barycentric dynamics model

See also:

haXe.org

Fuzzy Physics Pt  1: Constraint Dynamics

Fuzzy Physics Pt 2: Constraints Applied

Fuzzy Physics Pt 3.1: Rigid Body Dynamics