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?
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.
PreloadSwf is one fine gem in Flash Player’s mm.cfg, the historical and little known Flash Player configuration file.
In this post I will tell you all you have to know about this feature and how you are going to use it in your projects.
This was invented for Flash profiling: Clement Wong, from the Flex SDK team, presents PreloadSwf as a major piece of the “Flash profiling” puzzle in his about the Flex profiler post in 2008.
If you want to know most of the secrets of mm.cfg, dive into Jean-Philippe “jpauclair” Auclair post on mm.cfg hidden treasures. This is a must read if you like bytecode porn 🙂
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…
Let’s state it again: "tweening" is a commodity with plenty of alternatives, which means you’re not obliged to use a) crappy ones, b) bloated ones, and c) commercial ones.
Like many Flash developers I started developping Eaze because a) it’s fun, b) it’s (mildly) challenging, and c) I really had a few ideas to innovate in this field.
Since then I had the occasion to discuss (I should say brainstorm) with other Flash developers (hi Joshua and Steve) about our "tweening needs" (sounds dirty, isn’t it?) and our idea of the perfect library. This was very entertaining and they all gave me lots of crazy syntax ideas which turned out to be possible…
I don’t want to sound grumpy, but I never liked how more and more coders don’t seem to be able to keep things simple. Looks like nowadays you must be an architecture astronaut to be considered seriously.
One of these basic Flash things which should be kept simple is tweening – everybody needs to animate things, but I believe it should be kept as a commodity and not become fatter than your own application code.
Last time I gently coded a script for “rounding” the corners of a path. I think the script is really fine, handles nicely closed paths, but, it’s “static”.
So here’s the new, innocent, question: what if you want to have an animated drawing of the path?
Innocent answer: the drawing method would need a “ratio” parameter, so you can draw only a part of the path.
A few days ago, I was with a few students from Gobelins talking about their school projects. One group was working on some trip-assistant project where they would display itineraries on a city map.
Map itineraries most of the time are painted as straight lines with square corners and so one student suggested that it would look nicer with rounded corners: easy stuff, I said, just get each segment’s direction vector, multiply by the corner radius you want and lineTo/curveTo the path.