If you don’t already know, Haxe NME allows you to write code in a language that has strong similarities to Actionscript 3 but compiles down to native code across multiple platforms including iOS, Android, BlackBerry, Windows, Mac, Linux, Flash and (beta) HTML5. Admittedly, Adobe Air also provides a fantastic mechanism for publishing to multiple platforms but the temptation of native performance was very enticing.

Introduction

What you see here is a brief summary of the NME port of Away3Dlite proof-of-concept.

Check out the following two videos (available on YouTube) to see 3D in Haxe NME in action .

Starting off

To begin with, it took no time at all to set myself up to build the supplied examples. The biggest thing for me was having to install MonoDevelop and the plugin to build NME applications. I use FDT on a day-to-day basis and there are Haxe templates but unfortunately, I couldn’t find any NME templates and didn’t want to spend any time trying to create one.

With MonoDevelop & Haxe NME setup, building and deploying to all my devices was incredibly easy and I had the supplied Box2D example up and running on my Mac, iPad, Blackberry Playbook, iPod touch 2G and Huawei U8510 (Ideos X3/Blaze). What was particularly interesting for me was that it was now possible to easily build and deploy to my devices that don’t meet the min specs for Flash/Air – so I’ve been previously unable to develop for these devices (iPod Touch 2nd gen & Huawei U8510). Very impressive.

Lets go for an Away3D test drive

My first idea was to try a simple Away3D type test and this was my first problem. The only library that has been ported to Haxe is Away3Dlite. No problem, I can give that a try. This was where the second problem arose and my noob-ness was showing. Having not played with Haxe before, I didn’t really know what the differences were between it and Haxe NME. As such, when i came to use the Away3Dlite Haxe code, I found lots of reference to flash.... packages rather than nme.... packages. This meant that the port of Away3Dlite was for Haxe only and for NME it needed to be different.

I then started to realise it was not going to be such plain sailing as I had first thought. I soon found that there were some fundamental missings from NME – namely the z property on display objects and other 3D supporting classes and methods.

Building on Haxe NME

The next part of the setup, to allow me to add the missing functionality was a little more problematic but all those problems were down to relatively straight forward problems, but unless you know what you’re doing, can seem quite fundamental stumbling blocks – it was a bit of new territory for me. A quick post to the forums on www.haxenme.org pointed me in the right direction and soon enough I was able to have a play.

My objective, and proof-of-concept was to get Away3Dlite or more specifically, the Haxe implementation working under NME so I can build native apps.

The Proof-of-concept

This port, for now, is a far from complete NME port of the original Away3DLite Haxe port, with the addition of NME extra bit’s-n-pieces so it all works together. As Away3dlite is based on Flash Player 10, there is no Stage3D code in there, just good old fashioned DisplayObject type stuff. Also, this implementation also only supports iOS, OSX, Blackberry and Android targets in NME, so far. I suspect the Windows and Linux targets should be ok if they depend on the neash packages but I’ve not really tried the Flash or HTML targets as there may be conflicts or un-implemented features that I have built into NME and the neash packages.

You may be asking ‘why bother’, as Stage3D bring huge performance improvements with greater capabilities and is supported across multiple platforms. Well, for starters, Away3Dlite had already been through a port – so the starting point wasn’t right at the beginning. Secondly, I’ve been annoyed for a while that I have devices that I couldn’t build for. Yes they are low-spec or quite old but it seems a shame that other apps work well but anything done in Air can’t be published – very frustrating. I was also curious to see what performance could be had in comparison to Stage3D – and that’s something I still need to ascertain – See the ‘The Future?’ section below for more info.

One major reason for giving it a try was to get familiar with NME and begin to understand what can be achieved with the platform and I am very impressed so far.

On to the demo

All the demos are versions of the standard ExMQO.as example from the Away3DLite examples git repository. It loads a Messerschmitt BF109 aircraft and clones it four times, positioning them in a cross formation, then on each Event.ENTER_FRAME increments the X,Y and Z rotation of each model.

In total, there are 6072 triangles in the scene with approximately around 3000-3300 triangles visible at any one time. So it is quite an intensive demo.

The following is a performance table of all the devices used in the above videos. The performance FPS are not especially accurate, more indicative of the comparative performance on the devices under relatively normal operating conditions. Also, there may have been other factors that contributed to the values, good or bad, which I may have overlooked.

Performance scores – from my observations

Device

Air Captive Runtime FPS

HaxeNME FPS

MacBook Pro 13″ 2.26Ghz Core 2 Duo

17

37

iPad 3: iOS 6.01

3

11

Blackberry Playbook: OS 2.1

4

11

iPod Touch 2nd Gen: iOS 4.2.1

not supported

5

Huawei Blaze/Ideos X3/U8510: Android 2.3.5 (600Mhz)

not supported

4

For the iPad and Playbook, both the HaxeNME version were built and deployed along with an AIR captive runtime version whereas the iPod and U8510 could only manage the HaxeNME version – but at least they managed it 😉

Admittedly, the performance wasn’t phenomenal but to be honest, I wasn’t expecting it to be that high really. The POC takes advantage of HaxeNME’s GPU graphics rendering but ideally it would implement the GPU drawing in a far more efficient way to take advantage directly of the ‘z’ property (at the GPU level), depth buffer, etc, as used in more conventional hardware 3D rendering scenarios including OpenGL and Stage3D. This implementation pre-transforms all the triangles from 3D to 2D on the CPU rather than feeding 3D information to the GPU drawing API and even then the drawing uses the default system within NME rather than being an optimised version. I went for an ease in implementation rather than trying to change the rendering pipe-line of NME (I did look at it originally, but things soon broke so I stayed away from it for now).

There are bound to be a lot of optimizations that could be made by coding C++ implementations of methods rather than relying on the HaxeNME translation, none of which have been investigated as yet.

I suspect there is plenty of room for performance improvement.

And now?

Okay, the proof-of-concept did it’s job and I have an operational (too some degree) Away3Dlite port in Haxe NME, which is what I was after. I’d like to try and produce a more functional application using the port to see the what real world performance increases can be achieved.

I’d also like to investigate areas where I could improve performance. This will always be a trade off though between time and complexity of the solution – quick wins are good but re-writes/refactoring may need to happen to achieve significant gains. I need to understand the inner workings of NME in greater detail to have the confidence to dive in there.

The Future?

I know the current 3.4.4 beta of Haxe NME now has experimental support for OpenGL 2 and has examples of using shaders. I’d love to be able to port Away3D 4.x to HaxeNME for a full featured NME 3D engine. Again, I think it would take a while to implement as it would either require implementing Stage3D functionality in Haxe and NME or alternatively working the other way around and reworking the Stage3D implementation in Away3D and re-write necessary elements, such as shaders specifically for NME – even an NME rendering system.

Certainly a lot to think about but an interesting challenge. We’ll see what happens