Nicolas Cannasse Blog

Thunderbird Trash Folder

Nicolas Cannasse — Sat, 12 May 2012 01:06:26 +0200

Just for the record, I'm posting this here. It might help other people as well, or myself if I forget exactly how I did it the first time.

I'm using Thunderbird with IMAP quite often. It works quite nicely. However specifying an alternative Trash folder doesn't always work as expected.

For instance on your GMail account Thunderbird will correctly detect that your trash is in [Gmail]/Trash, but messages put in that Trash are automatically deleted after 30 days. I prefer in general to keep all my old mails in an Archives folder.

Thunderbird has a nice option that ask you in which folder you want deleted items to placed, but that's not exactly what it does. Actually this give it another "Default Trash" folder name, as shown in the prefs.js (it is stored in a trash_folder_name key).

And this other trash folder will conflict with Gmail one, leading in most of the cases your mails being put in the Gmail Trash instead of your custom one.

One simple fix I found is to Unsubscribe to the Gmail Trash folder. This way you have one single active Trash (your custom one / Archives), et voilà.

WWX Conference Review

Nicolas Cannasse — Tue, 17 Apr 2012 22:07:47 +0200

Had a lot of fun at the WWX conference this weekend !

We had many great speakers, covering many different topics. The Haxe ability to target many different platforms is a real freedom that enable a high level of innovation.

For those who were not there, here's a quick resume until the recordings are made available :

Day 1

I made a keynote about the year that we went past, announced Haxe 2.09 release and detailed its changes, then presented plans about Haxe 3.0 that we will start working now and finally talked about medium and long terms plans for Haxe, such as creating a non-profit foundation. Here's my slides if you want to check them.

Franco Ponticelli presented the work he's making at ReportGrid with very nice SVG graphics, entirely done in Haxe

The Silex Labs team, which did also a great job at organizing the conference, presented the promising Cocktail library : a full HTML+CSS engine written in pure Haxe, which can run into Flash and NME

Hugh Sanderson (GameHaxe) presented the general principles and nifty details of the Haxe/C++ backend, which is the base for NME and other great usages of Haxe. Technical devs loved it, designers went for a coffee break

Robert Fell presented the awe6 inverted game framework, which is used to made several Lego Star Wars games in Haxe. The force was definitely with him.

Dominic de Lozenzo and David Peek from Massive (which have a 15+ Haxe developers team) presented an excellent review of Selling Haxe to clients and upper-management. Some great advice that we will use to improve communication around Haxe

We then got many great Lightning Talks (8 minutes per speaker), which were showing great tools and promising techs, perfect brainstorming before...

The Party in a nice bistrot in the very center of Paris that was entirely reserved for us, we got the full night to eat, drink and talk about Haxe of course. Everybody will remember the Palinka that our friends from Prezi bring from Hungary : that was delicious and many of us (including me) got to drink more than they were expecting in the first place :)

Day 2

Robert Bak did a great demonstration explaining how to explain/teach Haxe to developers. Really insightful talk, perfect complementary with Dominic and David one. Great thoughts for the incoming year.

Caue Waneck announced the release of the awaited Haxe/Java and Haxe/C# targets, which are now part of the Haxe nightly builds. Being a perfectionist, he explained a lot the things that could be improved, whereas the results are already wonderful !

Philippe Elsass (aka 'The FlashDevelop guy') presented the NME framework, explaining how you can make games for Mobile, Flash and HTML5, using a single code base.

Peter Halacsy from Prezi.com explained how and why the decided to switch their whole product to Haxe, how they were successful so far and how they want to contribute back to the community. He didn't tell us how many liters of Palinka its developers consume per month

Juraj Kircheim (aka Back2Dos) was smiling and seemed very happy to introduce fellow developers the principles and examples of Haxe Macros. Seems like it made the life of a few of them much more easy (and hopefully happy) now that they got it.

And - last but not least - it was a real pleasure to learn about Nico Zimmerman artistic work at Britzpetermann, and how they use Haxe for many different things such as wining an award from Mozilla with a WebGL demo or making interactive window installation combining different technologies together. A wonderful inspiration moment that we enjoyed together.

And after a few questions and community talks it was already time to finish and come back home.

A very huge thanks to SilexLabs for organizing the whole event, and to all the speakers and attendees for being there.

I'm already looking forward for next year edition, actually would be great to have the same kind of events in the US as well, if anybody want to take care of the organization.

Adobe Announce Speed Tax !

Nicolas Cannasse — Wed, 28 Mar 2012 16:23:31 +0200

Today Adobe announced its plans for so-called "Premium Features", check it out here

Basically, what it means is that you'll have to get a license from Adobe and pay them 9% of your net revenues if you want to use the "premium features" together with Stage3D API which allow hardware-accelerated 3D in the browser.

Sadly, instead of providing real actual "premium features" that could have appealed to AAA games developers and let independent developers continue making their games and other apps without paying Adobe Tax, the so-called "premium features" consists in one simple thing : Alchemy opcodes.

For those who don't know about it, there are two actual usages for Alchemy :

the Alchemy toolkit allows to convert C++ code to AVM2 Flash bytecode, and introduces additional opcodes for fast Memory access
these opcodes can be reused by some tools, such as Haxe flash.Memory or Joa's Apparat for AS3

Why Alchemy is so much important ? Because the AVM2 - the virtual machine that powers the flash player - is AWFULLY SLOW when it comes to memory manipulation.

As soon as you want to manipulate memory, whatever you choose : Array, Vector or even ByteArray (sic) are painfully slow compared to JavaScript or other competing technologies.

So far the Alchemy opcodes have been used as a replacement to cope with bad memory performances of AVM2, in order to speedup various tasks such as PNG encoding, Raytracing, Cryptography, Away3D Physics engine and many other tasks that just manipulate memory.

Another example of Alchemy usage is the latest technical demo of a game I've been working on : Galaxy55 is a Minecraft-like engine that absolutely needs Alchemy to build the world triangles and calculate lightning occlusion. Doing it without Alchemy would just make the game impossible since it would require more than one second to rebuild a part of the geometry when a block is changed, which occurs quite often.

A last example is Unity3D which is using Alchemy opcodes to target Flash Player.

So this is it : Adobe just made DECENT SPEED a "premium feature".

And since you really need that speed for doing (serious) Flash 3D games, it means that you will have to pay Adobe Speed Tax when you want to make a 3D game.

More important, it means that there is no hope that they will improve the slowness of the Flash Player memory, since it would then allow developers such as me or tools such as Unity3D to run 3D content without the need to get a premium license !

Oh, and what about the openness of the SWF format ? Sure : it's still open, you can build your own SWF without Adobe tools. But if you use X and Y feature, then you'll have to pay Adobe for it. Not a fixed amount of money, but a 9% tax on your revenues to get your content to run at a decent speed !

Honestly, Adobe just killed the idea of making 3D flash games, especially for independent game developers that don't make that much money that they can afford paying Adobe taxes.

The only "good news" I see is that the Haxe compiler itself is not relying on Alchemy opcodes (unless you use flash.Memory) and that it easily allows me to target other 3D technologies such as WebGL, which I will definitely consider seriously for the next 3D games, instead of Flash.

Open Letter to the Apache Flex Community

Nicolas Cannasse — Wed, 22 Feb 2012 11:36:51 +0100

I was asked to comment on the possibility of the Apache Flex Community to port Flex to Haxe, and use it has its main technology, so I posted the following mail on the Apache Flex mailing list.

I'm sharing it as well on my blog because it might also interest people that are not Flex subscribers.

I would say that there actually two choices to make there : one from a technical point of view, and one from a political point of view.

From the technical point, and with all due respect to AS3, Haxe as-a-language is way ahead in terms of features. I'll not make the list of all the improvements we made, please look at the documentation and make your own idea about it.

Of course, Haxe is a different language from AS3. In particular because it's been designed from the very start to be able to compile and run efficiently on different platforms (Flash, JavaScript, but also PHP,C++,C#,Java,etc.)

Efficiently is the keyword here.

Everybody working on compilers know that running a X language on a Y platform it's not been designed to run on is HARD. You can easily convert it to 80% - the part that always looks easy - then the next 10% are very hard, and the last 10% almost impossible without killing overall performances.

The reason is simple : most of the languages (including AS3) have been designed together with the platform/VM they run on, so adapting it to another runtime which made different choices is like trying to fit a square in a round hole : it doesn't fit - unless maybe you cut the square corners.

Haxe has been designed from the start to favor features that enable us to compile it efficiently on all platforms. It doesn't mean that we are using the lowest common denominator of all possible platforms, it's just that we make actual design choices that enable us to have great highlevel language features while still being able to compile them natively and efficiently on each platform.

I'm explaining that because I know you want to target Javascript/HTML5 with Flex as well. Don't take it lightly : one good share of Flex future is definitely there, and trying to do everything by yourself is definitely a very hard road to take.

I'm not a Flex expert, and to be honest I have never used it, so there might be pending issues and technical questions that you have regarding the best way to port Flex to Haxe : feel free to ask them there, I'll try to answer them to my best.

Now from the political point of view :

First, let me say that in the Flash world, Haxe is one of the most active open source community and we are very happy to welcome Apache Flex developers as a open source sister community.

I've personally always been a huge support of open source philosophy : some of you might also have used MTASC a long time ago, I hope you enjoyed its quality and speed and that you will find the same enjoyment at using Haxe - if you use it at some point.

You are now an independent community, which is great : you can now make your own choices, which should not be based on marketing, branding or overselling of a given tech, but on technical points.

Adobe is currently pressured and has to make hard choices. You don't know what they will be, you don't know where they will go, and if they say Left, it might finally be Right after a few months. I don't blame them : they're a commercial company, they have their own agenda to take care of, it's just the way it is.

OTOH, Haxe community has no hidden agenda : we thrive for the best technology, everything is open source, discussions and patches are welcome. We of course need to be conservative in terms of language features in order to not bloat the compiler and to keep the language elegant and coherent, so in the past years we've been improving things step by step, without either hurrying or slowing down.

In the past year, while Flash has suffered several drawbacks, Haxe has definitely gained a huge momentum. In great part this is thanks to its community which has been writing code, but also making things more visible / accessible for developers.

For instance http://haxenme.org is a great example of it : Haxe now enables to write-once compile-natively-everywhere on iOS, Android, Flash, Desktop and much more. You could do it before, but it's now much more easy, and people know about it.

Sorry if I feel to much enthusiast about it, but I'm definitely excited about the times to come.

Momentum is an important things for technology, especially when it's open source : it keeps developers motivated, it brings new people to the community, it helps making the right choices at the good time.

I'm definitely sure that Haxe momentum can help the Flex community, and vice-versa.

Now I guess you have two distincts choices left : continue to follow Adobe plans or adopt another technology (Haxe or something else) and move forward.

I can't decide for you, but I can at least answer the questions you might have.

Best,
Nicolas

Optimizing your Printer

Nicolas Cannasse — Fri, 30 Dec 2011 13:07:38 +0100

Today I'll not talk about code optimization but instead about hardware optimization.

First, allow me to say I hate printers.

They are actually quite useful tools for everyday interactions with the "real world" (or at least, the part of the real world that still use paper instead of digital documents). But the printer vendors are one of the most hateful industry : proprietary drivers, bloated software that you HAVE to install with your printer, and - most of all - toner page counters.

Today I had to print many documents to send them back as snail mail. This is already an annoying thing to do. But when I was about to print the last page (of about 40) my printer stopped working and all was displayed was Please replace the Toner.

WTF ? It was just printing very nicely just seconds ago ! In my old printers memories I was thinking that a toner would die when there is no more ink, or more exactly when you can no longer read what it prints...

Looking at my Brother MFC-7440 printer settings, I found something called the "Page Counter". It tells you how many pages you have printed so far.

Guess what ? It was stopped at exactly 1500.

Conclusion - in case you don't know about it - toners have a page counter, and toners will stop working when the page counter hits the limit, whatever if you have ink left or not.

This just another form of planned obsolescence, and I hate it. Since when engineers should design products that are planned to break ? Since when science should be used not to improve the products, but to degrade their quality ? With all the waste of both energy and raw materials (and your money as well btw), this kind of behavior should become a crime, or at least I hope it will become in the upcoming years.

But let's back to my printer, which looks like this actually :

I searched a bit on the internet and people were talking about different ways to reset the counter. I didn't find any information for my specific Printer/Toner.

Some people were suggesting to remove and put back again the Toner. That didn't work for me.

In terms of planned-obsolescence-engineering, it was making sense to put the counter inside the toner itself. And to have the printer ask the toner how many pages were left.

So one of the way to reset the page counter was to stop all possible communications between the toner and the printer.

So I removed the toner and looked at it :

On both left and right sides, I found some round-looking holes ending with a small glass-like window. Some place where maybe a laser could "communicate" with the toner.

I tried then to simply close these holes. Putting tape was not very easy so I instead used tissue paper with a little water to make it stick.

And once the toner was put back and the printer turned ON... Tadaaaa ! It was working like a charm and I could print my page number 1501 !

I'm not sure how many pages the toner will actually be able to print, but I'll make sure once it really die to update this post with my optimized page counter.

I expect a x1.5 to x3 optimization here.

And what about you ? Do you know good ways to fight against planned obsolescence ?

Update : as mentioned in the comments, a must-see documentary on planned obsolescence is available in English French and German. It was haired in early 2011 on the Arte tv channel.

World Wide Haxe Conference !

Nicolas Cannasse — Tue, 20 Dec 2011 12:44:14 +0100

I'm please to announce that the World Wide Haxe Conference 2012 (WWX-2012) will take place in Paris on April 13-16 2012.

This conference will be the best place to meet fellow Haxers and exchange both ideas and drinks ! Expect some big announcements to be made there as well !

In short : if you are either an experienced Haxe developer or someone that want to learn more about it, this is THE place to be !

Check http://wwx.haxe.org for all the details.

This year we have enough room for ~100 persons so we put a ticket system in place, please not do wait for the last minute to get your seat or you might not make it.

We are also looking for Speakers ! If you want to talk about your work or introduce your tools/library or want to show/teach/introduce something to the Haxe community, take your chance and please send us a mail with your speaking proposal at speakers@haxe.org.

Selected speakers will be announce little by little but expect the main contributors to Haxe and Haxe libraries to show up ;)

Big thanks to the SilexLabs.org team for taking care of the whole conference organization and WWX website !

See you there !

Adobe Make Some Alchemy !

Nicolas Cannasse — Wed, 23 Nov 2011 20:34:51 +0100

Today I had some issues trying to recompile one of our SWF game to work with Flash Player 11.2 Beta. I was getting an error #2500 An error occured while decrypting the signed SWF. The SWF will not be loaded

After trying different things to understand what's going on, I thought it was just a beta bug that would be fixed in final release. Until I saw the following quote that was added afterwards to the Adobe Release Notes :

Starting with Flash Player 11.2 and AIR 3.2, content targeting Flash Player 11 and AIR 3 (i.e., content using SWF version 13 and above) will not support the experimental Alchemy prototype.

What the F.... ?

But let's explain first what is really Alchemy for those of you that haven't used it. Alchemy is a tool to run C/C++ code in Flash Player. But this is also a set of Flash Virtual Machine opcodes (low level operations) that can be used to get quick memory access.

These opcodes are available by using Haxe flash.Memory class or Joa Ebert Apparat optimization tool.

These operations allow to perform very fast memory operations that crush the performances of using (very slow) native Vector or Array classes. See for instance Polygonal Labs Benchs that show a x3 to x8 speedup by using Alchemy operations.

With native 3D now in Flash Player, it is really important to be able to use these operations as well, since a lot of API require you to build both vertex and index buffers, and Alchemy can improve your framerate by orders of magnitudes !

I've been using Haxe flash.Memory in many different games right now, in order to perform many different operations such as fast 3D (x,y,time) PerlinNoise, custom filters, fast vertex buffer creation, etc etc etc.

Seeing it removed from future versions of the Flash Player is a terrible signal sent to all Flash games developers !

So what to do ?

Adobe history of taking random decisions that piss off the whole community being what it is, I guess the only thing left it to complain, complain, and complain, until they hear us out and bring it back !

Two steps for that :

spread the word ! Tweet this post or other related news around you
send emails/tweets to Adobe community managers interested in flash gaming such as Thibault Imbert

...with the hope that it will make them change their plans.

Thank you !

Update : Actually this is even worse since existing content built for FP11+ (SWF-version=13+) and using Alchemy opcodes will BREAK as soon as you install FP 11.2 !!! You'll have to buy Alchemy2 and recompile your existing content so it can continue to work (WTF ! again) - this information is confirmed by Adobe.

Flash is dead, again ?

Nicolas Cannasse — Sun, 13 Nov 2011 09:15:59 +0100

I didn't wrote that much about recent Adobe announcement that they are dropping Flash Player for mobile and focusing on AIR for apps instead. I wanted first to see what kind of reactions people had.

There is actually many different point of views.

Joy : people that didn't like Flash (some of them actually hate it) are rejoicing, seeing that as the next step toward complete flash demise. I can understand why people don't like proprietary technologies. As a developer, you get more frustrated since you can't contribute or try changing things that are just broken. And companies are often driving you into some kind of vendor-locking strategies in order to make sure that you can't reuse your skills if you buy another product from another company or - worse - use open source software. Which leads to...

Fear : "omgwtf I know only about Flash how am I going to eat in the upcoming years if it's dead ???" that's what a lot of flash developers are thinking now. They spent years building their skills for a given particular usage. Seeing this usage fade away must be quite fearsome. Of course they are people that will told them that nothing is wrong...

Deny : "I have never used Flash browser on mobile so it changes nothing, and you can still use with AIR for apps, actually this is great news !" .... Well, that's one way to put it, and actually that's not entirely wrong since actually flash browser usage on mobile has never been the main way to use Flash. That's just missing the point.

People thinking that way are just completely ignoring that technology popularity has never been about facts, but about hype, buzz, and somehow communication. Like it or not (being a scientist I'm actually very sad about it) but it works this way. And Adobe just sent a very bad red-light signal to all their actual (and potential) users. That might not be what they intended, but the result is the same : some companies will cancel their flash/mobile projects, some other will not choose Flash why they could have, etc. Of course some people know about that, but they just don't care...

Positivism : "every technology have its own life cycle, change is good, try to adapt it and follow where it leads you to". Which is true. But frustrating. First, because I want to be able to use the technology I choose and not the one that happen to be the one everybody is telling me to use. And second, because the only way out is Javascript.

Not that I don't like Javascript : this is a not-so-bad scripting language (btw the term scripting does not actually mean anything in terms of programming language, but I'm still using it there) which is quite easy to both learn and master, an active community, several good open source virtual machines, good tools, debuggers etc. But it's not my language of choice. First because I prefer statically typed programming languages : they might be harder to learn and master, but - when done right - I feel they give you a great productivity boost by letting you focus on your actual code and warning you for all the other minor errors you might be doing (typos, wrong parameters, etc.)

I don't think that statically typed PL will work for everybody - some people might spend more time actually figuring out how to correctly "type" their programs that they spend on actually programming - and I don't think that a single programming language can work for everybody, that language being my own (Haxe btw) or Javascript.

But let's back to the topic, which was Flash.

To answer the original question "Is Flash dead ?", I would say "again" : that's one more blow to it, and a big failure PR-wise for Adobe. But a technology is not dying so easily. It might eventually fade away in the upcoming years, or raise back (which is possible be have less probability) . In all cases, if you are a flash developer : don't panic. But don't do anything either ! Try to learn new things, not for the immediate present, but for the middle-term future. If you find Javascript sexy, then go for it. If you prefer structured/typed programming, then learn Haxe.

One more word about Haxe btw (it's my blog actually so I feel free to talk about my own things, hope you don't care - hopefully not if you've been reading all this post). The particularity of Haxe is that it is a language without its own platform. Usually all languages have their own platform : ActionScript has Flash, Java the JVM, C# has .Net, Javascript the web browser. Of course some people are trying to run these languages on other platforms as well, but it's often awkward and slow because the languages have usually been designed to run on their own platform. Haxe is about having one single highlevel strictly typed programming language that compiles - natively - too all the mainstream platforms. That's what we have a last kind of thoughts.

Don't care : Haxe developers don't care about petty platform wars, they know that Haxe will always adapt the mainstream platforms, that the community will build crossplatform apis as they did for Flash with NME (to run on C++/Mobile) or Jeash (to run on Javascript), and that you can still target natively a given platform to get the best performances and full features access.

Of course, I am part of this last category of people.

Hope you will join us too !

Perlin Noise Shader

Nicolas Cannasse — Sat, 22 Oct 2011 23:07:49 +0200

A few months ago I spent some time trying to run perlin noise on full GPU with a hardware shader.

Of course, thanks to HxSL I didn't have to write it in assembler.

Before getting into code details, let's have a small demo :

[perlin_shader.swf]

Here's the final shader code in HxSL :

var input : {
    pos : Float3,
};

var perlinPos : Float3;

function vertex(delta : Float3, scale : Float) {
    out = pos.xyzw;
    perlinPos = ([(pos.x + 1) * 0.5, 1 - (pos.y + 1) * 0.5, 0] + delta) * scale;
}

function gradperm( g : Texture, v : Float, pp : Float3 ) {
    return (g.get(v,single,nearest,wrap).xyz * 2 - 1).dot(pp);
}

function lerp( x : Float, y : Float, v : Float ) {
    return x * (1 - v) + y * v;
}

function fade( t : Float3 ) : Float3 {
    return t * t * t * (t * (t * 6 - 15) + 10);
}

function gradient( permut : Texture, g : Texture, pos : Float3 ) {
    var p = pos.frc();
    var i = pos - p;
    var f = fade(p);
    var one = 1 / 256;
    i *= one;
    var a = permut.get(i.xy, nearest, wrap) + i.z;
    return lerp(
        lerp(
            lerp( gradperm(g, a.x, p), gradperm(g, a.z, p + [ -1, 0, 0] ), f.x),
            lerp( gradperm(g, a.y, p + [0, -1, 0] ), gradperm(g, a.w, p + [ -1, -1, 0] ), f.x),
            f.y
        ),
        lerp(
            lerp( gradperm(g, a.x + one, p + [0, 0, -1] ), gradperm(g, a.z + one, p + [ -1, 0, -1] ), f.x),
            lerp( gradperm(g, a.y + one, p + [0, -1, -1] ), gradperm(g, a.w + one, p + [ -1, -1, -1] ), f.x),
            f.y
        ),
        f.z
    );
}

function fragment( permut : Texture, g : Texture) {
    var pos = perlinPos;
    var tot = 0;
    var per = 1.0;
    for( k in 0...2 ) {
        tot += gradient(permut, g, pos) * per;
        per *= 0.5;
        pos *= 2;
    }
    var n = (tot + 1) * 0.5;
    out = [n, n, n, 1];
}

Sadly, because of Flash11 limitation to 200 opcodes in shaders, we can only perform two octaves (which are done through for loop unrolling).

You'll notice that two textures are used for this shader : the permut texture and the g texture.

They correspond to the two main operations done by perlin noise : for each point (x,y) the perlin noise will calculate the integer part (ix,iy). It will then use a lookup in the permut texture to perform some kind of pseudo-randomization.

So this way the (ix,iy) integer coordinates will give us a random index into a gradient value, which is the gradient at the top-left corner of the "box". Now what's left is only to get the other 3 gradients values at the other box corners (which are at (ix+1,iy) (ix,iy+1) and (ix+1,iy+1)).

The algorithm will then interpolate between these 4 corner values : if we are at the top-left corner, it means that we should reach the top-left gradient value, and so on... The interpolation is not linear but uses a fade function which will smooth transitions between gradients.

One other issue with Flash11 is the lack of Float textures : the gradient values are usually between [-1 and 1] and all three values needs to represent a unit-sized 3D vector. Because we have to encode the gradients into RGB texture color space which is between [0...1] with only 1/256 precision, it is needed to perform two additional operations per gradient lookup which is (g * 2 - 1). Normalization of the gradient after that is not really needed since the precision is good-enough in most cases.

Another important part of the code is the one that builds both textures :

static var PTBL = flash.Vector.ofArray([ 151, 160, 137, 91, 90, 15,
    131,13,201,95,96,53,194,233,7,225,140,36,103,30,69,142,8,99,37,240,21,10,23,
    190, 6,148,247,120,234,75,0,26,197,62,94,252,219,203,117,35,11,32,57,177,33,
    88,237,149,56,87,174,20,125,136,171,168, 68,175,74,165,71,134,139,48,27,166,
    77,146,158,231,83,111,229,122,60,211,133,230,220,105,92,41,55,46,245,40,244,
    102,143,54, 65,25,63,161, 1,216,80,73,209,76,132,187,208, 89,18,169,200,196,
    135,130,116,188,159,86,164,100,109,198,173,186, 3,64,52,217,226,250,124,123,
    5,202,38,147,118,126,255,82,85,212,207,206,59,227,47,16,58,17,182,189,28,42,
    223,183,170,213,119,248,152, 2,44,154,163, 70,221,153,101,155,167, 43,172,9,
    129,22,39,253, 19,98,108,110,79,113,224,232,178,185, 112,104,218,246,97,228,
    251,34,242,193,238,210,144,12,191,179,162,241, 81,51,145,235,249,14,239,107,
    49,192,214, 31,181,199,106,157,184, 84,204,176,115,121,50,45,127, 4,150,254,
    138,236,205,93,222,114,67,29,24,72,243,141,128,195,78,66,215,61,156,180
]);

static var GRAD = [
    1,1,0,
    -1,1,0,
    1,-1,0,
    -1,-1,0,
    1,0,1,
    -1,0,1,
    1,0,-1,
    -1,0,-1,
    0,1,1,
    0,-1,1,
    0,1,-1,
    0,-1,-1,
    1,1,0,
    0,-1,1,
    -1,1,0,
    0,-1,-1,
];

inline function perm( x : Int ) {
    return ptbl[x & 0xFF];
}

function initPermut() {
    var bytes = new flash.utils.ByteArray();
    bytes.length = 256 * 256 * 4;
    flash.Memory.select(bytes);
    var out = 0;
    for( y in 0...256 )
        for( x in 0...256 ) {
            var a = perm(x) + y;
            var aa = perm(a);
            var ab = perm(a + 1);
            var b = perm(x + 1) + y;
            var ba = perm(b);
            var bb = perm(b + 1);
            flash.Memory.setByte(out++, ba); // B
            flash.Memory.setByte(out++, ab); // G
            flash.Memory.setByte(out++, aa); // R
            flash.Memory.setByte(out++, bb); // A
        }
    var t = c.createTexture(256, 256, TextureFormat.BGRA, false);
    t.uploadFromByteArray(bytes, 0);
    return t;
}

function initGradient() {
    var bytes = new flash.utils.ByteArray();
    for( x in 0...256 ) {
        var p = (perm(x) & 15) * 3;
        var r = GRAD[p];
        var g = GRAD[p + 1];
        var b = GRAD[p + 2];
        bytes.writeByte(Std.int((b + 1) * 127.5));
        bytes.writeByte(Std.int((g + 1) * 127.5));
        bytes.writeByte(Std.int((r + 1) * 127.5));
        bytes.writeByte(255); // A
    }
    var t = c.createTexture(256, 1, TextureFormat.BGRA, false);
    t.uploadFromByteArray(bytes, 0);
    return t;
}

The PTBL is the classic perlin noise permutation table, everything else is just precomputing some perlin noise operations in order to make sure that is can be performed with less texture lookups.

Now all you have to do is to build a quad covering a part of the screen, initialize it with a delta corresponding to the perlin scroll and a scale value.

Download the Full Haxe source code

Haxe 2.08

Nicolas Cannasse — Sun, 25 Sep 2011 15:32:42 +0200

I'm very happy to announce the 2.08 release of Haxe, available now on http://haxe.org/download

This release was initially planned for this summer, but it got a bit delayed because of many new features (and community requests) that needed some additional testing/feedback before a proper release.

Because Haxe increasing popularity there's still a lot of pending things that needs to be done, but we had to stop a bit adding new things and make a proper release at some time. This is most likely the latest 2.xx release, next one should be Haxe 3.0, around spring 2012.

Let's see now what's new in 2.08 :

For Javascript, we've been improving the .js code output : it looks nicer, more hand-written, less verbose. There's still some improvements that can be done, but don't forget that you can write your own custom JS generator in Haxe.

there's now js.JQuery as part of the standard library. It uses the new @:overload metadata to have a fully typed JQuery access in Haxe. By default JQuery-1.5 is automatically embedded, you can disable this by using -D noEmbedJS

the full Flash Player 11 Apis are now available, with Haxe high level 3D shaders HxSL and it is now possible to directly embed bitmaps with the following code :
```
@:bitmap("file.png") class File extends flash.display.BitmapData {}
```

two new apis for server-side web developement : the URL Dispatcher and a brand new version of SPOD which enable you to write directly your SQL as Haxe expressions, see SPOD Macros

the ability to directly reuse this and member variables from within the locally declared functions, such as the following example show :

class Foo {
    var count : Int;
    public function new() {
        sprite.addEventListener("click",function(e) count++);
    }
}

a lot of improvements on Macros, in particular a lot of optimization for the runtime performances and better ways to manipulate a type declaration and to define new types, see Building Types with Macros

and much more... (see the change log)

There's actually much more than this, and this is only a small part of what's happening around Haxe, since there are much more work done in 3rd party libraries by the Haxe community, watch for http://haxenme.org for an example.

Enjoy !