Judging by the number of results Google returns, this is a pretty fringe case (that or I’m exceptionally stupid… hush). Regardless, it’s a problem that has been plaguing me for the past few months. If it weren’t for my genius programmery brother I would have never found it either. But thanks to him I’m now savvy to what’s termed as “rounding errors”. They even sound evil.

Here’s an example with code…

Below we define our dimensions grabbed from pixels (raw bitmapData from some loaded file elsewhere). We just want to analyze a quarter of the image, hence we’re dividing both dimensions by 2. We also instantiate the array (a fixed-length Vector) we’ll be iterating through:

1
2
3
4
5

var w:int = pixels.width / 2;
var h:int = pixels.height / 2;
var _l:int = w * h;
var _rc:Rectangle = new Rectangle(0, 0, w, h);
array = new Vector.<uint>(_l, true);

Awesome. Now somewhere else in the code (say, an update method) we want to assign a chunk of pixel data to the array so we can pick through them one by one:

6
7
8
9
10
11
12

_rc.x = pixels.x;
_rc.y = pixels.y;
array = pixels.getVector(_rc);
for (i; i < _l; ++i) {
	_pixel = array[i];
	var alpha:uint = _pixel >> 24;
}

Alright, looks mighty fine. We’re just checkin’ out the alpha value in those pixels, you know whatever. BUT WAIT. While we’re running this code, the values for pixels.x and pixels.y are changing because our source image is moving around the stage. And guess what? Without pixel snapping on, we’re getting floating point values for those coordinates even though they’re typed as ints. This wouldn’t normally be a problem but since we’re extracting other pixel data using those values, they need to be floored or else we’ll get the rounding error I discussed above.

So to fix this bitch we simply change lines 6 and 7 to:

6
7

_rc.x = int(pixels.x);
_rc.y = int(pixels.y);

…and viola, no more error. (I used int() instead of Math.floor() because it’s hella faster). So I hope that helped someone out there because I sure as hell needed it Good luck and have fun.

1. Best resources for beginners
2. Syntax overview
3. More performance tips
4. Realtime use of Pixel Bender
   1. Asynchronous mode
   2. Synchronous mode
5. Conclusion

When I set out to write a very simple Pixel Bender (PB) kernel/script thingy, I expected it to be relatively straight-forward, mostly because Adobe has been so good writing quality documentation for its products and/or there is a wealth of info on their products produced by their users. Unfortunately I didn’t find the dev guide in the Help menu and I missed some key AS3 bits from the links I’ll post below, but even so I still had a lot of trouble finding some info that really should already have been out on the interwebs. So this post is to fill in the gaps when going from AS3 to Pixel Bender.
Hope it helps

Best resources for beginners

Here’s the best tutorials and explanations I’ve found so far:

• The official guide and reference. Slap that F1 key! Also, don’t forget the Help menu in the toolkit like I did (there’s the PB-specific language spec and dev guide there).
• Using PB as a calculator. Completes the official tutorial.
• Great in-depth article with general+performance tips.
• Very straight-forward examples + comedy. Can’t go wrong there.
• Nice user article on optimizations and some speed tests (turns out, for input bitmapData beats ByteArray beats Vector.)

Syntax overview

As a casual programmer of high-level languages and no mid- to low-level ones, I was thrown off by PB’s awkward syntax. It’s strongly typed, which is fine, except I’m not familiar with low-level languages like C or any previous shader language (PB is based on GLSL from what I hear). Here’s a basic difference:

AS3: var i:Number = 12;
…in PB is: float i = 12.0;
The decimal in 12.0 tells PB it’s a floating point number. If it was just 12 PB would think it’s an int.

When dealing with “vectors” (which are arrays, as in Flash 10’s odd use of the word “vector”) it’s float2 i = float2(12.0, 2.0). Notice there’s no brackets or anything suggesting any type of array present. It’s simply the type + how big the array is, eg float3. It goes up to 4, for the 4 channels in images: Red, Green, Blue, Alpha). Then, as you can see, intializing the array is a simple matter of putting in the numbers you said would be there. So float4(1.0, 24.2, 0.1, 3.4) is valid whereas float2(1.0, 24.2, 2) is not, because there’s an extra number in there and it’s an int (adding insult to injury).

An important thing to keep in mind is that Pixel Bender sees channels in the order described above (RGBA). This little detail cost me a bit of time because I’m used to AS3’s order of ARGB–the alpha channel is first in AS3 while it’s last in PB.

To use any of the built-in functions you simply call them as they appear in the reference doc: all(x); atan(x,y); etc., no Math calls like we have to do in Flash (this through me for a loop, lemme tell ya).

For those of you who use the shortcut operations like var i:int = foo < bar ? foo : bar;, then you'll be pleased to hear they're supported in PB too. Just about the only thing "Hydra" (formally the codename for Pixel Bender, now--I guess--the name of the PB Flash implementation) does not support is loops of any kind and their related break/continue statements. That last bit is bad because there are times when I want to stop the filter if a certain condition is met. You just have to design your logic to take this into account from the start.

That's the basics but take special note that shader.data is actually an array, so you can do some naughty stuff like iterate through some kinky data and set the input as shader.data['whatever'+i].input = kinky[i]. Also note that in order to set the input for a shader in AS3 you must set it to shader.data.vdipb.INPUT = inputImage where vdipb is the variable name you declared in the PB shader itself.

More performance tips

Turns out that after I converted my kernel from using boolean methods (like boolean4() etc.) to if statements, it consistently executed faster. I also got some fractional FPS increases by using the age-old optimization of putting real values (eg 1.2) in the evaluation statement instead of references (eg pixel.r). See the last blog I linked above for some other obvious and not-so-obvious performance tips.

PB math is much faster than straight AS3 math but it's slightly brighter (I wouldn't say it shines per se...) when it runs in asynchronous mode, which is enabled by using ShaderJob. You use addEventListener(Event:ShaderEvent...) and then run start(false) to put it in asynchronous mode (the param is waitForCompletion and it's already false by default). See Ryan's post for a great example of how the ShaderJob has to be setup (Squize's post, linked above, is an even clearer example).

Realtime use of Pixel Bender

Asynchronous mode

Reading the above linked performance tips for PB you, like me, might be thinking "OH MAN I can rule the universe with ShaderJob doing bitchwork like heavy collision solving" and you'd be totally wrong. You only have to set the input for a shader once, but you do have to create a new ShaderJob per computation of the filter every frame/tick. This is the depressing because ShaderJob takes a LONG time to start up and it, unlike the job itself, does use CPU from Flash's main thread--you do not get the asynchronous hotness until the actual job is started. And it is sloooooowwwww. Unless you're doing some serious number crunching or temporary special effect, you will not see a huge benefit from using PB in your game.

To be clear, ShaderJob works well enough for realtime usage but my experiments have shown that it's not fast enough to be executed every frame (unless you're SWF is running at 20 FPS or so). I tried to get it to fulfill my game's collision detection system by processing the entire map, but PB just couldn't handle the job. Still, I do recommend you try it (using Squize's recursive implementation) and see if it works for you. Just keep your hopes down

Synchronous mode

You can set ShaderJob.start(true) but if you're going the synchronous route, I suggest applying your Pixel Bender kernel by using the filter method. It starts up much faster than ShaderJob and doesn't have to be restarted every time you want to update the input. You do have to wait for it to finish processing before it will move to the next line in your code though, but as I mentioned above, PB math is a lot faster than AS3's Math library. So if you're doing something intense(r) like severe image distortion then PB is definitely worth a shot, but if it's just conditionals then you're probably better off in pure AS3 land.

Conclusion

Besides doing complex calculations, another place where PB would really help though is processing large (like 600 or 10000 pixels wide or bigger) images. It loops through each pixel faster than AS3 does. But remember that in AS3 you can do loops, so easily skipping pixels (using the continue statement) can result in some significant performance gains if you're not processing all the pixels in the input data (eg skipping transparent pixels). There's a lot of pro/cons so experimenting is, as always, the way to go (if you can afford it).

So there it is, all the info I wish was out there when I started learning PB (I can't stop thinking of Peanut Butter!). Hope some of it was helpful and of course I could be wrong about something (except about declaring input once, I've heard otherwise but in practice it worked fine) so please don't hesitate to correct me if so. Good luck and have fun

I’ve been working on a couple game concepts and want to prototype a few more before committing to one to build out. I’ve been hacking the hell out of Flixel, which I’ve decided to use for a most of the games. There’s a screenshot of game3 on the right there. Weird, eh? Also fugly, but it’s placeholder art so there. I have a new collision detection system for it that I’ll be posting about eventually (at least, I’ve never heard of it before).

The microtransaction (MTX) dilemma

I’m really excited about all the new services that have been released to allow Flash developers to monetize their games through microtransactions. I fucking hate ads, plus the ROI of them in Flash games is usually shit. Many many years ago I knew microtransactions (MTX) were the future of digital content and I’m pleased to see the idea coming to the mainstream (in America at least, Asia was quicker on it as usual).

The problem I’m seeing with MTX is that Flash developers need to try a lot harder by making much bigger games in order to really reap the rewards. Before, you could make a pretty simple, fun and addictive game and monetize it easily with ads. But with MTX, you can’t do that as easily since you need to build more content for players to buy into. For example, to me, putting premium content in a Tower Defense game isn’t viable–the game concept is so small that I doubt anyone is going to pay anything for more turrets or maps (for example). There just isn’t enough game there.

So in order to realistically bring MTX into our games I think we’re going to have to build much bigger games, and that kind of sucks because that makes it much harder for indie devs to make good on their work. Hell, this might actually decrease the quality of Flash games due to the higher gate devs will need to jump to get in. Well, let’s just see how it goes but I for one am having to take a lot more time building a game worthy of MTX-enabled content

By the by, below is my current list of MTX-enabling services currently available. If you know of any others, please leave a comment

• GamerSafe – Seems to be the best choice so far. Adds achievements, microtransactions, save games, leaderboards, etc in a unified, web-wide accessible account.
• Nonoba – Like GamerSafe, but also has a multiplayer network… but you must have a nonoba account to keep multiplayer stats/items etc (but guests can still play, just not save). Anyone used their multiplayer API yet?
• MochiCoins – MTX only. Can’t use with other systems so I’m completely ignoring this one.
• HeyZap – Also MTX only.

It’s best to include as many options for your players as possible, so given this list, you would allow premium content to be purchased with GamerSafe, Nonoba and HeyZap.

New additions to C³

I’ve made a significant number of changes to the site itself. Besides the better layout (960gs ftw) I added this awesome Wordpress plugin that does an excellent job highlighting AS3 code (see previous posts with code)… except it’s fat and makes the site load slower, but whatever. I can fix that with another plugin (I <3 WP).

Also you can socialize my posts now, using Sociable; you’ll also see new blog posts updating my Twitter status (I mainly wrote this post to test that actually). I still have a bit to do for the site aesthetically though… but I kinda like tweaking themes, and now that IE is growing up (sort of) web design has been a little easier. I still can’t wait for Google’s bitch-slap to MS though. That’s so baller.

Each drink adds a certain amount of “drunkeness points” for every sip (you can tell how many sips you have by the icon on your nametag) to your avatar and over time your avatar will show signs of intoxication, such as bubbles above their heads and the propensity to fall down randomly. You avatar has a drink tolerance that’s determined by your MP level and how many drinks you’ve had in a session.

As of this writing there’s only 4 types of beers to choose from. In the future I’ll be adding a lot more, and not just beer but wines and spirits too. Good stuff.

If you have any other ideas for what drunk effects I should add, let me know. (Note that I can’t touch the avatar graphics so I can’t add new animations. I also can’t currently blur the screen because that would kill performance and it can get annoying.)

Module page. Search the marketplace for “bar system” or my username, “vonwolfehaus”.
Price: 1700 coins.
Configurable options: x and y position that the bar menu appears at when opened

I’m not sure why I made this module but I did. If user sit in a piece of furniture with this behavior attached to it, they’ll be giving a dunce cap with the word “FAIL” on it. They’ll also be scorned by a message from the world owner. If the user tries to leave the chair before their time is up (time is also configurable) they will be kicked from the world.

Module page.
Price: 30 coins.
Configurable variables: timeout length, timeout message (title too), x and y position of the hat.

I started by converting the thumbnail to a Vector array of Bitmaps. I planned on using TweenLite to shuffle each bitmapped pixel off the screen, and hoped I could do some fancy stuff with the Bitmaps like scale them for interesting effects. I did this by dumping the uint values of the bitmap into a ByteArray using getPixels(), then creating a new Bitmap for each value in the ByteArray using readUnsighnedInt() in a while loop. Each new Bitmap (representing a pixel of the original image) was added to that Vector array I mentioned:

var pixels:ByteArray = srcBMD.getPixels(srcBMD.rect);
pixels.position = 0; // make sure we start reading from the beginning
var newx:int = src.x;
var newy:int = src.y;
while (pixels.bytesAvailable) {
	var splodeParticle:Bitmap = new Bitmap(new BitmapData(1, 1, false, pixels.readUnsignedInt()), PixelSnapping.ALWAYS);
	splodeParticle.x = newx;
	splodeParticle.y = newy;
	++newx;
	if (newx > src.x + src.width) {
		++newy;
		newx = src.x;
	}
	container.addChild(splodeParticle);
	pixArray.push(splodeParticle);
}

I’d then loop through each item in the Vector to tween them off stage, revealing the loaded content below them.

Turns out this was a pretty dumb idea. The performance was extraordinarily sluggish during the while and for loops (naturally) and I wasn’t able to get a smooth tween because of this. Also, the ByteArray did not recreate the original image correctly — it came out rather distorted:

I’m still not sure why, as this is my first time dealing with the ByteArray class, but I figured I’d cut my losses and try a different approach.

Since I was getting great results with blitting in other experiments, I figured I should try holding a Vector array of Points that represented the pixels I wanted to move around. The actual “moving” simply ran setPixel() on a Bitmap for each Point in the array after I ran some translation calculations to get shit moving all nice-like. Points have a lot of extra baggage that I didn’t want though, so I just used a custom class that simply stored some dimensional variables and called it good.

I based my classes off of Andre Michelle’s Bitmap Particle experiment — he knows more math than I ever will and came up with a fucking brilliant effect there that I can only dream of achieving, so mad props to that bloke.

Anyway, as you can see this worked out pretty damn well. I could spend a whole week on this experiment, playing with the variables (especially the ignite var) to get different transitional effects, as well as adding more filters… but I’ll just leave this basic example for you to play with. Just be sure to show me anything particularly cool you come up with!

Usage:

// Optional format
var format:TextFormat = new TextFormat();
format.font = "Verdana";
format.size = 10;
var bmt:BitmapText = new BitmapText(300, 500, true, format, 12, 100); // only width and height are required
bmt.addText("This is html text, which can't be mixed with regular text.", true); // set last param to false for regular text
this.addChild(bmt.render());

More instructions/explanations are in the class itself.

The particle trails you see are actually all on one bitmap that I draw to after updating each particle in sequence, per frame tick. The particles themselves are a simple class that keeps track of a few variables such as velocity and position. The class doesn’t extend anything, instead the Main class of the swf draws a line from where the particle was in the previous frame to where it is in the current frame.

To make them fade over time I simply did a colorTransform on the whole bitmap at the begining of the tick method. I didn’t alter any hues obviously, I just subtracted the alpha value of the bitmap a little. So the longer the pixel has been in the bitmap, the lower it’s opacity. I wish I can claim that cleverness but I actually got the idea from somewhere else… probably 8bitRocket.

This method of graphics manipulation, called blitting, is the way to get a metric fuck-ton more performance out of Flash than is possible with mere Sprites. You can see there’s 600 “particles” in the demo — had I simply extended the Sprite class and used that to render the scene, I probably would have only been allowed a few hundred sprites while keeping the framerate at around 30.

If you want to see some great examples of blitting, check out 8bitRocket’s posts on the subject. You can even find a blitting engine called PixelBlitz — check out this badass schmup demo of his!

This time it’s because I’m an alpha tester for Metaplace, and I’ve been putting most of my free time into that. Check out the site, post in the forums (maybe you’ll get selected for the upcoming beta) — it’s an excellent project with a ton of potential.

But I’ve also been working on a new AS3 experiment that implements a blitting engine for sprite rendering. This allows me to display over 1000 sprites on-screen at once, as opposed to the 300-400 that’s possible with no special code. I’ll be implementing this in my upcoming Flash game. Maybe.

A quick google didn’t yield anything relevant, so I was left to my own devices. I remembered being able to draw pixels to a BitmapData object while writing my game in order to improve performance, so I figured I’d see if I could just copy the pixels from the text field and “bake” it into a bitmap.

Turns out you can. In fact, Adobe had already done this in the help files and it’s actually extremely easy. Check it out:

var tf:TextField = new TextField();
tf.text = "bitmap text";
var myBitmapData:BitmapData = new BitmapData(80, 20);
myBitmapData.draw(tf);
var bmp:Bitmap = new Bitmap(myBitmapData);
this.addChild(bmp);

No sweat right? Anyway, since I didn’t find any help on this anywhere else (granted, I didn’t look very hard), I thought I’d share this little adventure of mine. Hope it’s helpful.