Nicolas Cannasse Blog

haXe 2.06 Available !

Nicolas Cannasse — Sat, 14 Aug 2010 18:02:05 +0200

I'm please to announce on behalf of the whole haXe compiler team that the 2.06 release of haXe is now available on http://haxe.org/download !

The main changes in 2.06 are :

metadata support, see http://haxe.org/manual/metadata
allow custom haXe serialization, see http://haxe.org/manual/serialization
allow to directly access the classes in SWF libraries in Flash9, and also allow several -swf-lib parameters
flash9+ now use native Xml parser : a lot faster, but more strict with namespaces
improvements in code generation for PHP and C++ platforms
https support in haXe/PHP
a lot of bugfixes and improvements on all platforms

See the whole list of changes here : http://haxe.org/file/CHANGES.txt

Enjoy !

Speaking at FITC/SF

Nicolas Cannasse — Mon, 9 Aug 2010 13:36:34 +0200

I went already to SanFrancisco earlier this year and since I'm quite busy with my daily work at Motion-Twin I wasn't really sure about going to another conference this year.

However, nice people from Influxis have been invited me for FITC San Francisco as part of their Voodoo Lounge in-conference so I'm very happy to talk here about Everything you wanted to know about haXe, but were afraid to ask, make sure to attend if you're coming to FITC, and if you're not, they will be a live streaming of the talks.

No reason for you not to watch then ;)

haXe support in FDT !

Nicolas Cannasse — Thu, 22 Jul 2010 21:21:52 +0200

I often - at least once a year - go to Flash conferences to talk about haXe

A lot of ActionScript developers are interested in giving haXe a try, but the main reason for not giving it a try is because of (lack of) IDE support.

Back in the old days, it was hard to switch between languages because of the need to adapt to a new syntax and to the changes in standard library. Since you needed to remember all the API, you were spending most of your time switching between your code editor and the API documention.

Today, IDE completion is very useful and will help you to learn/discover the API of a new language. With a good syntax support, you'll also avoid most of the troubles getting used to a new syntax. But while on one hand a good IDE will help you discover new languages, on the other hand switching to another IDE or (even worse) back to a bare text editor is very hard for some developers.

This is one of the many reasons why IDE support is important for haXe.

In order to ease IDE integration, we have been supporting from a long time compiler based completion, so you won't have to rewrite haXe Type Inference algorithms in order to display completion tip. This support help the community developing haXe support in several IDE, including TextMate, FlashDevelop, Emacs, Vim, and a lot of others...

But every developers have their own preferred IDE and I being myself IDE agnostic, I'm always happy when I see a new IDE supporting haXe.

This is why I'm very happy today to announce the alpha version of haXe support for FDT, one of the best Flash IDE out there, widely used by ActionScript developers around the world !

Many thanks to PowerFlasher and Influxis, and the FDT team to making that happen !

Apple Gate

Nicolas Cannasse — Mon, 12 Apr 2010 22:14:46 +0200

For those that haven't been following recent news, Apple changed their iPhone Apps Developers requirements by only allowing Objective-C (and a few other) languages to be used to write such apps.

What seems to be a move to prevent Adobe from integrating iPhone target in their upcoming CS5 release since it directly compiles AS3 to ARM through LLVM is actually annoying much more people than Flash fanatics, since many developers are using other languages for iPhone dev.

According to some people on the haXe mailing list, it seems that haXe for iPhone is safe since Apple would only want to ban people avoiding going through XCode compiler, which would also make platforms such as Unity safe.

I'm personally not surprised by Apple stance, since I've always seen their products as a beautiful and nicely designed lock-in, with very low level of interoperability and openness, everytime justified for the supposed sake of the "end user experience".

What makes me more surprised is that a lot of developers are still trying year after year to convince others (or themselves ?) that Apple is cool and love developers and open source, while the company actions have mostly headed the other way...

Anyway, I really enjoyed reading Hugh blog post on the subject, check it out it's worth reading (and the comments of people not understanding irony are funny as well).

FlashGamingSummit Slides

Nicolas Cannasse — Fri, 12 Mar 2010 21:22:35 +0100

I was presenting haXe at the FlashGamingSummit on Monday, that was a nice one-day conference and my first time in SanFrancisco. I'm currently attending the GDC which is also quite interesting.

I tried to focus my talk on haXe from the point of view of flash game developers. Being one myself, I think there's many reasons why haXe is perfectly suited for such a task, performances being one of them.

The Kube demo I was showing is an actual game that's been released on http://kube.muxxu.com (sorry, french only so far) and that is using a realtime raytracing engine running in Flash with low-res old school looking textures.

Here's a screenshot of the actual game :

You can download my slides in you want to have a glance at what I was presenting :

FGS2010_haxe4GD.pdf

Back in 2005

Nicolas Cannasse — Sun, 14 Feb 2010 21:46:15 +0100

I was just looking at my emails archives. Actually we installed our IMAP server at Motion-Twin by the end of 2005 so I almost have all my sent/recv mails from this time. More than four years of words, and so much energy (and time) spent while writing them...

November 2005 was also the time that we started a private mailing list with the main people of OSFlash. It was including OSFlash cofounders - Aral and myself - as well as people working on the big projects at this time : John Grden, Chris Allen, Dominick Accattato and Luck Hubbard from Red5, and Edwin van Rijkom from Screenweaver.

We started discussing about a possible OSFlash Manifesto which would act as a foundation for the newborn and growing OSFlash community.

Here was my original take on the Manifesto :

Date: Sun, 27 Nov 2005 12:05:02 +0100
From: Nicolas Cannasse <ncannasse@m.....com>
Subject: [Roundtable] Manifesto RFC

The OSFlash Manifesto
---------------------

Fifteen years ago, there was no Web. Nothing. The WWW protocol was 
invented back in 1990 by CERN scientists in order to share research 
informations. Since then, the web and the whole internet have been 
growing at a tremendous pace, bringing a place to communicate and share 
for users around the world, a place where everybody can talk freely, a 
huge quantity of online services and wealth to a lot of people and 
companies.

What made possible this growth is the openness of Web protocols and file 
formats. Anybody can "speak the web" freely, by sending HTML documents 
using HTTP protocol over a TCP/IP connection. The Web is not owned by a 
particular company, it's a whole ecosystem of mixed open and 
prioprietary tools, all using theses open protocols and file formats.

Flash is a technology that is widely present on the Web. Yet, the number 
of Flash developers is still way beyond the number of web developers. 
There is a reason for that : Flash is a proprietary platform owned by a 
private company named Macromedia (now Adobe).

The OSFlash community is composed of Flash enthousiasts and technology 
savvy people that see an interest in developing Flash further its 
current status. As a community, we have two goals :

One is technical. As most of us are using Flash on a daily basis, we are 
cooperating together in order to create a better set of tools. The tools 
sold by Macromedia cannot always be the perfect fit for any kind of 
usage. As a community, we're helping each other and are trying to find 
the best way to complete a given task.

The other is ethical. We don't want to be "lock-in" into a particular 
proprietary solution. We don't want one part of the Web platform to be 
owned and fully controled by a private company. As a community, we are 
then working at learning the different protocols and file formats needed 
  in order to "talk Flash". We are doing that in a legal way, through 
observation of the existing. And we are then providing the documentation 
and tools released under an Open Source license so that everybody can 
openly build Flash content.

Additionally, we are requesting that Macromedia open further the Flash 
platform, by doing the following :

a) fully document without any licensing restriction the different 
protocols and file formats used by Flash. The OSFlash community is doing 
that, and this will surely bring a whole set of Open Source tools. By 
having an official documentation, Macromedia can create a whole 
ecosystem of other companies that will create other Flash-related tools. 
We think that this will benefit the Flash platform.

b) allow the Flash Player to be embedded and reused without any 
restriction, so that the Flash technology will not only be usable on the 
Web but inside applications, bringing a lot of new people into making 
Flash content. With current Player restriction, the platform is not even 
available of redistribution.

c) facilitate the emergence of third party compatible Flash Players, 
just like Sun did for Java. This will put again the Flash technology far 
beyond its current limits and bring in return more users into Flash.

d) ultimaly, create a consortium representing both companies and users, 
that will openly discuss the evolution of the Flash technology in a 
democratic way.

If Macromedia opens the Flash technology, we can see a future in it. If 
they don't, that will ultimaly be the death of the idea of "Flash as a 
platform". Creating a web proprietary platform, should not and actually 
cannot be done. Any company following this path will fail in doing so.

Following the experience of Democraty and the Web : openness bring 
growth to everybody.

-- EnD --

Nicolas

That was of course a bit bold at this time, but four years later remains quite actual since the situation hasn't changed much since then.

This manifesto was not approved by Aral which had his hands on OSFlash.org so after a few weeks of discussions we didn't reach anything and we were not able to establish OSFlash as a community and to act as one. From there, OSFlash community began splitting among specific projects, from which came very nice pearls such as PaperVision3D, Red5, and my own haXe.

Today OSFlash is no longer an active united community. There are a few posts on the mailing list but nothing really happening. Maybe things would have gone a different way if we were able to agree on this Manifesto, back in 2005...

Flash Gaming Summit

Nicolas Cannasse — Wed, 3 Feb 2010 21:30:20 +0100

I'm trying every year to speak at least at one international conference. Attending to a conference is a good way to keep me updated with what's happening in the real outside world, and I also like to talk about my work while I'm there ;)

I don't have much free time, I dislike airports, and I'm married : three good reasons why I'm also limiting a bit my involvement within the "conference loop" compared to some of my good Flash friends which are doing something like five (or more) conferences a year.

Since I like to meet new people and learn new things, I think it's best to go as much as possible to different conferences. This year I will be very happy to speak about haXe at the Flash Gaming Summit conference which takes place in San Francisco next month !

This is a bit a side-event of the bigger Game Developer Conference 2010 so I'm sure I'll have a lot of fun there, and meet people that want to hear more about how to develop Flash games with haXe.

EDIT : I decided to the stay the whole week in SF and attend the GDC at the same time, so if I know you and if you are around, drop me an email so we can meet.

See you (maybe) there !

haXe Community Meeting

Nicolas Cannasse — Tue, 26 Jan 2010 16:51:34 +0100

The haXe community is having an IRC meeting on Thursday 28, make sure to make it if you want to know more about haXe and different ways you can use it !

All details about the meeting are published here : http://haxe.org/com/meeting

Playing with Sfxr

Nicolas Cannasse — Fri, 22 Jan 2010 16:48:51 +0100

In case you don't know about it, Sfxris a very nice library used to general sound effects, perfectly suitable for independent game developers :)

Sfxr was then ported to AS3, which was itself ported to haXe

I wanted to use it for one of my projects, but I was not very happy with the way it worked for Flash9 : you had to load a SWF (containing a sound and generated in-memory) each time you wanted to play a sound.

So I modified a bit the code in order to create a SWF that contains a Sfx class extending which is binded to the sound data. This way you can now :

build a SWF from wave bytes
load it using Loader.loadBytes into a new empty ApplicationDomain
retrieve the Sfx class
create a flash.media.Sound instance
cache it for further usage

The code uses some static data to define the AS3 class. I could have done it manually by using the haXe Format Library which have full SWF+ABC support but I didn't want to add one more dependencies so did something more simple instead.

Here's the source code for that, you can plugin it into Sfxr haXe port :

static var AS3_DATA = "s238:EAAuAAAAAAgAA1NmeAtmbGFzaC5tZWRpYQVTb3VuZAZPYmplY3QMZmxhc2guZXZlbnRzD0V2ZW50RGlzcGF0Y2hlcgUWARYDGAIWBgAFBwECBwIEBwEFBwQHAwAAAAAAAAAAAAAAAAABAQIIAwABAAAAAQIBAQQBAAMAAQEFBgPQMEcAAAEBAQYHBtAw0EkARwAAAgIBAQUX0DBlAGADMGAEMGACMGACWAAdHR1oAUcAAA";
static var AS3_BYTES : haxe.io.Bytes = null;

public function buildSWFSound() {
    var rate = switch( wav_freq ) {
        case 5500: 0;
        case 11000: 1;
        case 22000: 2;
        case 44100: 3;
        default: throw "Unsupported freq "+wav_freq;
    };
    var is16Bits = switch( wav_bits ) {
        case 8: false;
        case 16: true;
        default: throw "Unsupported bits "+wav_bits;
    };
    var stereo = stereo_pan != 0.0;
    var wave = haxe.io.Bytes.ofData(baWave);

    var swf = new haxe.io.BytesOutput();
    swf.writeString("FWS");
    swf.writeByte(0x09);  // version
    var o = new haxe.io.BytesOutput();
    for( b in [0x78,0x00,0x05,0x5F,0x00,0x00,0x0F,0xA0,0x00,0x00,0x0C] ) // header
        o.writeByte(b);
    o.writeUInt16(1);  // #frames

    // Sandbox
    o.writeUInt16((69 << 6) | 4);
    o.writeUInt30(8);

    // AS3
    if( AS3_BYTES == null )
        AS3_BYTES =  haxe.Unserializer.run(AS3_DATA);
    o.writeUInt16((72 << 6) | 63);
    o.writeUInt30(AS3_BYTES.length);
    o.write(AS3_BYTES);

    // DefineSound tag
    o.writeUInt16((14 << 6) | 63);
    o.writeUInt30(2 + 1 + 4 + wave.length);
    o.writeUInt16(1);  // sound (character) ID
    o.writeByte((3 << 4) | (rate << 2) | ((is16Bits?1:0) << 1) | (stereo?1:0));
    o.writeUInt30(wave.length >> ((is16Bits?1:0) + (stereo?1:0))); // samples
    o.write(wave);  // data

    // SymbolClass
    var cname = "Sfx";
    o.writeUInt16((76 << 6) | (2 + 2 + cname.length + 1));
    o.writeUInt16(1); // 1 class
    o.writeUInt16(1); // sound ID
    o.writeString(cname);
    o.writeByte(0);

    // ShowFrame
    o.writeUInt16((1 << 6) | 0);

    // end tag
    o.writeUInt16(0);

    // finalize
    var swfbytes = o.getBytes();
    swf.writeUInt30( swfbytes.length + 8 ); // filesize
    swf.write(swfbytes);
    return swf.getBytes();
}

#if flash9
static var cache = new Hash<flash.media.Sound>();
static var pendingLoaders = new List();
public static function play( settings : String, ?delay : Float = 0 ) {
    var sound = cache.get(settings);
    if( sound != null ) {
        sound.play(delay);
        return;
    }
    var s = new Sfxr();
    s.setSettingsString(settings);
    s.generate();
    var timer = haxe.Timer.stamp();
    var l = new flash.display.Loader();
    pendingLoaders.add(l);
    var domain = new flash.system.ApplicationDomain();
    l.contentLoaderInfo.addEventListener(flash.events.Event.INIT,function(_) {
        pendingLoaders.remove(l);
        var cl : Class<flash.media.Sound> = domain.getDefinition("Sfx");
        cache.set(settings,Type.createInstance(cl,[]));
        delay -= haxe.Timer.stamp() - timer;
        if( delay < 0 ) delay = 0;
        play(settings,delay);
    });
    l.loadBytes(s.buildSWFSound().getData(),new flash.system.LoaderContext(null,domain));
}
#end

Getting Some Numbers

Nicolas Cannasse — Thu, 21 Jan 2010 00:00:33 +0100

Some people often ask me what are the advantages of haXe in terms of speed.

Of course, there are many runtime optimizations in haXe that make your program run faster, but one of the very important thing to me is also the speed of the compiler. Compiling quickly help you to test some minor changes more often, to find and fix errors faster, and prevent you from losing your concentration and your time waiting for the compiler to be done with its work.

So what about comparing haXe and AS3 compilers speed ?

First, haXe starts with an obvious disadvantage : because it has type inference, structural subtyping and generics, the compiler needs to perform much more type checks that in more classical type system such as AS3 one.

But let's see how it rates anyway.

I tried the following : compiling the whole hx-format library, which is 64 files / 10.000 lines / 300KB of haXe to Flash9. Here's the commandline for that :

time haxe -swf9 format.swf -cp hxformat/tests/all All.hx

On my QuadCore (haXe compiler does not yet use multicores, that's something we need to fix btw) the command run in 0.31 seconds which is a decent enough.

Now, I'm generating the corresponding AS3 output by using :

haxe -as3 format_as3 -cp hxformat/tests/all All.hx

(a small fix was needed in format.amf.Reader since some expression is not accepted by AS3 generator, but well...)

Then here we go with the AS3 compilation. This was actually a bit hard, because I found that the format.swf.Namespace class is actually a reserved name, so had to do a bit of renaming here and there, then the mxmlc compiler crashed when compiling format.mp3.MPEG (but maybe I'm not up-to-date), and I had to recreate a All.as file that would ensure that all files will get compiled (since import in AS3 is lazy while it's not in haXe), and so some other minor fixes. Took me 15 minutes but I was able to compile everything except format.mp3 package.

So at last here we go :

mxmlc --output all.swf -compiler.optimize All.as

Took... 3.3 seconds on my QuadCore

So, even if we take out something like 1 second for JVM startup (mxmlc is Java) then we still have haXe which is... 7x faster than mxmlc ?

Now, that's just a benchmark, I would be happy if other people could try the same with their own project to see if I'm accurate enough or not, but this seems to confirm that indeed, haXe is fast !

(anybody who remember no more coffee break while compiling ?)