Links mentioned in the tutorial

• Red5
• Eclipse for Java EE Developers
• NetStatusInfo class

V1

A few weeks ago, in Amsterdam, Ralph explained a bit about it during his session. And then finally yesterday (actually the day before…), I bit the bullet and spent the evening making it happen. Only 4 hours later I had a first version that got pretty close to it.

Check this very first edition on the following URLs. The text is generated using AS3, so you can just make it show any text you want. Just change the URL params

• Particle fun V1 (with blur)
• Particle fun V1 (without blur)

The particles move to a perlin-map (red & green) with text in front of it. The color of each pixel is used to determine whether the particles has to move up,down,left or right and how far. Not how fast… That left all particles moving almost equally fast… Which is kind of a minor downside to me… Seeing how it almost was 6AM, I felt it were a good idea to catch some sleep…

V2

When I woke up a few hours later, I felt the irresistible need to improve the effect of the particle swarms and optimize some code in order to squeeze a few more frames per second out of the code.

I ruined the rest of my day coming up with another version. This time the perlin-map’s color would not just serve as a guide who tells the particles where to go and how far. The map would actually act as a force field: Each pixel would accelerate the particles on both the x and y-axis. As a result: we have now very different speeds of particles! And it looks pretty cool too! Example below. The text can be controlled using the URL parameters.

• Particle fun V2

Watch out! Nerd time!

This final version (well… final…) looks pretty good in my opinion. A few details about it:

• 25000 particles (1 particle = 1 pixel)
• runs up to 85fps (Capped this at 50fps, otherwise it the animation would be too wild)
• The bitmapdata object’s dimensions: 750 x 350

Most important things

During this experiment I learned a lot about optimization. A few things that might come in handy some time:

• Instead of using setPixel() for every single pixel you wish to animate, only update the bitmapdata once using setVector(). You can get the vector of pixelvalues from the bitmapdata obj using getVector(). Then change the values in the vector. When done, appy the new values to the bitmapdata object using setVector(). This will give you some valuable milliseconds (believe me: every millisecond counts when doing 25 000 loops per frame)
• Instead of looping through long arrays  (or even vectors) use linked lists: They’re easy and fast!
• Bitwise operations might look very unhuman, but they can buy you a great deal of milliseconds! Make sure you check the bitwise possibilities that there are out there. A lot of great minds have shared ‘common’ calculations in the form of bitwise operations that turn out to be just a bit faster.
• Think a lot about what kind of calculations you’re going to make and most importantly: When? For example in my first version: I get the pixelvalue from the perlinmap every iteration of the loop (times 25 000). However in version 2, after generating the perlin map, I immediately calculated the forces of every pixel and saved the values in a vector. I then request those values in the loops. This kind of precalculations will give you valuable milliseconds per frame and thus more fps.
• When editing pixel per pixel, make sure to lock()/unlock() your bitmapdata. That will prevent the bitmap from updating after every change. Again: giving you more milliseconds for your viewing pleasure!

I can’t really post any technical optimization tips (since I really just got started myself) but there are tons of articles out there on this topic. I suggest you check those out for more practical optimization tips.

I’m looking into doing more experimentation regarding particles. If you have any optimization techniques that I should know off, don’t hold back to educate me Either way: I really love this, so stay tuned!

Sources: Click (Flash Builder 4 project)

• Interactive: I want the user to be able to control what is happening. The user should always be part of the application. The user should actively be engaging with the application. Whatever happens should happen either because of the user or for the user to get an even better experience.
• Experience: I don’t want them to just click a few buttons. I want my users to like the application. I want them to like it so much, that they start missing it once they’ve closed the browser window.
• Designer: Although most of you know me as a developer, I want to make a point here: I don’t develop. I create.
  I write code in order to create a visual masterpiece, either in interaction or experience; not in code; not in application architecture; none of those non-Ronny words.

That last point is really the reason of why I’m writing this. Having said the above, it should be clear Actionscript has enabled me to create cool stuff. Actionscript has enabled me to create whatever I could think off. But now at this point, I’m eager to go beyond my current limits, and I want to go there fast!

Only a few minutes ago, I was thinking about how I’d start creating this new (experimental) application. And before I even got to actually start building the whole thing, I lost motivation. It is SO MUCH WORK to only setup the application without  the actual features I wanted to build in the first place. How am I supposed to have fun?!

I came to realize how much I miss the AS2 coding style where you just created. You would just have pointed at a movieclip, and run a loadMovie(). It doesn’t get any quicker than that.
Even worse: I missed the loosely typed, old fashioned JavaScript style of getting straight down to business. My guess is: You don’t understand what I’m trying to say here. Let’s show you a simple example: Load an image and add it to a sprite on the stage.

import flash.events.IOErrorEvent;
import flash.events.Event;
import flash.display.Loader;
import flash.display.Bitmap;
import flash.net.URLRequest;
 
var url:URLRequest = new URLRequest("myPicture.jpg")
var loader:Loader = new Loader()
addListeners();
loader.load(url);
 
private function addListeners():void {
	loader.contentLoaderInfo.addEventListener(Event.COMPLETE, completeEvent)
	loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
}
private function removeListeners():void {
	loader.contentLoaderInfo.removeEventListener(Event.COMPLETE, completeEvent)
	loader.contentLoaderInfo.removeEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
}
private function completeEvent(event:Event):void {
	removeListeners();
	var bm:Bitmap = Bitmap(e.target.content);
	someSprite.addChild(bm);
}
private function ioErrorHandler(event:IOErrorEvent):void {
	removeListeners();
	trace("Ay, yo' pic is gone, mate!");
}

This looks pretty straight forward, right? Create a loader, add the eventlisteners for completion and error, handle them, and remove the listeners. This is as straight forward as it gets.
Well even though this is as basic as it get’s: It’s too much! This should be easier! Shorter! Hell: it should be more fun!

If loading this image is your application, then this is not that much of a problem. If loading 3 images is only a small (and almost not important) part of your test-application, then all of this code is way too much effort to focus on what you actually wanted to do: Test something completely different!

You might think I’m exaggerating here, but I’m not. When I think of a cool little experiment, I don’t want to spend all day starting to create it, only to end with 10 minutes of writing the actual test code. I don’t want to write 300 lines of code in order to just test something that consists of 10 lines.

I’m not asking Adobe to make AS4 shorter-handed, I’m not calling anybody out to create a framework that enables me to have fun, I’m not asking anybody something. I’m just getting tired of having to write bullshit JAVA-assed best practice code in tiny-experimental-proof-of-concept-test-applications.

I don’t feel like I’m using ActionScript anymore… I feel like I’m subjecting myself to it. I’m not in control. Actionscript is. If I don’t agree with that close minded language, it’s not going to cooperate in any way… I have to talk to it very genly, and choose my words wisely… What the f###? It’s a computer! Now bend over and do as your told!

When writing test-applications (which is basically what I do 90% of the time), I want to get the job done. I don’t want the code to look good. In fact, when creating this test builds that are a kick in the teeth for every best practice rule in the universe, I couldn’t be bothered in a lifetime about coding conventions… I just want my freaking app to start working!

However I soon learned the microphone feed didn’t go through the SoundMixer of the Flash Player, therefor would would not be able to be analyzed. There was a workaround with FMS/RED5 and bouncing the stream off the server but that’s rather overkill (not to mention the lag).

However…
Mike Chambers and Lee Brimelow were in Paris the other day where they demoed/demo’ed/demo-ed (how the hell do you spell that word??) a few new features of the upcoming AIR release. If you don’t already know, you’ll probably have guessed it by now but (just to be crystal clear): The microphone is accesible for computeSpectrum in the AIR runtime. Check out the demo on Lee’s blog

Lee stated on his blog he couldn’t talk about this feature being brought to the Flash Player, but I’m pretty confident Adobe will do so
Even though I’m not much of an AIR developer, I like the idea of having access to both microphone and camera… I can image a few cool applications using those features…

By the way: If you don’t already know: there’s a great site with all kinds of intresting articles on the subject. If you’re interested, make sure to check it out: getMicrophone().

So I started moving some code around and after a few minutes, I found myself rewriting the whole thing… That’s not a bad thing since now we’ve got one handy class that can do about just everything a Bezier Animator should be able to do.
Demo time!

There’s still a little bug somewhere which allows the target to ‘run away’ from the bezier, and I haven’t gotten quite to the root of the problem, but I really felt I had to share this. Also there are some imperfections when you disable the orientToPath and scaleByPath properties. I will look into fixing those asap.

I really love the idea of animation movieclips using bezier curves. It looks so natural and yet zo intriguing… I will do some experiments and upload them later on, showing the coolness behind this simple animation engine.

Sources
Download the above demo source (Flash Builder 4 project): Click
Download the BezierAnimatioin class: Click

Today I found some time to mess around with bitmapdata and computeSpectrum again. I’ve been playing with this earlier, but didn’t quite get where I wanted to be. A few weeks ago I came up with a better way of rendering the soundTunnel. That resulted in some crazy cool shit, which I finished off today.

I won’t go into technical details here (yet). I just wanted you guys to see the result.

Demo

Click here
And just to make sure it is actually reacting to the sound, try the following links too

• Song 1: Click
• Song 2: Click
• Song 3: Click (default)
  
• Song 4: Click
• Song 5: Click

Controls

• F: Go full screen
• S: Freeze visualization
• Click: Change color (happens automatically too)

Screenshots

Tijdens het ontwikkelen van de site voor mijn eindwerk in december liep de emmer over: Alweer een project waarin het ActionScript tweenen niet wilde lukken. Gerrit kwam me helpen, en na even zoeken kon hij me vertellen dat de fout inderdaad niet bij mij lag, maar bij de garbage collector in de Flash Player.
Mijn probleem was vanaf dan opgelost, en in elk project waar ik nu ActionScript-matige tweens aanmaak kan ik dat probleem meteen uit de weg gaan, maar ik zie nog enorm veel vragen opduiken waarin dit exact zelfde probleem besproken wordt.

Hoe ontstaat dit probleem?
Het probleem zelf ontstaat (voor zover ik het heb gezien) als je in een functie/handler een lokale tween aanmaakt, zonder externe referenties te behouden.

Voorbeeld:

function someHandler(e:Event):void{
var tween:Tween = new Tween(someMC,'scaleX',Regular.easeOut,0,1,5,true);
}

In bovenstaand voorbeeld wordt de functie someHandler opgeroepen eens er een event gedispatched wordt. Op dat moment wordt een tween aangemaakt in de scope van die functie. Eens deze functie doorlopen is, wordt deze verlaten, en zomee is deze scope niet meer in gebruik. Er is op dat moment geen referentie meer naar je tween object, dat je zonet hebt aangemaakt.

De garbage collector verwijdert variablen/objecten aan de hand van die referenties: Als er objecten zijn in scopes waar niets meer naar verwijst, is dat ‘garbage’ en kan zomee verwijderd worden.
Het tween object is hier ook onderhevig aan: Eens je de scope van die someHandler functie verlaat, is er geen referentie meer aanwezig naar je tween object, ookal is die visueel actief op de stage van je Flash movie. Als de garbage collector van de Flash Player dan voorbij komt om op te ruimen wordt je tween object verwijderd: op het scherm stopt je tween voordat hij klaar is.

De oplossing?
Er zijn verschillende manieren om de garbage collector te vertellen dat we ons tween object nog nodig hebben.

• We declareren de tween globaal. Hiermee zal hij altijd in main scope aanwezig zijn, en zomee niet verwijderd worden tenzij wij dat zelf aangeven.
• We kunnen diezelfde globale tween ‘hergebruiken’ in diepere scopes. (Handig als je maar 1 tween hebt, waarvan je zeker weet dat hij zichzelf nooit zal overschrijven/vervangen.)
• We maken een globale array aan, waar we elke tween aan toevoegen. Op die manier is er ten alle tijde een referentie naar ons tween object, en zal de garbage collector het niet kunnen verwijderen, tenzij we de tween uit de array verwijderen.

De laatste oplossing heeft mij al veel gediend, en is weinig moeite.

var garbage:Array = new Array();
function someHandler(e:Event):void{
var tween:Tween = new Tween(someMC,'scaleX',Regular.easeOut,0,1,5,true);
garbage.push(tween);
}

Dit is een nogal onprofessionele manier Ik vind dit nogal een vuile manier om het probleem uit de wereld te helpen, maar het is wel de essentie van de oplossing.
Bij extreem veel tweens in een applicatie die lang in gebruik is, is het misschien geen slecht idee om die array af en toe wat uit te kuisen: Tweens die niet meer gebruikt worden uit deze array verwijderen.

Er zijn mensen die me zeggen dat het gebruik van Tweener of TweenLite dit probleem ook meteen oplost. Ikzelf heb nog niet genoeg met Tweener gewerkt om daar zelf een oordeel over te kunnen vellen.

Ik hoop dat ik hier een aantal mensen kan mee helpen, gezien dit toch een populair probleem schijnt te blijven.