Here comes the Haxe language and it’s almighty type inference!
Enjoy smart Haxe completion in many popular editors
I have seen the light and I believe that Haxe awesome – why don’t you want to use it?
Alright, you probably heard about Haxe (some people are annoyingly fanatic), maybe even used it at some point in the past (it probably sucked).
But you don’t know Haxe – it has changed, you have changed, let’s talk.
Do you really know CreateJS?
Many people have heard about it, but I often find out that they don’t really know what CreateJS is, what it can do, and why it can really help developing expressive websites in HTML5 today.
Believe me, it’s a topic worth digging!
ASNext was supposed to solve once and for all AS3 VM performance problems.
ASNext is now canceled, but the problem remains.
Why and how slow is AS3?
We know AS3’s VM and JIT aren’t very efficient in general, partly because the language is fairly rich and dynamic; and even if the VM was awesome, all maths are computed with double numeric types which are known to be massively slower than floats.
However compared to other scripting languages, we shouldn’t complain that it’s slow – AS3 AOT-ed on iOS is definitely much faster than interpreted LUA for instance, so why is that such a problem in AIR and not in Corona/MOAI/Gideros?
Profilers are some of the most important tools to optimize an application – yet many developers don’t even know such a thing exists.
There are profilers for most runtimes, that is you’ll get a different profiler for C++, .NET, Java and even Actionscript. For instance we’re using JetBrain’s dotTrace to profile FlashDevelop (a .NET application), and for Actionscript you’ll have the fantastic Adobe Scout.
Haxe NME, for desktop/mobile targets, cross-compiles your haxe code into C++ and builds a pure native application, so we’ll use a C++ profiler.
NME is an impressive crossplatform technology particularly appropriate for 2D games development. And by crossplatform that mean:
- Windows/Mac/Linux and iOS/Android/webOS – at full, native, C++/OpenGl speed,
- and Flash so you can also compile it for the browser.
Activity & contributions around the NME project has increased a lot recently and it seems to have become mature enough as a few companies have started using it to develop (fairly impressive casual) commercial games. If you have an iPhone I warmly recommend trying Ponon Deluxe (free) – it’s incredibly slick and a clever variation on the Tetris theme.
If you know Flash and AS3…
…you’ll be up and running in a few hours:
- this is most feature complete implementation of the Flash API that you will get your hands on – more complete than what Starling will ever be, and more complete than the subset of AIR you can use to keep performance decent,
- development is in haxe, a clever language with increasing IDE support that you can however code like AS3 90% of the time.
With the Flash Player 10, Adobe added a new set of instructions allowing to compile C/C++ in a way the AVM2 could execute. By wrapping a little bit of glue code in C, Alchemy allows to reuse some of the numerous open source C libraries available.
And when you appreciate the speed of Alchemy-compiled C code, you can wonder how it can possibly be so much faster than AS3. Unfair!
What makes Alchemy code so fast? The main secret is a faster memory management, because obviously C/C++ is all about pointers & malloc’ing. ByteArray in AS3 is kind of slow so Adobe had to hack the AVM2 to remove this bottleneck or Alchemy would have been pointless.
And the good news for us AS3 geeks is that it is possible to use this fast memory in AS3…
The haxe community has been buzzing about it for some weeks, and a few days ago you could read in haxe 2.0.4 release notes that the experimental C++ compilation target was now included.
You probably know that haxe can be used as an alternative to AS2 and AS3 for Flash development, but you would definitely be missing something if you limit this powerful language to “just Flash”…
So how did haxe get to be able to compile as C++ and why is it a big thing?