Skip to content
Nov 13 09

Unpredictable Flash

by pixelpracht

In the last couple of months I’ve programmed a lot of AS3 code. And when there was performance critical code to write it often got frustrating. The problem is not that AS3 compiles into bytecode which is running on a virtual machine. It’s not the lack of hardware acceleration or threading. The problem is a lack of transparency – it’s often impossible to find the best approach without trying and comparing all the different possible options!

Let me give you an example: I have a source Bitmap object and want to draw it with a PixelBender shader in my target buffer.

var target:BitmapData;
var source:Bitmap;
...
source.blendShader = myShader;
target.draw(source, matrix, colorTransform, BlendMode.SHADER, clipRectangle);

Welcome to the first pitfall: The clipRectangle does work as promised but it doesn’t affect the performance. You can set it to a one pixel square and it still evaluates every pixel in the target buffer. Good to know? Yeah, but it’s not in the docs. Not sure that the people at Adobe even know about it.

So, if the area I need to update is small enough it’s more efficient to copy the relevant pixels into an intermediate buffer apply the shader on it and copy it back. copyPixels comes to mind, right? Yes, that will work. And we all know how fast that is. But besides copyPixels there’s also a getPixels and a getVector method that allows me to extract a rectangular portion of the source. How fast are these? Turns out that copyPixels is the winner, getVector is about 50% slower and getPixels which basically does the same thing is 500% slower then copyPixels. Dooh!

But why do I even mention alternatives to the copyPixels way when it’s fast and everyone that reads blogs knows that it’s fast? Because getVector is a valid alternative. Turns out there’s quite some overhead to setting up and executing a pixelbender Shader. And after some more testing it turn’s out that for my specific simple shader the fastest option to update small rectangles in the target buffer is to just extract that portion using getVector, then iterate over the contents of a target and a source vector, do the calculations in plain Actionscript and copy the result back using setVector.

It’s a matter of luck and stubbornness that the tech demo I’ve been working on was successfully pitched and not canned as “not doable in flash”. Writing bytecode directly can’t be any harder then that. :P

Nov 5 09

Let’s blog!

by pixelpracht

It bugged me for quite some while that the nice domain I’ve been holding for years was linking to an increasingly outdated website showing off some student projects of mine. Considering how easy it is to setup a blog (you read the prove) I decided I’d give it a try.

First there’s a topic to chose, though. Something I know about. And something other’s might care to read about. The only topic that stands a chance to fulfill both requirements is Game Development.

I wanted to create games for the better part of my life: It started when I wrote a Harry Potter broom-riding game in 2000 and noticed with surprise that this simple game I programmed with my self-tought Delphi knowledge was spread and enjoyed by thousands of Harry Potter fans. I received mails of fans every day telling me about their highscore or making redicoulous feature requests. And I realized that making games could be more fun then playing them! :)

Now, 10 years later, I’m earning my living as a game programmer. And I will use this place to share my thoughts and other creative output. Let’s see where that leads to!