Nicolas Cannasse Blog

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.

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 ?)

Adobe Promoting haXe ?

Nicolas Cannasse — Sun, 27 Dec 2009 20:35:01 +0100

First, merry christmas, and (soon) happy new year too all of you !

Seems like Adobe recently made some pages about game development in Flash as part of the Developer resources. Named Flash Platform Game Technology Center, they list some "featured" games that were made in Flash and are showing good use of the technology.

I was surprised that the first featured game was ScaryGirl : not because this is a bad game - Scarygirl is a very nice game, congratulations to the TouchMyPixel team for it - but because it's entirely written in haXe as stated on the developers page :-)

Anyway, have a look a the game, it's a very good one, and it shows that serious people are using haXe for "real stuff" (so do I, and many other developers as well).

Oh and just a small note : we have recently been moving haXe from its old CVS repository to a brand new google code SVN. You can browse the source code and report issues / features requests there.

Enjoy !

EDIT maybe I was a bit too fast, someone noticed me that the developers comment were talking about the Scarygirl website that is written in 100% haXe. Only parts of the game itself are in haXe as a previous mail of Tony was talking about ;)

CS5 iPhone Support

Nicolas Cannasse — Sat, 10 Oct 2009 10:39:15 +0200

As announced at Adobe MAX conference, Flash CS5 will have the ability to output iPhone binaries directly (read FlashMagazine Article about it).

I don't have much details on how it's done, but here's my guess based on what I've been reading : Adobe have built a SWF Bytecode-to-C converter (maybe using LLVM which was already used for Alchemy), then are using a cross compiler such as a modified version of GCC in order to link together this C code and a static library containing the Flash Player for iPhone.

This way there is no runtime interpretation of the SWF Bytecode, everything is "native".

haXe already has a haXe/C++ target which enable in particular to target the iPhone, so what are the differences between the two methods ?

First, I'm pretty sure that you will be able to use SWC in iPhone projects in CS5 (or else that would be a too much crippled feature). And since haXe allow you to output reusable SWC, it means that you will be able to use haXe together with this CS5 feature.

However, in that case (or if you are using AS3) you are still targeting the Flash Player. You will have additional API to handle touch screen, but you will mainly be limited by what the Flash Player gives you. In particular, that mean that you will not be able to access OpenGL ES API, etc.

This is the main difference with haXe/C++ way of doing things.

haXe/C++ allow you to natively target the iPhone (and all other devices that can be programmed with C++ BTW). And in order to ease the from-Flash transition, some API of the Flash Player have been ported to C++ in order to reproduce their behavior.

But with haXe/C++ you are no longer limited by the Flash Player : you can directly access to all the API provided by the iPhone, and in terms of graphics capabilities you don't have to go through the Flash Player API, which is good when you want to abstract things, but bad if you want to get best performances or innovative visual effects.

So in the end it's nice to have the choice : either use CS5 feature to be able to directly run your unmodified apps on the iPhone, or if you really want to be able to "hack" the iPhone and use its native capabilities, use haXe/C++ for that.

Open Source and Morality

Nicolas Cannasse — Wed, 30 Sep 2009 19:11:02 +0200

Joa Ebert is questioning on his blog whereas having an open source decompiler/obfuscator software would make sense.

I can maybe help a bit with this choice, since I was confronted to the same one a few years ago. At this time I wrote an AS2 decompiler as well as a SWF obfuscator that we are still using at Motion-Twin.

People that have met me know that I'm a big proponent of open source and open protocols, so why didn't I open sourced these software after writing them ? There are good reasons behind these choices.

Decompilers

While decompilers are a very good tool for the expert to learn about the way a given compiler can optimize code, in the hand for the average user they are mainly used to look through other people code.

I'm all for open source and code sharing, but I think that someone should get the original developer agreement before looking at his code. I don't consider that decompiling is the same as stealing, since the original code is not lost in any way (this is somehow similar to downloading an MP3) but in practice, you will often find people decompiling for the sake of just copying, only because they are too lazy to solve a given problem or because they have a deadline and just don't care reusing someone else work without asking.

While an open source decompiler is a great tool for hackers (but in that case a disassembler is already quite enough), it becomes an immoral tool in the hands of mister everybody. So I guess that from a moral point of view, an open source decompiler would not fit any particular "good usage".

Obfuscator

Somehow the entire opposite from the previous one, since the only usage one might have from an obfuscator is to protect his code from being decompiled.

Some side story : in early 2009 I have been working on an Flash9 obfuscator prototype that is working nicely. We thought to sell it by making a partnership with PowerFlasher (the company behind FDT IDE) but we found that using the software was hard and required a good knowledge of the theory being a virtual machine, as well as many code changes in some cases. We then recently decided to not push further the project, although we will be using the obfuscator in-house at Motion-Twin for our Flash9/10 projects.

So yes, I have no problem with selling an obfuscator software. Since I think that it should be the developer choice to either share its software or not, one should also have the choice to protect himself from people using decompilers.

However, I'm having a problem with the idea of an open source obfuscator, since the two ideas of "open source" and "protecting your code" are clearly opposite.

Also, I don't think that people should be encouraged to protect their code, and I don't think that someone should provide them an easy+free way of doing so. Because the best people feel their code is "secure" the more they will be sensible to their code being "reused", even if it's not at all the same code but the same behavior or same principles.

I think that developers in general should first focus on improving their skills instead of thinking about protecting the things they have been written and that almost nobody would actually like to copy.

Obfuscators and similar technologies are putting too much emphasis on the notion of property of code, and since I'm also a big opponent to software patents, I don't want such ideas to become mainstream : we don't have software patents in Europe and this is something that we should really defend.

Of course obfuscators don't have anything to do directly with software patents, but at the same time first someone might want his code to be protected, then later he want not only that, but also the ideas behind his code to be protected. And that's where software patents start being a problem.

There are still a few valid reasons to use obfuscators : for instance we are mainly using it not to protect our games implementation (because we don't care) but to protect the protocols used to save the score or exchange data between client and server, since we don't want these to be exploited by malicious players that would ruin the fun of other players (such exploits are not possible in secured games when the server handle the gamelogic, but for arcade games you don't really have the choice).

In conclusion, this is not because your are making an open source software that you are doing a "good thing". There are some cases where helping a software go mainstream can actually go against what you were thinking at first. Open Source and (sense of) Morality are two different things, but when combined they become extremely powerful.

And I guess that's all I had to say on the subject :)

The failure of AS3 ?

Nicolas Cannasse — Sat, 8 Aug 2009 01:06:05 +0200

Back in October 2005, Macromedia (later bought by Adobe) announced the Flash Player 8.5 Beta which would include support for a new programming language : ActionScript3 (AS3).

The player 8.5 - which was named this way not to frighten customers that just bought Flash 8 IDE - will later be renamed as Flash Player 9 and AS3 became the default programming language for Flash and Flex - replacing the previous AS2 - with the release of Flash CS3 Pro in April 2007.

Now, more than two years later, it's maybe time to check if AS3 was a success, or a failure.

AS3, a proprietary language ?

One of the promises of AS3 was to get out of the whole "proprietary language" thing.

Traditionally, Flash has always been criticized of being a closed-source platform (which it is) thus threatening one of the most beautiful and important things in the Web technology today which is openness : openness of protocols (TPC/IP, HTTP), formats (HTML, CSS) and browsers (Firefox and many others). Versus a full proprietary Flash platform, including an unkown programming language named "ActionScript".

The idea of AS3 was then to be based on the ECMAScript4 specification that was in the works and was supposed to become the next Javascript : Javascript2.

Sadly, since making a full programming language specification takes time, and is then not compatible with business agenda, ActionScript3 was released way before the EcmaScript4 specification was made available, and at the time the final ES4 spec was released, AS3 was already no longer compatible with it.

Furthermore, the whole EcmaScript4 process was stopped later due to political struggles between the major browser vendors (read my other post about it).

Of course, it's important to note that the AS3 compiler and the Tamarin Virtual Machine which run it were open sourced, which is of course better than nothing. But that is not what differentiate a proprietary language from an open one.

An open language has to be community-driven : people have to be able to express directly how they feel about it, and get answers to questions they might have about the way the language is designed and the way this particular feature works.

Also, the most technical users should be able to report bugfixes directly, and eventually provide full new features that have to be reviewed in decent time before getting included or rejected with a valid reason.

An open language is not about just opening the sources, it's about opening the process of designing and evolving the language.

So, here we are two years later : ActionScript3 is still a proprietary language, which evolution and control is entirely in the hands of Adobe.

AS3, better than AS2 ?

One of the major things that AS3 bring's with it is a whole new API for managing flash content. Entirely redesigned to be more practical, it should have greatly improved ease of programming for developers, versus AS2 which was hacked on top of AS1, with strange API coming from Flash 4 and even before that.

I mean, when you decide to redesign something from scratch without taking care about backward compatibility, you have an infinite freedom to design things the best way they should be.

One of the area where AS3 is definitely better than AS2 is speed : performances were greatly improved, and that's a very good thing.

However, in terms of usability, there was a lot of complains of "old school" flashers that had to write much more code in AS3 than in AS2 just to do exactly the same thing. Some might think it's pure conservatism : old men don't like when things are not in the place they were used to be. That might be true sometimes, but there's always some truth when so much people complain about API usability.

For example - I'm playing the devil advocate of course - but could someone explain me the advantage of writing the following in AS3 :

mc.addEventListener(MouseEvent.CLICK,function(e:MouseEvent) {
});

Against the following equivalent in AS2 ?

mc.onClick = function() {
}

Oh, I can hear you : listeners are very powerful, you can add several of them on the same object !

Right...

But how much probability do you have to need several click handlers on the same MovieClip ? Maybe one every hundred ? Or did you EVER need that ?

I'm not paid for programming on a per-line-of-code salary, I want simple things to be simple to write as well.

In terms of API design, IMHO AS3 went the wrong way : instead of making things that you write often be simple, the API gives you the power to make complex things, but simple things become very difficult and painful to write.

AS3, a full OO language ?

A third point were AS3 was supposed to shine was about being a "modern" programming language, with a full Object Oriented system, classes, real types, etc.

The issue is that for AS3 designers, a modern OO type system equals Java.

And not the latest Java with generics and many more features. No. The original Java, back from 1995, when at this time Java was already way behind many features experimented in research programming languages.

As a game developer, I enjoy the speed that a static type system can bring. I'm also a big proponent of strict type systems since as much type checking work the compiler do instead of me, as much I can focus on actually programming.

But the Java type system lacks one huge thing : expressiveness.

This is an axiom : the more the type system of a programming language is restrictive, the more people will try to bypass it by NOT using the type system, but instead Object and unsafe casts.

And the axiom reciprocity : the more the type system of a programming language is expressive, the more people can rely on it and the less "architecture overhead" there is.

Right now a lot of people are hating Java for its lack of expressiveness. Sadly, people are thinking that dynamically typed languages such as Ruby are the solution, whereas there are strictly typed languages which are much more expressive than Java...

The lack of many language features in AS3 such as generics, inlining, function-types, enums... have brought many developers to complain about the language. A language which has not evolved in the slightest since 2006. Some people really hate it now, and can you work daily with a language that you dislike ? Not if you have the choice...

I personally think that especially in the programming language design area - where I'm the most active - AS3 is a failure : it brings too much strict OO principles to satisfy people that prefer "scripting" procedural languages such as AS1/2, but fail to deliver in expressiveness for people that want actual features in that area.

AS3 is sick of the want-to-be-Java disease, and that's not one that you can easily cure.

What's next ?

I must admit that I'm biased in that review, and I haven't been using so much AS3 myself. I've mostly spent the last three years designing and programming in haXe.

But I'm also listening to what people are saying, in conferences, on blogs, around me. And I wanted to put into words the feelings of the actual AS3 users out there, with my own analysis of why we got there.

Sadly, I don't think that AS3 can be fixed, or it might take years. Adobe has other priorities than listening to perfectionists developers, and they are masses of Flash customers out there that just don't care at all, maybe because they do programming only as a job without any notion of pleasure inside it.

But since I don't like AS3 and was for long time interested in programming language design and compilers, I came up with my own solution to this problem : after MTASC, I designed a language called haXe and wrote a compiler which can compile it to Flash Player 6-8 and 9+, and can then act as replacement for both AS2 and AS3.

Since the initial release of haXe, a lot of people have been contributing to it, making it a real community-driven programming language, which include many features that are not in AS3.

So instead of suffering in silence, I invite you programmers to act : give a try to haXe, adopt it if you like it, and join our very active users community.

The language is maybe not perfect, but it's evolving quickly.

We know that it still lacks documentation, but that something that's getting better and better over time.

I can't guarantee that you will enjoy programming in haXe better than in AS3, but I know a lot of people that made the switch and don't want to go back.

Just do something to help yourself.

To be more happy everyday when programming.

Try haXe

PS : In case you doubt it, this is not an advertising, since I'm not getting a single Euro out of it, this is just a advice from a fellow developer ;)

Step by step Guide for haXe/iPhone

Nicolas Cannasse — Wed, 29 Jul 2009 15:57:34 +0200

Hugh Sanderson have blogged a complete step-by-step Guide to get started developing on the iPhone with haXe :

Read it here

haXe 2.04 with C++ support

Nicolas Cannasse — Sun, 26 Jul 2009 20:08:07 +0200

Today haXe 2.04 was released.

Thanks to the hard work of Hugh Sanderson, haXe now have support for the C++ platform.

It then mean that you can compile any haXe program directly to C++, and get the performances of the one of the world fastest languages ! C++ support open also a lot of new possibilities for haXe targets, including huge progress on running haXe on iPhone

In order to use the C++ platform, you will have to use the -cpp target, but before that you need to install the hxcpp library that contains all things needed to compile. This is easily done by running the following command :

haxelib install hxcpp

Now, you can simply write a small haXe program :

class Test {
    static function main() {
        trace("Hello World !");
    }
}

And compile it with :

haxe -cpp out -main Test

This will give you a file out/Test.exe that when run will simply display Hello World.

Easy, isn't it ?

In order to go further, you can use the APIs that have been made accessible from haXe/C++, they are fully listed on the haXe API pages.

It's of course possible to interoperate with other C++ programs, but these details will be soon documented.

Actually, C++ is the 6th platform supported by haXe, since there is already :

Flash (for Flash Player versions <=8)
Flash9 (AVM2, for Flash Player versions >= 9)
Javascript
Neko
PHP
... and now C++

Which will be next one ? ;)