Nothing much here, but I thought I’d share a handy little library to decode WebP in Flash. Here’s two demo’s : Lena and V for Vendetta, both encoded using the webp binaries provided here.

It’s a small wrapper around the WebP library ported with Alchemy. The port is pretty easy to do using Alchemy, aside from some issues with the Alchemy toolchain pretending to be a normal gcc toolchain; it enables some x86 asm code for cpu identification in the webp code, which obviously won’t work in Flash. After those issues are resolved getting up and running is easy.

However, I’d figure I’d post this as I have seen several requests for making webp work in Flash.

Although webp decoding isn’t there natively om the FlashPlayer, this should help you a long way. Read further for an example on usage and download of the swc.

As for this blog; due to time constraints I find myself not being able to update it regularly, even though I want to. Also, as I do a lot more tech then just Flash these days, I’m looking for a way to post experiments in other technologies, without the daunting task of making a full scale blogpost about it….more on that when I figured it out.

Download webplib.swc.

public class Main extends Sprite
{
	[Embed(source="V.webp", mimeType="application/octet-stream")]
	private const WebPImageClass:Class;

	public function Main()
	{
		stage.scaleMode = StageScaleMode.NO_SCALE;
		stage.align = StageAlign.TOP_LEFT;
		init();
	}

	private function init():void
	{
		WebPLib.init();//Only needs to be called once.
		var bitmapData:BitmapData = WebPLib.decode(new WebPImageClass() as ByteArray);
		addChild(new Bitmap(bitmapData));
	}
}

An image of ShadowGun a game made by Madfingers, using Unity.

If you wonder why it’s silent in here again; same old, same old; I’ve been busy. So many things happened this year, most of them very good. Workwise, I have joined the brilliant minds at Unity Technologies to work on further expanding the reach of Unity. Today is exiting, because over on the Unity blog, there is a first public sneak peek of our progress. Let us know what you think !

JFA Voronoi Paper by Guodong Rong and Tiow-Seng Tan.

WebGL / Canvas – Jump Flood Voronoi Experiment. from Ralph Hauwert on Vimeo.

Demo Video of WebM being decoded by Flash. from Ralph Hauwert on Vimeo.

This is a little side project I have been playing with. I’m porting google’s libvpx using Adobe Alchemy to run WebM in Flash Player 10, which doesn’t support the format natively yet. Because it’s not much more then a small and experimental side project, I quickly made a video to show it’s progress up until now. Monday the new part in the Particle Sessions will appear.

Part One of the Particle Session kicks off with looking at a system similar, but simpler then this Bloom particle experiment (music made for it by the fantastic artist Rich Bologna, thank you again for it, Rich!). We’ll be taking slow steps of optimizations and at the end have a get prepared for the next level. To be able to get up to speed with the working of the video particles, we’ll start from the beginning and work our way up. For that reason, we’ll start very simple and look at a basic unoptimized particle system with next to zero functionality, and modify the code for performance.

Basis : The Particle

The opening picture of this post is the album cover of The Strokes – Is This It. It being one of my favorite albums, I have listened to it many times, but never noticed what the cover really was. It’s amazing & inspiring what imagery one can get from science. Now put on your headphones and listen to that album while reading this post.

Over the last years I’ve more and more started enjoying introductory books about theoretical physics. In complete honesty, it wasn’t even that long ago that I didn’t know that the Boson in the Higgs Boson wasn’t the other guy discovering it, next to Mr.Higgs. You know, like the Hale-Bopp comet was discovered by Hale & Bopp.

Luckily for us and this post, we don’t need to deal with wave particle duality and quantum entanglement, but we can achieve seeming complexity by using simplicity.

Getting started : Simplicity & Complexity

The simple core particle we will be using in this session get its complexity from its display of large numbers of them, not from per instance properties. To illustrate that, let’s start off with a simple particle object in AS3

package com.unitzeroone.particlesessions
{
	import flash.display.BitmapData;

	public class Particle {
		public var x:Number;
		public var y:Number;
		public var velX:Number;
		public var velY:Number;

		public function Particle(x:Number, y:Number, velX:Number, velY:Number) {
			this.x = x;
			this.y = y;
			this.velX = velX;
			this.velY = velY;
		}
	}
}

As you can see, this particle object is pretty simple, and it contains the core properties we really need to make them move. Its position stored in x and y, and its velocity stored in velX and velY. For the case of this post it’s more then enough to do what we want.

I do want to point out two things about the simplicity of this. First of all, we express all values in absolute x and y. For the positions, this would be called a cartesian system. In some cases it might be handier to express velocity as a polar coordinates, but performance reasons we’ll keep them like this.

OOP (s)

It’s very common within the AS3 industry to “objectify” everything in nicely wrapped classes first and think about performance later. In the case of our particle and a classic “update” loop as seen in game engines, the most natural feeling way to implement the particle’s moving behaviour for the particle is as follows.

package com.unitzeroone.particlesessions
{
	import flash.display.BitmapData;

	public class Particle {
		public var x:Number;
		public var y:Number;
		public var velX:Number;
		public var velY:Number;

		public function Particle(x:Number, y:Number, velX:Number, velY:Number) {
			this.x = x;
			this.y = y;
			this.velX = velX;
			this.velY = velY;
		}

		public function updateAndDraw(toBitmapData:BitmapData):void
		{
			this.x += velX;
			this.y += velY;
			toBitmapData.setPixel(this.x,this.y,0xFFFFFF);
		}
	}
}

This is a very logical thing to do and is suitable for most things, especially in larger code bases, it certainly helps in readability. It also matches many things you’ll see in OOP and AS3 books. Like car.drive() or lasership.shoot() or avatar.updatePosition(). From a pure OO perspective, it makes sense. From a performance perspective, this isn’t as good though. We’ll tackle that in a bit.

Main

Now, let’s say we’d have a very simple Main class to run this system, as such :

package {

import flash.display.StageScaleMode;
import flash.display.StageAlign;
import com.unitzeroone.particlesessions.Particle;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.display.Sprite;
import flash.events.Event;

	public class MainOne extends Sprite {
		private var bitmap : Bitmap;
		private var bitmapData : BitmapData;
		private var particles:Array;

		public function MainOne(){
			init();
		}

		private function init():void
		{

			//Create a canvas to draw too
			bitmapData = new BitmapData(500,400,false,0x000000);
			bitmap = new Bitmap(bitmapData);
			addChild(bitmap);

			//Create a set of random particles with a random velocity
			particles = new Array();
			for(var i:int = 0; i<=1000; i++){
				particles.push(new Particle(Math.random()*500,Math.random()*400,Math.random()*2-1,Math.random()*2-1));
			}
			//Wait to be added to stage
			addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
		}

		private function onEnterFrame(event : Event) : void
		{
			//Clear the stage
			bitmapData.fillRect(bitmapData.rect,0x000000);

			//Lock the bitmapdata, while we are updating it.
			bitmapData.lock();

			//Draw particles
			var p:Particle;
			var l : int = particles.length;
			for(var i:int = 0; i<l; i++){
				p = particles[i];
				p.updateAndDraw(bitmapData);
			}

			//We are done updating, unlock the bitmapdata
			bitmapData.unlock();
		}

		private function onAddedToStage(event : Event) : void
		{
			//If added to stage, set stage properties and start listening to the global enterframe.
			stage.frameRate = 30;
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.addEventListener(Event.ENTER_FRAME, onEnterFrame);
		}
	}
}

For clarity sake I’ve omitted a couple of things, but this code runs. If you run it, you’ll see bunch of particles moving at a constant speed, moving offscreen. Our simplest of simple particle system works, so now we can start looking at performance and why we need to change the structure for performance.

Performance, the small issues

If you aware of performance caveats within Flash, you’ll immediately notice a couple of things, amongst which the lesser problems like for instance;

bitmapData.fillRect(bitmapData.rect,0x000000);

A lesser known fact about this piece of code is that the property rect of the bitmapdata is not a static read-only rect, but that every time you query this property a new rect is instantiated. Instantiation is rather expensive in the AVM2, but in this case, it’s called once per frame, thus not a major issue. Still it’s unneeded. Keep this in mind when you do many things per frame with bitmapdata.rect. In general, keep in mind that instantiation & allocation is expensive.

If you ever had one of those swf’s which seemed to hickup every now and then, chances are that it is the garbage collector kicking in. It doesn’t have to be one specific place where you are instancing to many objects, it might be more then one. So keep things clean from the beginning. Also keep in mind that many small performance losses will result in one big one.

The larger performance costs

There’s multiple things we can optimize in this piece of code. For now let’s keep it a bit simple and look at the larger issues, where we get the most gain. One of the main issues is how we store and access the individual particles.

particles = new Array();

We currently store them in an (as always in ActionScript) untyped array. If we’d like to keep the “storage” an array like structure, we would be better off using a Vector for storage, but we can get it even a bit faster by using a linked list instead. For the purposes of this simple particle system, that data structure is enough, as we are only going to linearly iterate over the particle set in one direction. This is called a singly linked list.

Let’s have a look at how that works.

Linked List

First, we modify our Particle class, to contain a link to the next particle in the list, by adding this to its properties.

public var next:Particle;

Then we modify the Main class to instanciated the particles like this :

var particle:Particle;
var previousParticle:Particle;
for(var i:int = 0; i<=1000;i++){
	particle = new Particle(Math.random() * 550, Math.random() * 400, Math.random() * 2 - 1, Math.random() * 2 - 1);
	particle.next = previousParticle;
	previousParticle = particle;
}
firstParticle = particle;

For every particle we create we store a reference to the previous particle in that particle. Then when we are done with the loop we keep a reference to the last created particle. That particle refers to the particle created before that, and so on, until we reach the first particle which has no reference to any particle.

We now update the drawloop to do the following;

var p : Particle = firstParticle;
while (p) {
	p.updateAndDraw(bitmapData);
	p = p.next;
}

Final(ly) ?
Using a linked list instead of an Array helped, but we can even more performance for free, by adding the “final” keyword to the particle class.

final public class Particle {

You would use the final keyword normally to prevent classes from being subclassed, but there is an interesting piece about final in Flash AS3 and AVM2 performance tuning, which by now is an aged document. In this case it indicates that sealing classes using the final keyword helps the AVM because the properties are already resolved and bound.

I find that in Flash Player 10.1 the advantage is less noticable then 10 and before, but it still has a slight performance gain on my machine, although I’ve heard it been debated more then one time. It seems to me also that some platforms/architectures benefit more then others. My naive way of thinking about it is that if you’re not going to subclass it anyway, you might as well finalize it. Simplicity.

Function calling
It may seem obvious to call a method of an object (like with car.drive()), but if you want maximum performance you should avoid function calls. With this in mind, let’s take another look at our draw loop :

var p : Particle = firstParticle;
while (p) {
	p.updateAndDraw(bitmapData);
	p = p.next;
}

The updateAndDraw call here is the costliest thing in the main loop. Not because what it does, but because it is a function. In general, function calling is always going to have some form of overhead, but in the case of Flash / AVM2 / AS3, the cost is exceptionally high. Although this situation has improved with Flash 10.1, the overall hit of just calling a function inside the loop is way to high to be acceptable if we want to achieve high numbers of particles.

Inlining

Inlining is something a compiler does for for you to replace a method call with the actual functionality in place of the function call.

AS3 does not have an inline keyword natively, and the compiler wouldn’t know what to do with it. Joa Ebert’s Apparat tool suite, written in Scala,provides amongst other incredibly handy things a way to do inlining in AS3. I highly recommend using it for larger projects where code style and performance are important. I actually also would highly recommend it for any project where performance is a priority. For this instance though, let’s go to a simpler solution first.

We’ll remove the updateAndDraw method from the particle class and make our main loop look like this.

var p : Particle = firstParticle;
while (p) {
	p.x += p.velX;
	p.y += p.velY;
	bitmapData.setPixel(p.x,p.y,0xFFFFFF);
	p = p.next;
}

Yay. For now you’ll have to take my word for it, but this is faster. (later on in this series will prove this with benchmark tests, I wanted to avoid this post just being a bunch of charts and performance graphs).

Yet another function call.

While looking at this new snippet, immediately you’ll notice another function call in our mainloop.

bitmapData.setPixel(p.x,p.y,0xFFFFFF);

The bitmapData.setPixel is yet another function call being called as many times as there are particles. What’s important to note though is that Flash native API calls are faster then calls to methods in non “api” classes. So although the bitmapdata.setpixel call is costing us more then it should, it still not costs as much as calling a method on one of your objects.

Still, there is cost associated to this function call, and we can avoid it by inlining the method again. setPixel() is an incredibly handy utility function though, so we need to replace its functionality by a piece of code which mimicks its behaviour. Also, we need to write to the bitmapdata’s data by hand.

I’m not going to jump into using Alchemy / FastMemory just yet, so for now we’re going to use the next fastest accessible type that is available in AS3. Vector.

Drawing to a Vector instead

One can avoid drawing to a bitmap using setPixel and use a faster way to do so using a Vector object. While certainly not the fastest way to write to a bitmapdata, it’s probably the fastest way to do it in pure actionscript without any external tools. In comparison to using setPixel in our main loop, it should be a very good performance improvement.

One of the things setPixel did for us was bounds checking. Since we won’t use it anymore, we need to do it ourselves, so that we don’t write to a position in the vector that is outside of the bounds of the vector. At the same time, we’ll use this to resolve another issue. The particles were randomly flying offscreen. Instead of that we’ll respawn them at their starting position. We’ll add these properties to the particle class.

final public class Particle  {

		public var x:Number;
		public var y:Number;
		public var velX:Number;
		public var velY:Number;
		public var spawnX:Number;
		public var spawnY:Number;
		public var next:Particle;

		public function Particle(x:Number, y:Number, velX:Number, velY:Number) {
			this.spawnX = this.x = x;
			this.spawnY = this.y = y;
			this.velX = velX;
			this.velY = velY;
		}
}

And here is our main renderloop :

private function onEnterFrame(event : Event) : void
		{
			// Clear the stage
			bitmapData.lock();
			bitmapData.fillRect(bitmapRect, 0x000000);
			var vec:Vector.<uint> = bitmapData.getVector(bitmapRect);

			var w : int = bitmapRect.width;
			var h : int = bitmapRect.height;
			// Access particles and draw them
			var p : Particle = firstParticle;
			while (p) {
				p.x += p.velX;
				p.y += p.velY;
				if(p.x > w || p.x < 0){
					p.x = p.spawnX;
				}
				if (p.y > h || p.y < 0) {
					p.y = p.spawnY;
				}
				vec[int(w*int(p.y) + int(p.x))] = 0xFFFFFFFF;
				p = p.next;
			}
			bitmapData.setVector(bitmapRect, vec);
			bitmapData.unlock();
		}

While this setup is still far from optimal from a performance perspective, we’ve got a reasonably fast way to render 10 to 20k particles to screen.

One note here is the bitmapData.getVector and setVector.
This still isn’t that optimized – the function call “BitmapData.getVector” creates a new Vector object every time we call it, and as you know, creating objects takes CPU and memory allocation. Ideally the function should allow us to pass it a pre-existing vector object for it to populate with data. There are a couple of examples of this throughout the Flash API’s, and I truly hope Adobe will address these in future versions of the Flash Player. The benefit here of using getVector is that we can quickly clear the entire vector. Or if you would play around with this, you could not fillrect the bitmapdata and blur it slightly every frame.

For reference, what we have now looks like this, and can be download as source here: MainOneVersionOne (635)

So far, simple enough, right ?

I’ve kept everything quite simple so far to illustrate a couple of mostly obvious performance hints, and to set a frame of reference for the follow up article, part two. Technically this solution is far from the optimal solution to run particles. But for experimenting with moving the particles in a more interesting fashion, its good enough for Part One of this series. The benefit is that we can still express all the code in ActionScript. We’ll add a little bit of PixelBender in the mix to get comfortable with it and use it as an example of manipulating data with PixelBender.

Velocity Field ?

Visually this example is completely boring, so let’s make it a bit more interesting. We’ll start by making the particles move to a background pattern. We’ll use some perlin noise and pixelbender to generate a vector field for the particles to read from.

We’ll use a vector similar to the vector we are using to draw to the bitmapdata we did earlier, and mix in some perlin noise to convert grayscale perlin noise to velocities to be quickly looked up by the particles. We start by adding some code to the Main class, let’s start with the init method.

private function init():void
{
	//Get some perlin noise in grayscale to read in our pixelbender filter.
	var perlinMap:BitmapData = new BitmapData(WIDTH, HEIGHT, false, 0x000000);
	perlinMap.perlinNoise(128, 128, 6, 123456, true, false,7,true);

	//Load the embedded shader bytearray into a new shader.
	var velocityConverterShader : Shader = new Shader(new VelocityConverter() as ByteArray);
	var velocityConverterFilter : ShaderFilter = new ShaderFilter(velocityConverterShader);

	//Create a new temporary bitmapdata to write the filter result too.
	var perlinVelocityMap : BitmapData = perlinMap.clone();
	perlinVelocityMap.applyFilter(perlinMap, perlinMap.rect, perlinMap.rect.topLeft, velocityConverterFilter);

	// And get the result into a fastly readable vector
	velocityVector = perlinVelocityMap.getVector(perlinVelocityMap.rect);

	//Nicely dispose of the memory used by the two bitmapdata's.
	perlinVelocityMap.dispose();
	perlinMap.dispose();

	//Create a canvas to draw too
	bitmapData = new BitmapData(WIDTH, HEIGHT, false, 0x000000);
	bitmapRect = bitmapData.rect;
	bitmap = new Bitmap(bitmapData);
	addChild(bitmap);

	//Initialize the particles and keep them as a linked list.
	var particle:Particle;
	var previousParticle:Particle;
	for(var i:int = 0; i<=1000;i++){
		particle = new Particle(Math.random() * WIDTH, Math.random() * HEIGHT, Math.random() * 2 - 1, Math.random() * 2 - 1);
		particle.next = previousParticle;
		previousParticle = particle;
	}
	firstParticle = particle;

	//Wait to be added to stage
	addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
}

As you can see we added some code and a new property to our mainclass, to hold a reference to a “velocity vector”. This Vector will contain values much like colors. There’s many ways to get pixelbender to output data. To be able to read the data quickly in our mainloop, we need a vector again. So the easiest way to get a vector with uint’s from a pixelbender is to actually let it render to a bitmapdata.

The reason we are using 2 bitmapdata’s is that it’s significantly cheaper to instanciate them yourself and pass them, then to pass 1 bitmapdata for pixelbender to use as input and output, as it will allocate a block of memory for the output in any case. This way it’s faster and we have more control.

After the pixelbender filter has done it processing, we simple do a getVector on the bitmapdata to get the result into a Vector.<uint>.

A tiny bit of pixelbending

To get familiar with pixelbender kernels, we’re going to use one to calculate the data in our velocity field with. The pixelbender filter is one of a very simple kind, let’s have a look at it. It only has one input and it samples four pixels for every pixel it evaluates. Sampling from data within the Pixelbender is quite heavy, but for now we will only run this filter during the initialization of our swf. It might be fast enough to run every frame even.

<languageVersion : 1.0;>

kernel VelocityConverter
<   namespace : "com.unitzeroone";
    vendor : "UnitZeroOne";
    version : 1;
>
{
    input image4 src;
    output pixel4 dst;

    void
    evaluatePixel()
    {
        const float halve = 0.5;
        const float3 offsets = float3(0.0,1.0,-1.0);//We'll swizzle these around in our sampling.
        float4 left = sampleNearest(src,outCoord()-offsets.zx);
        float4 right = sampleNearest(src,outCoord()-offsets.yx);
        float4 top = sampleNearest(src,outCoord()-offsets.xz);
        float4 bottom  = sampleNearest(src,outCoord()-offsets.xy);

        //We'll store the slopes in green and blue, the two lower bytes in the vector.
        dst.r = 0.0;// We don't need to set r, but on some older flash players this caused bugs.
        dst.g = ((left.b-right.b)*halve)+halve;//Get the slope value between left and right, and normalize to 0-1
        dst.b = ((top.b - bottom.b)*halve)+halve;//Get the slope value between top and bottom and normalize to 0-1
        dst.a = 1.0;//We're using four channels, because we use shaderfilter.

    }
}

What this filter does is that it calculates the so called central difference for every pixel, using its connecting neighbours and store them back into the color channels. Let’s look at its input and output to have a visual reference before discussing it further.

The input & output.

Although that wikipedia page about the central difference might have scared you off, all in all what it does is very simple. For every pixel you look at the connecting neighbours in both directions and you look at the difference between that and store that. Note that we are normalizing the value, so that the maximum negative value of -1 and the maximum value of +1 fit in a range 0 to 1. This way we can read these values later on in our mainloop. We store the result for the difference on the horizontal axis in the green channel and the result for the vertical axis in the blue channel, hence the blue green teint of the image.

It’s good to note that PixelBender really makes these types of image calculations fast and simple. Long before PixelBender we had to do this using combinations of filters and copy channels to do this quickly enough. My first experiment with fast bumpmapping from a long, long time ago used that way of doing it. When I started working on Papervision3D it resulted in this experiment.

Making things move

Now that we have this new set of data, how do we make our particles dance to it ? The reason we wrote too a vector uint is so that we can read from it quickly. But we store the data in two different channels, being blue and green. Let’s take that data out and manipulate our particles velocities using it.

Our main loop will look something like this;

while (p) {
	//Add the current velocity to the particle position
	p.x += p.velX;
	p.y += p.velY;

	//Keep the particles in bounds
	if(p.x > w || p.x < 0){
		p.x = p.spawnX;
	}
	if (p.y > h || p.y < 0) {
		p.y = p.spawnY;
	}

	//Calculate the new position index;
	pos = (w*int(p.y) + int(p.x));

	//Draw the pixel
	vec[pos] = 0xFFFFFFFF;

	// Read the velocityfield at the new particles position
	var velocities : int = velocityVector[pos];
	var velXU : int = ((velocities>>8)&0xFF)-127.5;
	var velYU : int = ((velocities)&0xFF)-127.5;

	//Add a fraction of the position velocity to the current velocity
	p.velX += velXU*.073;
	p.velY += velYU*.073;

	// Dampen the current particle velocity
	p.velX = p.velX*.99;
	p.velY = p.velY*.99;

	p = p.next;
}

This bit of actionscript :

var velXU : int = ((velocities>>8)&0xFF)-127.5;
var velYU : int = ((velocities)&0xFF)-127.5;

If your unfamilar with masking and bitwise operations, this might look slightly strange. But if you have worked with colors using setPixel before, you might be familiar with the pattern here. Basically we extract the “color” as output by PixelBender from the green and blue channel. I put color in quotes there, because it’s not what we use it for. We simple use the byte packing into uint’s as a way to quickly access one value in a vector (which is the heaviest), and then unpack it into two of its components. A uint in Flash is 32 bit, so it contains 4 bytes. In theory we have 2 bytes left for storing other data. More on that in part two.

And it does almost exactly the opposite of what this did in the pixelbender loop :

dst.g = ((left.b-right.b)*0.5)+0.5;
dst.b = ((top.b - bottom.b)*0.5)+0.5;

The only difference is that pixelbender treats the color value as a range between 0-1 and that our actionscript values will now be filled with a value between -127.5 and 127.5. We handle putting the particle velocities to reasonable values by multiplying them by a rather small value. Play around with the values if you like.

To assure that the particles don’t pick up an infinite speed we dampen it by multiplying by a value near to one, as to only slightly lower it every loop.

p.velX = p.velX*.99;
p.velY = p.velY*.99;

So is it magical yet ?

If we look at what it looks like now with a thousand particles, we see this:

So, no it’s still rather uninteresting. Although our particles do seem to have to taken up a life on their own.

Adding complexity by adding the numbers

The particles seem to settle in areas, and the randomness of their movement and location is worsened by the fact that they are moving over perlin noise, where the noise part of that implies it’s somewhat random.

As I said at the beginning of this post, part of the percieved complexity of a particle system is in its numbers. What happens if we replace the perlin noise by a picture and add a lot more particles, let’s say 20.000 ? And then tweak the values a bit ?

Click here to see what that looks like.

Get the source here : Session One Final Source (716)

Closing and what will follow

The length of this simple introductory Session One already got way out of hand, so it’s time to close for this session, which means that unfortunately Alchemy is saved for next week. We’ve covered the basics of a reasonably performant particle system in pure, directly compilable AS3.

To continue this series and make the example code do a lot more then it does now, we need to start diving much deeper in PixelBender and the Alchemy-memory within Flash Player. We’ll be able to increase the number of particles to a much higher count then 20.000 of them using these techniques and hopefully be able to fully understand why and how. Along the way we’ll be able to look at how these technologies function inside the Flash Player.

Hopefully, we’ll polish up this example to a point where it’s starting to become interesting to look at. You’d be surprised to see how close we are to achieving something like the Particle Reactor with the current source code. But to be able to fully explain ways of using PixelBender and Alchemy, we need about another time the length of this post.

Until then, I would love to see your experiments based upon the source code above. If you do happen to do anything with it, please send it over and if there is enough response, maybe we’ll add it to next the post. I’ll give you some hints; dynamic vector fields, colors, trails.

I would like to thank Seb Lee-Delisle for reviewing this post and helping me to get it cleaner, better and more to the point. Another big thank you to Tim Knip for reading and pointing out the missing explanations.

I would also greatly appreciate any feedback on this article from you. I’m new to writing large articles / tutorials like this, and would love to hear what you think and what you would like to see.

Last week I reveiled my plan to revive this blog and start getting regular posts on here again. It had been cooking for a while and I had decided that the first thing to do to revive the blog was to start with a long overdue post about particles, mainly sparked because of the interest in the Bloom Particles (mirror without preloader) I did for the unfortunately cancelled Bloom conference. The other part was that I really wanted to get it out and get particles out of my system for a while. I had promised to post about this for quite some time, but with the blog not being used, it was a daunting task. It turns out I find it much harder to make blogposts then little experiments. This post is about that. I apologize up front for it being a bit of a personal story before anything else. It is however, the start of …

The Particle Sessions

I decided I wanted to take and expand and continue on what I explained in my Skunkworks talk (video of that talk at FFK here), where I used this example to show how simple these systems work in ActionScript and how something can create seemingly visual complexity with fairly simple and atomic code. But since this is not a 1 hour long session, but a blog, I can dive much deeper in the technical parts. Never truly 100% happy about the code in the Bloom piece, I had since then already done a couple of new things which particles. I slightly elaborated on that  and my other distractions in my session titled “The Discontinuity” at Flash on the Beach in a combination of Cinder and Flash Experiments (experiments one and two). That session was taped and will hopefully find it’s way online as a video soon, in the mean time watch some of the fantastic speakers here. I wanted to include the newer things in that talk. I’ll be posting multiple things here, and bundle them under the name, the Particles Sessions.

The Discontinuity

As I stated in my previous post, I’ve decided to take it easy with the conferences this year. The title I chose for that Flash on the Beach talk, was indeed pre-concieved. Taking a bit off from that would free up some time for the blog and experiments too; I have been thinking about what I want to communicate through this blog and how it can substitute what I normally talk about at conferences. I had decided that for the first particle post, I wanted not only to use another simple example of particles to explain particles, but to explain many facets of Flash, ActionScript, Pixelbender, Alchemy and creative development in general.

The Distractions

So I set out writing a new version of the fairly simple particles for the blog. In a fractal-like twist, what happened is that I for the 4th time I started exploring particles by writing code for this “tutorial” and then getting entirely distracted with just playing around with it. It’s the creative part about development I truly love. Play, learn and play. The side effect of toying around with ideas is that mostly you fail and every now and then find something interesting and new to play with. But in both instances you learn valuable lessons. This time this play lead me to something similar, yet new. What I failed at was the original goal of getting the blog post finally done.

Quasimondo : ” Have you tried it with video yet ? “

After writing the new example code, I felt it was missing something and I showed it to Mario Klingemann, who while discussing it said : “Have you tried it with video yet ?”. The code wasn’t well suited for that, and I didn’t think much of it, but as a quick distraction and experiment, I started hacking the nicely clean particle code to do some video. It didn’t work well in the first instance, but after a little bit more of code cluttering and quick hacks it worked nicely. Then I added in some of Keith Peters’s minimalcomps way to quick (they’re so easy to put in, I didn’t really do it nicely) and put it online and tweeted it. I then started looking at my blog and found it was broken. Who thought digital things would break out of lack of maintenance ?

Even more distractions

What happened with the particles experiment somewhat surprised me. I didn’t see it as a particular different thing of what I normally play around with and execution could have been way better. But the particle video experiment quickly got some strangely high amounts of hits. Most of them from Twitter, StumbleUpon, Reddit and Hackernews. At this point, my website has trafficked near 1Tb worth of data of that experiment, and amassed a for this site truly staggering amount of visitors. I started checking the comments out.

With very positive reviews, one thing stood out; I had preselected 3 videos and put those in, to show the effect on different video’s. But based on the feedback of above mentioned blogs, people wanted to be able to select their own videos. In my mind I had a small part of the following Saturday aside to actually write the particles post, but instead used that time to add in quick, hacked and experimental support for YouTube. It’s been working pretty stable. But again I failed at finishing the particles post.

The Fail, not again.

So after mutilating the code yet more I had now running a bandwidth eating experiment on my website, but no blogpost, the goal which started this to begin with. The normal work week hit and I do also enjoy working on Aviary, which has priority. I ended up using pieces of time normally wasted on CoD:BO to write snippets of code and chunks of explanatory text. It became apparent one post wouldn’t be enough alone, and I’ve decided to make it into a series. This is to be thorough and an actual reference towards the technologies and ideas used, rather then quickly touching upon something. The prologue alone had almost become to long for one post and had been going to a couple of revisions.

Yesterday I had a quick peek at compiling a WebM decoder for Flash using Alchemy and the opensource libvpx, which contains the VP8 codec. Although it does work in the form of a very early form of their examples running using swfbridge, it’s quite slow at this point in time. I was tempted to not post anything about the particles again and play with it more this night. But I decided I didn’t want to fail again, so particles first. WebM can wait.

Next Monday you can expect the first post surrounding the technical details of a simple but fast particle system in Flash. I’ll start out explaining the bloom particles, it’s working and it’s flaws. And then we’ll start looking at (yet again) combining Alchemy and Pixelbender to make a faster version of that. We’ll dive deep into the details of Alchemy and some experiments to combine them with Pixelbender.

This post is also way of forcing myself to get Part 1 of this multipart part series neatly together this weekend. And finally get particles of my todo list and out of my system for a while…unless I get distracted. My apologies for the delay.

Hello there, and welcome again. So, this blog post at the beginning of 2011 is a result of my New Years resolution, which is to revive my blog to a fully functional and lively place. I apologize for it being mostly deserted. I left it alone since May 2010. Most of the reason behind the blog falling behind was that year’s fault really, not mine.

It was a good year. I started doing a project for Aviary and was honored to speak at many great conferences of the web industry. One of the most note worthy events for me personally was also to be part of Adobe FlashCamp Tokyo and Seoul. It was a great trip and a privilege to hang out with such heroes as Mike Chambers, Mario Klingemann, Lee Brimelow and Erik Natzke. You can see Lee’s video report of that trip in Flasher Magazine 3 on Vimeo. (Doug McCune is alive and well, despite what that video says).

Looking ahead, this year promises to be an equally great year. In the Flash space, one of my long time wishes, GPU support for Flash is on the shortlist for a public beta in this year. More on that in a later blog. Privately, many things are happening and I’m loving it. Let’s just say that good times are ahead.

As for the reasoning for why this year my blog will get updated on a regular basis; this year I’ll take it easy on the conferences. I’m not saying I won’t be speaking or going to any, but this year has so many things going on for me (both work and private) that I decided to at least take it easy for a while. How long that “while” is, I haven’t decided.

I’ll miss all the great people, but at the same time this will give me more time to focus, work and enjoy life. Also for this reason, I’ve decided the blog will be the main form of sharing information and hopefully share useful work and thoughts.

As I started thinking about topics, I realized I still had quite a backlog of things still to put out there publicly and decided to tackle them one by one. My last talk, aptly named “The Discontinuity” at Flash on the Beach in Brighton has ran exactly one time, with some still in progress work, which I’d like to talk about. Also, things like FlashModPlug and my GNURocket implementation are still to be publicized. About that GNURocket client implementation, 2010 was also the year of a true demoscene contribution, in the form of Area Unstable (video) (pouet download). This was made together with Sander.Focus (graphics) and Gloom303 (music,sync).

I’ve also branched out to doing iOS development and working on experiments using both OpenFrameworks and Cinder. So there’s many things still to blog about this year. But, one thing at a time, so I decided to work through a backlog and start with some Flash particle experimentation. My next post, due tomorrow, will outline the working and technicalities about this thing; Rendering Video with White Particles (Flash).

[Update, the blog gave up on me, and I had to reinstall it. Here's my blog in it's new form].

Nexus One running Flash Player 10.1 from Ralph Hauwert on Vimeo.

This is a video of the Nexus One with a pre-release version of Adobe Flash Player 10.1. It does not represent the final quality of the Flash Player on this specific device. But it’s pretty good as is!

This is the Nexus One running 2 demos. First a Nexus one specific version of the “Milkyball“, which is adjusted in resolution and screensize.

Second a non-adjusted version of FlashModPlug, an experimental project I’m currently working on. It’s a port and wrapper of LibModPlug, running inside the Flash Player through Adobe Alchemy.

Conclusion 10.1 on the Nexus is really, really fast!

(go to vimeo for the full resolution version). (link to nexus demo)

Long time no see! I’ve been busy, sorry. First off all, I want to congratulate you on the great show today. Wow, that iPad is truly one of those things everyone is going to want to have, like your previous successes with the iPod and iPhone. I take my hat off for that! And wow, what a lead up to the show. Probably the first hype of 2010. And do you guys know how to keep a secret and then give a great show unveiling it.

That being said, I felt as an avid Apple products user as well as your friend, (you know I own a total of 3 Macbooks, a plethora of Airports and have converted nearly my entire family to buy one of those nice machines of yours) (actually it was Grant who got me into buying one) it’s my duty to inform you that I think something went wrong during your presentation. When you were showing the web capabilities of the iPad, something was missing in it’s browser (see screen-shot above). As your keynote and product presentations are normally flawless (ah, well, maybe not always), I think you might have missed this one.

You touted the iPad’s (great product name, btw) web capabilities as being amazing, perfect, you know, the regular Apple thing. But during the presentation I couldn’t help but notice that little “missing plugin” logo we all know from the iPhone. Now, I was thinking that this might have been one of those very exotic plugins of back in the day, like Director or Realplayer. But, as it turned out, the missing plugin was the Flash Player.

As you’ve started the introduction to the iPad with a reference to Netbooks, and we can safely say that most netbooks support Flash, I think we are both safe to assume that to be on par with those netbooks, the minimum you should have is a fully featured browser?
I mean, this is not some kind of small screen device with limited capabilities in terms of performance and graphics. It’s a fully featured machine ? Be it with that amazing iPhone touch interface. And be it in a slightly new package intended for true casual and business use. (Honestly, you kind of confused me, games and reading books ? I thought the gaming generation didn’t read and vice-versa, ah we’ll talk about that after you write me back on this letter).

Anyway, I think it must have been a demonstration error, because it seemed like the iPad didn’t support Flash?

Mythhackers.

Ok, now, who am I kidding. I know you’re a perfectionist. And you’re a man of subtle remarks too. Between you and me, you can admit it. We both know that little missing plugin logo wasn’t an accident. I think we both know why you did it. It must have been your kind of humor, getting back at that little prank  Kevin and Johnny of Adobe pulled on you at Adobe MAX. (see picture above too). You have to admit, that was funny. Man, we all laughed about that one. But hey, I always think that if they’re teasing you, they must want your attention. All in all, they didn’t mean any harm.

(I do agree with you that they should’ve spent some more cash on the explosion effect in the video, being the maker of some of the most premiere video effect software out there, but hey, it was a good prank video, executed very well).

Now, given some of the easter eggs in Mac OS X, which essentially is your baby, through that other thing you did, with that next-cube thing you were so enthousiastic about back in the day, I take it you have a fair amount of subtle humor in you. It always reflects in your letters and I always have to laugh when I think about how you made that joke about a mouse only needing one button. But, as always, there’s a time for fun and a time for seriousness. And you seriously can’t mean that the full featured web browser doesn’t support the biggest plugin out there?

If you do mean it, I can understand why. I’ve never really bought that, “Flash is too slow for the iPhone” story you told everyone at that party. I also know for a fact that RIM, Nokia, Samsung, NVidia and all those guys also didn’t believe it.

And yeah, I know that little stunt Adobe pulled with compiling directly from Flash to iPhone isn’t the same as running it in the browser, but hey, it is the output of Flash running on an iPhone. And surely there’s a lot of content which can now be readily available in the App store. And if that puny little ARM processor in an iPhone can, then surely that incredible piece of custom silicon you so proudly called the Apple A4 can. (it’s ARM too, right?).

Your nightmare ?

Ahh, going off track, I was saying that I understood why you would not want Flash. I know having rich, web enabled apps which don’t go through the App store can be a scary thought, food for nightmares. I know you’ve had a thing for nightmares, especially after Monster’s inc. But Steve, I have to tell you. A device which is intended for casual and easy use with all the slickness Apple always brings, but doesn’t support so much web content? Come on, what will the people think? Those netbooks you called slow and PC-ish, can run Flash, but Apple’s state of the art technology can’t?

Yeah, I know it’s hard to have that piece of proprietary software running so much content essentially being a separate platform, while having no control over it. But that’s why Kevin and Johhny where throwing those jokes at you. They want to help you, really. And again between you and me, isn’t it true that you’re always selling computers when those guys at Adobe come up with a new version of their creativity software?

I would like to also come with a more serious note, as your friend, I know I can remind you of this one. Do you remember that when I was still using a PC, we were always talking sh*t about those guys at Microsoft for dominating the market? About how they pulled that monopoly thing on Netscape with that “lovely” (I still remember the word you had for it) browser we all still despise, Internet Explorer. And what they did to Real by bundling that Mediaplayer? Well, as it turns out, they kind of ran into some anti-trust issues with the European Union. I hear it was quite costly for Bill. While I agree the iPhone was a completely different thing, you can’t bring out a computer and expect everyone to think it’s just a big iPhone and then pull all that stuff off that our friend at Microsoft once did, right?

Yeah, yeah, I know what you’re going to say. Flash is proprietary too and there should be an open alternative to it. But honestly, in terms of open initiatives competing with it, it seems those HTML5 guys are still not ready for it, and although having H.264 video support native to the browser is nice, it hardly replaces what Flash can do right now. Not to mention all that content already being offered by Flash, people can’t see on the magnificent iPad. If pure HTML5 content is even 1% of that, we both know that would be a lot. I do feel you should be open to any plugin, honestly, so the guys at MS/Silverlight and Unity3D, for instance, also get a shot. All in all, it’s your product’s users who are going to suffer for it otherwise. Now, as I’ve made my living building Flash apps, of course I am biased, but doesn’t every developer deserve a fair shot?

You're the man!

You were always this idealist, but this thing is making you look like you are just plain greedy, at the cost of your end users, not being able to access all web content. Give me back the idealist Steve, I love that guy! (I’ve included an old picture of you to remind you of that man).

Now, you know I do admire that you’re not like all those others and you’re doing things your way (and it seems to work), I think you’re going down the wrong path on this one, or this might have been just an error. If it was, just fix it before release, and we’ll keep it between you and me.

Sincerest Regards, your friend,
Ralph.

(quick note, can you make Johnathan stop saying the word Magical, every time he’s talking about one of the products he designs ? Frankly, it’s a bit annoying. And he’s not designing unicorns or leprechauns.)

(quick note 2 : if you do manage to talk to Kevin or Shantanu at the next party, ask them if their engineering people can talk to your engineering people about that video hardware support and performance issues, I think it would make many of our friends happy).

Milkyball, a further extension of my Triangle3D experimentation, used in my presentation of end 2009. Click on the shape to see the magic vertexmap.

PixelBender + Flash raytracer. Work in progress.

I posted both of these earlier on my twitter (@unitzeroone), but they didn’t make the blog as of yet. More details in future posts.