Here is basic math, receiving a huge boost between debug and release modes. The shaded bar is the duration of the call, so shorter means faster execution.

From here down, everything is running 10m iterations. The scale of these graphs is 560ms. Here's the difference in calling a static public variable, versus a local copy of same.

Finally, replacing the Math helper methods with some logic and basic math:

These stack up pretty well with what I saw in the debug player a year ago (although there is an overall speed increase in all the tests).

If anyone is curious, there is a slowdown in calculating powers of a number (i * i * i * i) as you have to reference that variable over and over - for me the break-even between stringing on more 'i's and just calling Math.pow() was around 60.

I chose the XOR algorithm, primarily because AS3 is lightning-quick with bit operations, and the algorithm is only 4 lines of code. Here are two versions I tried:

//  UINT
 
const MAX_RATIO:Number = 1 / uint.MAX_VALUE;
var r:uint = Math.random() * uint.MAX_VALUE;
 
//  returns a number from 0 - 1
function XORandom():Number{
	r ^= (r << 21);
	r ^= (r >>> 35);
	r ^= (r << 4);
	return (r * MAX_RATIO);
}

//  INT
 
const MAX_RATIO:Number = 1 / int.MAX_VALUE;
const NEGA_MAX_RATIO:Number = -MAX_RATIO;
var r:int = Math.random() * int.MAX_VALUE;
 
//  returns a number from 0 - 1
//  comment out line 13 for -1 - 1
function XORandom():Number{
	r ^= (r << 21);
	r ^= (r >>> 35);
	r ^= (r << 4);
	if(r < 0) return r * MAX_RATIO;
	return r * NEGA_MAX_RATIO;
}

It's worth noting that this algorithm works from a seed number. For my purposes, picking one random seed and iterating is fine, but this function is predictable enough that you wouldn't want to use this method for crypto or anything where you'd want "very random" data sets. This also could be useful in some situations where you'd want to replay a set of random numbers - such as generating enemies or levels in a game and then creating a replay by saving the seed number.

For my benchmark, I ran 25 sets of 10 million iterations on each function, using the 10.0 release player in Safari.

Interestingly, the logic to gate negative numbers in the signed-int version was enough to push it out quite a bit past the uint version. All told, the uint algorithm runs in just under one fourth the time it takes to call Math.random().

As always, Wikipedia will tell you as much as you want to know about the ins and outs of this algorithm and how it stacks up against other generators. And, just for fun, here's a frequency graph of the output.

First off - Flash uses a fairly confusing rotational layout. A DisplayObject's rotation is measured in degrees from 0, which is at 3 O'Clock. Degrees extend clockwise to 9 O'Clock (180°) where an odd thing happens. Flash converts any number you pass in to the closest possible value to zero, so 181° gets recorded as -179°. This is still technically correct, but it can wreak havoc on your code if you're not expecting it.

Here's a quick method to get the positive angle back:

spinner.rotation = 181;
trace(spinner.rotation);		//  -179
var angle:Number = spinner.rotation;	//  -179
angle = (angle + 360) % 360		//  181

Alright - what people really want to know is how to calculate the angle between an object and the mouse, or another object. The solution is to take the arc-tangent of the offset in y, divided by the offset in x, which, if you remember your trig from highschool, would be the two perpendicular sides of your right triangle. Here's what the code looks like:

package {
 
	/*
	*	Flash 10.0 ? ActionScript 3.0
	*	www.calypso88.com
	*/
 
	//--------------------------------------
	// PACKAGES
	//--------------------------------------
 
		import flash.display.Sprite;
		import flash.display.DisplayObject;
		import flash.geom.Point;
		import flash.events.Event;
 
	public final class Arrow extends Sprite {
 
		//--------------------------------------
		//  CONSTRUCTOR
		//--------------------------------------
 
			public function Arrow(){
				super();
				addEventListener(Event.ENTER_FRAME, enterFrame);
			}
 
	  	//--------------------------------------
	  	//  EVENT HANDLERS
	  	//--------------------------------------
 
			private function enterFrame(e:Event):void{
				var p1:Point = new Point(this.x, this.y);
				var p2:Point = new Point(stage.mouseX, stage.mouseY);
				this.rotation = angleBetween(p2, p1);
			}
 
		//--------------------------------------
		//  PRIVATE & PROTECTED INSTANCE METHODS
		//--------------------------------------
 
			private function angleBetween(p1:Point, p2:Point):Number{
				var deltaX:Number = p1.x - p2.x;
				var deltaY:Number = p1.y - p2.y;
				var angle:Number = Math.atan2(deltaY, deltaX);		//  in radians
				return radiansToDegrees(angle);
			}
 
			private function radiansToDegrees(r:Number):Number{
				return(r * (180 / Math.PI));
			}
 
			private function degreesToRadians(d:Number):Number{
				return(d * (Math.PI / 180));
			}
	}
}

The last surprise is that the arc-tangent comes back in radians (π radians = 180° degrees) so you'll need to convert back to degrees before you set the rotation. Here is the final result applied to a few dozen arrows.

Links | OPML

A fairly drastic solution is to flatten your arrays - it will give you a nice performance boost when you access the data, but it comes at the cost of obfuscation. Here's how it works:

(Sorry the numbers are goofy between the diagram and the code - CS4 crashed and I didn't feel like re-making that graphic)

In the traditional 2D view each "row" is a new Array object - this is where the added computing cost comes in. By flattening the data into one super-long array, you can access any piece of data with just one lookup. Finding the correct cell is a little more tricky though.

var myMDArray:Array = [
	['0a', '0b', '0c', '0d', '0e'],
	['1a', '1b', '1c', '1d', '1e'],
	['2a', '2b', '2c', '2d', '2e']];
 
var myFlatArray:Array = ['0a', '0b', '0c', '0d', '0e', '1a', '1b', '1c', '1d', '1e', '2a', '2b', '2c', '2d', '2e'];
 
var columns:int = 5;
 
trace(myMDArray[2][4]);
trace(myFlatArray[14]);
trace(myFlatArray[(2 * columns) + 4]);
//  2e, 2e, 2e

Now - supposing you have an index for something and want to reverse engineer the row and column - just break out the modulo grid code:

var row:int = int(14 / columns);
var col:int = 14 % columns;
 
trace(row, col);
//  2, 4

Hey readers - I want to apologize to anyone who tried to get to my last post and got a bunch of spam for cheap foreign pharmaceuticals instead. That certainly wasn't my intention (when I sell out, it won't be for gasex pills) and I'm taking steps to guard against this sort of thing in the future. If you want specifics on the hack, the best thread I've seen so far is here.

Sincerely,
-Rob

const ROWS:int = 30;
const COLUMNS:int = 88;
 
for(var row:int = 0; row < ROWS; row++){
	for(var column:int = 0; column < COLUMNS; column++){
		var s:Shape = new Shape();
		s.x = column * 5;
		s.y = row * 5;
 
		s.graphics.beginFill(0x666666);
		s.graphics.drawRect(0, 0, 4, 4);
		addChild(s);
	}
}

This can be simplified and sped up by taking advantage of the relationship between division and modulus to generate the row and column dynamically:

const ROWS:int = 30;
const COLUMNS:int = 88;
const ITEMS:int = ROWS * COLUMNS;
 
for(var i:int = 0; i < ITEMS; i++){
	var s:Shape = new Shape();
	s.x = int(i / ROWS) * 5;		//  this is the same as Math.floor(i / ROWS), just faster
	s.y = (i % ROWS) * 5;
 
	s.graphics.beginFill(0x666666);
	s.graphics.drawRect(0, 0, 4, 4);
	addChild(s);
}

By upgrading to loop-invariants, we can cut the nested for-loop for a nice boost. And, as a bonus, this new code can work with sets that don't end squarely at the end of a column.

The obvious issue with Flash and 3D is performance. The maps we wanted to show we're rectilinear height-maps, 256 vertices to a side. I already knew there was no way to do this in a photo-realistic way (256² is just over 65,000 squares, which would be 130,050 triangles to render...last I checked, Papervision gets unusable around 2000) so I decided to go with a wireframe style instead.

Since I didn't need camera's or any of the weight of the bigger engines, I opted to use Mathieu Badimon's very lightweight and (imo) thoughtfully laid out FIVe3D library as my starting point. From there I got a quick proof of concept up and realized there was still no way I could get away with the full 256² grid so I started cutting down the resolution. Using every third node (64²) struck a good compromise with the fidelity of the original mesh, and the performance limitations I needed to stay in to work for the majority of our users.

Off the shelf, FIVe3D was giving me roughly 12fps and consuming a pretty weighty chunk of system memory, so I started digging in and looking for optimizations I could make. To start with, I created a specific class for my model to eliminate all the cross-class calls between Shape3D and Graphics3D. I also decided the Point3D class had to go since every render pass would create tens of thousands of throwaway objects in order to calculate the z-translations for my nodes. After internalizing those, I brought in the Matrix3D class as well and started combining some of the heavy-use functions so the AVM could stay within one scope for the majority of the calculation and drawing.

That gave me a boost of about 50% but I still needed a little more oomph. Finally, I took the dive and flattened my arrays and ended up restructuring the core FIVe3D engine so it was operating a little more specifically to my needs (mostly hard typing some things and taking out optional calls to the flat-fill shader and the like). At this point, the code is fairly incomprehensible and some of the extensibility of the engine was lost, but it did put my frame rate just under 30fps so I can't complain.

Here is a standalone copy showing the final mesh, and if you want to melt your processor, click for a version with the original full-detail grid.

For starters, trying to figure out a slider solution took me on a tour of s:Slider, s:HSlider, and finally (past mx:Slider) to mx:HSlider. I haven't kept up on the Flex news that well in the past months so I get the feeling there's some big paradigm shift that's catching me by surprise (something about shifting from the mx package to the new s package for the Spark theme?). I'm guessing that half of these classes will get culled out by launch time, so I guess that's what I get for learning on the beta.

One thing I'm excited about is how quickly you can prototype ideas in here. Getting a webcam up took all of 5 minutes, and throwing out three color pickers was instant. I did spend some time fussing with the width bindings between the slider and the palettes but in a real project I'd probably take the time to design and write a true component for that functionality so I can't complain too much.

UPDATE: This thing seems to be crashing some peoples browsers. I haven't looked into it too far but I think there are some circular references in the bindings that are getting into a loop or something (I knew that idea was too good to be true!). For now I've moved the offending swf to it's own page: enter if you dare.

So, for Flex Experiment 0.01, I recreated an old demo I wrote for a paint bucket/magic wand tool. The actual Flex components went together pretty easily - the big issue for me was deciphering which of the 1000+ components in the framework I needed to use. Once that was figured out, the real chore became negotiating the inputs and outputs of the components (s:BitmapImage takes an Object for source and doesn't output a BitmapData anywhere? Really?) - somehow it all seems to work, but the components really are black boxes that developers are not meant to get into.

Anywho - click and drag around to see it in action, and (I'll grudgingly give Flex a gold star here) right click for the source.

Drag the three points around to alter the path.

1. Designate a Document Class for your fla - let's call it ProjectMain
2. Create the ProjectMain class and save it alongside your fla as ProjectMain.as
3. Set a property of something on stage, let's say myCoolLogo.x = stage.stageWidth / 2;
4. Compile to receive your TypeError: Error #1009

Your code is otherwise fine - commenting out that line seems to fix everything. Furthermore the object is right there on stage in your fla – your constructor just refuses to acknowledge it!

The problem goes back to AS2 prehistory and the top-down/bottom-up problem. If you don't remember that (admittedly it's a little obscure even if you did work in AS2 a lot), here's the gist: Flash is single-threaded, meaning it can only do one discrete task at a time, which includes running your constructor, and parsing everything on stage. In AS2 you could specify whether you wanted to run your code "top down" - meaning, 'run all the code in the top layer, then the next below and so on' or vice versa for "bottom up."

At this point you should be wondering what this has to do with anything - well let's say you create a variable on layer 10 (top layer) and give it a value - and in layer 1 (bottom layer) you wan't to do something with that value - it's only going to work if you're running top-down. If you run that fla bottom-up you'll execute the layer 1 code first and the variable will be undefined until frame 2. The exact same thing is happening with your constructor in AS3.

The constructor will always precede any timeline code or bytecode (including positioning things on stage, tweens, &c.) - so you need to be careful with your initialization. It's alright to create new objects and work with them, but you can't query anything that you put down on stage (the same goes for library-linked Classes) until at least one render cycle has passed and allowed all those objects to be generated. Luckily, AS3 has an event for that so it takes some of the pain out.

Here's how:

//  ...
 
//--------------------------------------
//  CONSTRUCTOR
//--------------------------------------
 
public function ProjectMain(){
	super();
	addEventListener(Event.ADDED_TO_STAGE, function(e:Event):void{
		e.target.removeEventListener(e.type, arguments.callee);
		myCoolLogo.x = stage.stageWidth >> 1;
	});
}

If you're curious about line 39 in there, it's a generic way to remove event listeners - there's a little more detail over on the code page. Also as an added bonus, all the code has been moved into a second function - and since the ActionScript JIT compiler doesn't optimize constructors, there's a good chance that this code will run faster than before.

In AS3, the volume attribute ranges from from 0 to 1. Graphically it's a pretty obvious choice to just link your fader up on a one-to-one relation - the math is straightforward and you can quickly verify that, as you scale up the volume, it gets louder, and when you scale down you approach silence. Easy.

The problem comes in when you listen to that audio with your fleshy human-ears, which detect sound logarithmically instead of linearly. That means that the perceptual difference in lower volume is much more noticeable than in higher volumes.

Here's a linear slider:

var v:Number = fader.width / totalWidth;
SoundMixer.soundTransform = new SoundTransform(v);

Notice that all the real action happens in the first half of the slider - the first 20% is a huge pickup in sound while the last 20% is almost imperceptible. Because your ear is countering the amplification, it's up to you to counter-counteract the faulty hardware (e.g. your user's inferior hearing) and still deliver a good experience. To do that, you need to remap the amplification from a linear input-equals-output model, onto a curve that's roughly opposite to the users perception.

Here's that same slider remapped to a simple quadratic gain:

var v:Number = fader.width / totalWidth;
SoundMixer.soundTransform = new SoundTransform(Math.pow(v, 2);

This has a lot more punch to it - the loud end definitely has teeth now, and the quiet end gives you a much finer control. Since we're already working between zero and one, we can employe a simple x² formula without dealing with offsetting or scaling in the equation. To really fine-tune you could use any exponent you want - say 1½ for a half-and-half approach, or 3 to move all the weight to the right side of the slider.

To sum up, here's a rough graph that I generated drew in photoshop to illustrate the principle. And if you're wondering, the music is Ode to the Bridge Builder from Kyle Gabler's fantastic World of Goo Soundtrack – I'm using it here without permission because it's all I have on my laptop right now – please go buy the game so I get sued less (also because you're a Flash dev and it's an inspiring example of great gameplay)!

In the course of that news, I put up a dedicated blog for the group: effx.org, using a standalone WordPress install and the extremely slick OnePress framework that the smart guys over at PBL have been developing, without which this thing would never have gotten off the ground.

So if you have an interest in Flash, Flex, or AS and you live in the greater Eugene area, drop by the meeting and check it out.

private const COLD_STORAGE:Array = [];
 
public function freeze():void{
	while(numChilren){ COLD_STORAGE.unshift(removeChildAt(0)) }
	stage.quality = StageQuality.LOW;
	stage.frameRate = .01;
}

In hibernation, the swf has nothing to render (which takes care of enterFrames, mouseEvents, etc.) and the stage refreshes are pushed out to one every 100 seconds, so cpu use is essentially nil, while all the swf assets chill out in memory until I want them again.

public function thaw():void{
	while(COLD_STORAGE.length){ addChild(COLD_STORAGE.pop()) }
	stage.quality = StageQuality.BEST;
	stage.frameRate = 30;
}

While I was working on the code to reanimate, I got to thinking about the elastic racetrack and it occurred to me that throttling the framerate down to under a second may be problematic – luckily the ExternalInterface (which I so love to hate) already supplied the answer. Since external callbacks are synchronous, they interrupt the normal progression of the code, so it's possible to reset the framefrate without waiting for the next frame to fire.

ExternalInterface.addCallback('freeze', freeze);
ExternalInterface.addCallback('thaw', thaw);

Everyone who hits this problem comes up with a plan of attack that goes something like this:

for(i = 0; i < 5; i++){
	var mc:MovieClip = new MovieClip();
	mc.name = "mc" + i;
	addChild(mc);
}
 
mc3.play();

Which sounds pretty good on paper, but generally ends with this:

Error 1120: Access of undefined property mc3.

So what went wrong? This is easily one of the biggest stumbling blocks for new AS3 users, and Adobe goes to great lengths to ignore it and pretend the problem doesn't exist. Here's the secret: Instance names don't really exist!

Ok, more specifically, when you assign an instance name in Flash, there is secret code generated for you behind the scenes that creates two variables which work together to give you the perception of an instance name. To do the same thing in your own code you would use this:

public var mc3:MovieClip = new MovieClip();
mc3.name = "mc3";

A .name is not a thing

The first half of this solution is repairing a misconception; There is a general belief that setting the name property on an object gives it mystical powers. It doesn't. The name is just a string that is attached to objects for your convenience, it is not a unique identifier. Saying you want to play the clip named "mc3" is just as silly as saying you want to play the clip at .x = 50, or .alpha = 1 – these are all attributes of objects, not pointers to the objects themselves.

So with all of that said, now it's time to contradict myself. Adobe has tried to redeem themselves by making a little workaround function for this problem. It comes in the form of the getChildByName("mc3") method. It's not particularly efficient and you can have multiple things share one name so it's not great code practice, but it is a handy tool to be aware of in a pinch.

Create dynamic variables at runtime

Having completely debunked .name, we've now got the other half of this issue to deal with - how to create dynamic vars in AS3. Again the answer is, you can't. What you can do, is leverage a single Array to point at all your clips at once.

var clips:Array = [];
 
for(i = 0; i < 5; i++){
	var mc:MovieClip = new MovieClip();
	mc.name = "mc" + i;
	addChild(mc);
	clips[i] = mc;
}

That code will create 5 distinct MovieClips and stick them all into the clips Array under different indices. To get a specific clip back later, you just have to know the index:

clips[3].play();

And now - the thrilling conclusion!

So, The Easy Way is great for getting your project working and out the door - however it's the opposite of great for writing re-usable code and observing happy OOP best practices. If you're asking "why?," well here's the answer: you're breaking the chain of command. The child class should never (ever!) be issuing commands to the parent – the most it should do is alert the parent to any changes and let the parent be the judge of what to do.

For the sake of argument, let's say that your child class is a pre-loader and your parent class is the main movie. When that loader hits 100%, it's going to kick the main timeline in the ass and start the playhead immediately. Depending on your setup, that might be ok - but imagine we also have a fancy loading animation on screen - even though the load is done, we still want to play out the last 20 frames of animation before we run off to the next scene. The workaround is clearly not going to help us in that respect because the loader has no idea what's going on with the animation - and what's more, if you've got the loader calling the shots, you can't ever re-use it in another project without reworking a bunch of that code.

The Hard Way

We need passive alerting, and that means Events. So let's scratch the parent.someFunction line and dispatch a custom event instead:

import flash.display.Sprite;
import flash.events.Event;
 
public class ChildClass extends Sprite{
 
		//  ...
		//  MainClass(parent).someFunction();
 
		var e:Event = new Event('readyToGo');
		dispatchEvent(e);

Ok, that looks pretty good. Now whenever the child class needs to do something, it just shouts out that it's ready and anyone else can listen to it and act (or ignore) accordingly. What's more, we've eliminated a targetted call so now the child class will work inside any parent class (not just those with someFunction() defined).

Now, the parent has to listen to the child and take over the responsibility of acting when that event is fired.

import flash.display.Sprite;
import ChildClass;
 
public class MainClass extends Sprite{
 
		//  ...
		var c:ChildClass = new ChildClass();
		c.addEventListener('readyToGo', someFunction);

Perfect - now things are working as intended and there's no breach of OOP responsibilities!

⇠ AS2 to AS3: Calling a Method of a .parent Class (1 of 2)

I see some version of this question posted almost daily: "I'm new to AS3 and I have a parent class and a child class; how can I call a function in the parent class from inside the child?"

By this time you've already tried parent.someFunction() and gotten this

Error 1061: Call to a possibly undefined method someFunction through a reference with static type flash.display:DisplayObjectContainer.

The problem is that the child class is essentially deaf and blind - it has no way of knowing what kind of object the parent is (it could be a Sprite, MC, stage, custom class, whatever) so Flash has to be safe and restrict you to the common denominator, DisplayObjectContainer, from which all those other classes derive. Because of that, the .parent property will only allow you to call DisplayObjectContainer methods on it such as removeChild, getChildByName, mouseEnabled, &c.

So right here there is a fork in the road – you can make a couple of assumptions and get a quick and easy answer and be done, or you can do a little reworking of your code and get to the bottom of the problem once and for all.

The Easy Way

Since most custom classes extend MovieClip, we can tell the compiler to go ahead and open up that functionality to us by treating .parent as a MovieClip instead of just a DisplayObjectContainer:

MovieClip(parent).someFunction();

That line tells Flash that the parent is a MovieClip (or some offshoot) and therefore is a dymamic class – meaning you can add properties and public functions to it on the fly – so you can call anything you want on it and the compiler will search for it instead of falling back to what is explicitly stated in the class at compile-time.

If that's a no-go for you (say your parent is a Sprite, for example), you can still use this trick but you'll need to target the functionality of the main class a little more specifically.

import flash.display.Sprite;
import MainClass;
 
public class ChildClass extends Sprite{
 
		//  ...
		MainClass(parent).someFunction();

The Hard Way

Ok - judge me if you want but I've already spent way too much time on the first half of this post and I'm not even to the good stuff yet. I'm going to hammer out the second half of this and post it a little bit later so that this whole concept is more digestible. Continuation is imminent!

continued: AS2 to AS3: Calling a Method of a .parent Class (2 of 2) ⇢

Now the good news; My new host runs entirely on wind power and my out of pocket expense is a quarter of what I used to pay. Huzzah!

In case you missed my earlier post, I've had a raging Flash-on for optimization lately, and today I'm jumping into the Math class. But first! A little warmup with operators.

I've often heard that addition is fastest, followed by subtraction and multiplication, with division being the slowest but I'd never seen any proof so I threw together my own test:

Way to go subtraction, almost 12% faster than addition! Ok, on to the good stuff. From here on down I'm running 1,000,000 iterations per test, the same test code I used previously, and compiling each test individually about five times (or until I'm satisfied with an average time).

Alright - the Math class. First and foremost this class holds some handy constants so my human meat-brain doesn't have to. The downside is that the AVM doesn't play well with static properties of other classes so there's a pretty significant slowdown. Instead, just retrieve the constant from Math once and store it in a locally scoped variable.

While a lot of the Math methods are invaluable (Math.atan2 == ♥), there are also a few that aren't as complex and slow your swf down unnecessarily. A big one that's easy to work around is the pow method – unless you're doing some heavy lifting with it, you'll see a good boost by keying out your formula by hand:

Or you can replace costly comparison calls with a little logic:

Going a step further, you can take advantage of int casting to shear off any significant digits to the right of the decimal.

By substituting int as a super fast round-down, it's an easy jump to true rounding:

UPDATE: A lot of other people have posted that you can recreate Math.ceil() by using int(i)+1, which never rang true to me – it only works on non-integers. I finally came around to a fix using modulus:
 
(i % 1) ? int(i) + 1 : i;
 
I don't have a fancy graph for this one but I benched it around 75% faster than Math.ceil.

My last trick is a monstrous, ugly, hack that I'm hiding over on the code page, it's an approximation for computing sine (which means you can also use it for co-sine by adding π/2 radians). Interestingly, this method of calculating the sine of an angle is actually less efficient and less accurate than the built in method, but the lag from calling the static method pushes Math.sin over the top.

Next: I'm hoping to give arrays a little loving in the not too distant future...if I ever get some free time that is. In the meantime – steer clear of unshift!

Further reading:
Joa Ebert on optimization
Speed tests over on OS Flash
Bitwise gems at Polygonal

When I started getting into it, I was somewhat surprised by how many ways there are to write a basic for loop. Combined with the different number types, that grows into a huge amount of variation in the way people can write code, so it follows that some methods must be better than others. I broke it down into four different structures:

1. Undefined variable, count up to ten.
2. Variable set to 10, negative increment to zero.
3. Variable set to 0, increment to ten.
4. Variable set to 10, decrement to zero.

These results are a little odd…let's look at what's going on. First of all, the obvious one: int is fast, uint is slow, and untyped is downright painful. So int it is, now on to technique.

The first and third test appear to be the same code, but there's a pretty large discrepancy between them at runtime. In fact the first test always wins by a visible margin. The difference between the first technique and the other three, is that the first test doesn't need an extra trip to memory to manually assign value to the newly instanced variable.

You may also be wondering about the negative increment in the second test – this is actually two tricks in one (and for a long time, I believed this to be the fastest execution). Even using a negative value, the addition operator takes about ¾ the time of the decrement (j--) operator. On top of that, looping backwards from a high value to zero, means you don't need to run a comparison, you can just cast the variable directly to a boolean.

All the rest of the code should be pretty pedestrian. There is one little snag in the untyped results but I suspect that's coming from weirdness in the JIT when it has to continually recast those values, and it's worth noting that uint really doesn't like the increment/decrement operators. And lastly, if you're wondering, I didn't test while loops here because both while and for loops are compiled into the same code – as far as the player is concerned, there is no difference, so use whichever you prefer.

UPDATE: Ok this is borked. In the middle of the night it came to me (in a vision?) – since the variable is never defined in the first test, maybe the JIT is just jumping the rails and never going through that loop at all? That would certainly explain the speed increase (better than my feeble explanation earlier).
 
So testing should have been an easy iterator variable - testing a loop that counts to 10, over 1 million iterations should trace out 10 million. Somehow the undefined loop code is so extremely broken that it's actually leaking out into the scope above! When I tested I got back 10...implying that the test code actually broke my benchmark harness. I'm still trying to get to the bottom of this but in the meantime, just go with method #2.

SWF: [AS3] [Zip] [doc]

When I posted the Pic class earlier, I knew immediately that I should code a companion class to handle the specific loading of swf files. With static images, you usually don't need a handle on the actual bitmap, but when you get into loading external Flash content, you generally want to interact with it.

To that end, I'm working on a class that will pass all the normal MovieClip properties back and forth between the parent and the loaded swf as though the wrapper were the swf itself, but that's going to take a while to really put together and test.

NOTE: I briefly considered a monkey-patch to just add a little loader directly onto the native MovieClip class but the idea of modifying all MC instances in the entire language just to add one niggling bit of functionality makes my blood boil. If Adobe wanted us to ignore the Loader class, they would have built things that way to start with (and named the whole mess AS2)!

In the meantime, here's the SWF class; A lightweight (~1500 bytes) loader that hides all the nitty-gritty stuff so you can just drop it in and go. Loading a swf and putting it on stage is as easy as this:

import com.calypso88.SWF;
 
var mySWF:SWF = new SWF('http://www.calypso88.com/test.swf');
addChild(mySWF);

Fine and dandy - but you'll want to get into the guts of the loaded content. To do that you need to wait for the loading to finish and then target the .mc property. Here's how:

import com.calypso88.SWF;
 
var mySWF:SWF = new SWF('http://calypso88.com/tester.swf', false);
addChild(mySWF);
 
//  trace out the loading %
mySWF.addEventListener(ProgressEvent.PROGRESS, onProg);
 
function onProg(e:ProgressEvent):void{
	trace(e.target.percent);
}
 
//  when loaded, customize the guts
mySWF.addEventListener(Event.COMPLETE, onLoaded);
 
function onLoaded(e:Event):void{
	trace('complete');
	mySWF.mc.spinner.stop();
	mySWF.mc.txt.text = 'Hello from the outside!';
	mySWF.mc.gotoAndStop(2);
}
 
//  start loading
mySWF.go();

To stay consistent with the Pic class, I included a clone function here too, but again, the way the loaders work, this requires some trickery so you can't just clone the swf and start manipulating, you'll have to wait for it to get initialized:

import com.calypso88.SWF;
 
var mySWF:SWF = new SWF('http://calypso88.com/tester.swf', false);
 
mySWF.addEventListener(SWF.LOADED, onLoaded);
 
function onLoaded(e:Event):void{
	addChild(mySWF);
	var myOtherSWF:MovieClip = mySWF.cloneMC(false);
	myOtherSWF.y = 10 + mySWF.height;
	addChild(myOtherSWF);
 
	myOtherSWF.addEventListener(SWF.CLONE_COMPLETE, function(e:Event):void{
		//  the clone uses the same .mc wrapper as the original
		myOtherSWF.mc.txt.text = 'This swf is a clone!';
		e.target.mc.spinner.stop();
	});
}
 
mySWF.go();

SECURITY WARNING: This class uses the URLLoader class instead of the more traditional Loader class. For most users this won't be a problem but if you are building an application that allows the loading of swfs from outside users, this class will open your swf to the possibility of cross-site script-injection. Use this at your own risk!

And just because this post isn't long enough, here are a few shots out of the Documentation Cannon!

Lightning, you cheeky bastard! Is that naturally occurring pathfinding or are you just happy to see me!?

As soon as I saw the beginning of that video I was reminded of my first maze test, and the unintended (yet quite interesting to watch) motion as the algorithm chewed through the possible paths. What's more, my latest maze experiment was built around the concept of tracing the path-of-least-resistance through a bitmap – precisely how the lightning is searching through the ionosphere for a positive electrical ground!

It took me about 5 minutes to overwrite the old maze with some render clouds and throw a little glow filter at the final path - and the result already looks pretty good. This is definitely a rough pass (there's a pixel-trap somewhere that's hanging the algorithm so I just jammed it all into a try/catch and ignored the timeout error), and there is a lot of weird clumping that I need to iron out, but the core concept is there.

Keep an eye out – I'll try and put up an animated (and less buggy) version sometime this weekend.

Pic: [AS3] [Zip] [doc]

Updated: Version 1.1.0

Here's a little throwaway class that I've been using for a while. For a skimpy 1200 1500 bytes, this little guy handles image loading and smoothing, and it will even spin off duplicate Bitmaps for thumbnails. w00t!

Simple implementation:

import com.calypso88.Pic;
 
var p:Pic = new Pic('http://make-some-noise.info/badges/88x31.gif');
addChild(p);

And some advanced features:

import com.calypso88.Pic;
 
var p:Pic = new Pic('http://make-some-noise.info/badges/88x31.gif', true, false);
addChild(p);
p.x = p.y = 40;
p.rotation = 10;
 
p.addEventListener(Pic.LOADED, function(e:Event):void{
	//  create thumbnail
	var thumb:Bitmap = p.cloneBitmap(false);
	thumb.scaleX = thumb.scaleY = .5;
	thumb.rotation = 10;
	addChild(thumb);
 
	//  change the original
	p.bitmapData.floodFill(10, 10, 0xFF6600);
	p.bitmap.smoothing = false;
});
 
p.go();

And of course – it's Free-Documentation-Friday!

UPDATE: I've posted a companion class for loading SWF content. It's not quite as seamless as I want yet, but it's still a lot faster and easier than writing out loaders all day. Check it out.

Old Man Internet seems to be endlessly moaning for an onChange event to monitor variables. When I learned the following technique I was shocked by how simple and clever it is, but somehow it’s still fairly obscure. The trick is calling your own accessors from within a class. Here’s how:

//--------------------------------------
//  PRIVATE VARIABLES
//--------------------------------------
 
	private var _speed:int = 10;
 
//--------------------------------------
//  GETTER/SETTERS
//--------------------------------------
 
	public function get speed():int{ return _speed; }
 
	public function set speed(i:int){
		_speed = i;
		speedometer.text = 'Speed: ' + i + 'mph';
	}
 
//--------------------------------------
//  PRIVATE & PROTECTED INSTANCE METHODS
//--------------------------------------
 
	private function accelerate():void{
		speed++;
	}

As far as the rest of your code is concerned, you’re just accessing a public variable; The setter is then translating that into a private variable and updating a textfield (just like the Var linkage in ol’ AS2).

WARNING: I’m not an expert here, but calling one’s own accessors (there’s an auto-erotica joke to be made here) seems like it goes against OOP principles. In the example, any outside class can wander up and change the speed without permission from the class itself – and that’s not necessarily good – so keep privacy in mind when you use this code. Also, if anyone has a good way to limit access to a setter (perhaps something akin to the singleton pattern would do the trick?), please give a shout.

So this is already some powerful mojo, but it’s linked up statically, so for now it’s kind of a one-trick pony. Let’s loosen it up and make this a bit more extensible.

// ...
	public function set speed(i:int){
		_speed = i;
		dispatchEvent(new Event('speedChanged'));
	}
 
//--------------------------------------
//  PRIVATE & PROTECTED INSTANCE METHODS
//--------------------------------------
 
	private function initialize():void{
		addEventListener('speedChanged', onSpeedChange);
		addEventListener(Event.ENTER_FRAME, accelerate);
	}
 
	private function accelerate(e:Event):void{
		speed++;
	}
 
	private function onSpeedChange(e:Event):void{
		speedometer.text = 'Speed: ' + i + 'mph';
	}

Now we’ve got a good onChange thing going here. Admittedly it’s still a far cry from just tagging a listener onto any old random variable, but with a little clever use of the event class you can achieve the same results.

BONUS CODE! Here’s the little workaround that inspired this post:

public function get scale():Number{ return scaleX; }
 
public function set scale(n:Number){
	scaleX = scaleY = n;
}

The point where 8-bit graphics break down is when it comes time to interpolate a gradient. If you want to draw a smooth fade from black to 10% grey, you want as many colors in-between as there are pixels. In an 8-bit environment, you’ve only got about 26 shades of grey to work with so anything bigger than 26 pixels across is going to have blocks of pixels, all colored the same – in the biz, this is called “banding.”

Interestingly, while Flash is bound to 8-bit it will still import a 16-bit Tiff. When I realized this I figured there must be some trickery going on - either I could use 16-bit color in Flash or else the Tiff was getting the chop. Unfortunately, it turns out Flash downsamples the image into it's own color profile, but the importer is good enough to give us the courtesy of a good dithering first (provided you enabled it in Photoshop). Here’s a little demo to show the dithering - if you squint you can see the banding on the originals.

Edit: Per Ben’s comment, I’ve tweaked the colors below to make the banding a little more noticeable (if you still see flat-black bars, try cranking up your monitor’s brightness/contrast). For all the headaches I’ve had from gradients in the past, making a bad one is really hard to reproduce on command!

I felt so guilty about posting that code yesterday that I was compelled to get this second version finished off tonight and optimized. And good news - I’m clocking it at 7 seconds! The big secret (ok, Bionic-Badger apparently already knew it in his comment a month ago) is to remove all the data constructs and just jam through the bitmap directly. So that’s what I did.

I had a brief notion that recursion was the way to go (I loves me some recursion!), the code was benchmarking extremely fast since there isn’t any storage, every child node just gets scoped into its own closure, however around fifteen thousand nested function calls is where Flash draws the line and throws in the towel (or stack overflow error, as the case may be). I’m still pretty sure I could get this algorithm down into the 2-3 second range if the recursion had worked...

Anyhow, my strategy was to color each explored pixel with an incremental number, so the first pixel becomes colored 1, the second 2, etc. Since we’re in hex color land, this gives the weird side effect of black to blue gradients that shift up into the green space as the color channels overflow. It’s bizarre to look at, but kind of cool to see where the breadth-first approach explores different areas. After that mapping has taken place, it’s a simple matter of tracing the path back from any given pixel by repeatedly finding its lowest-valued neighbor.

One final note; I’ve been noticing a strange discrepancy in the memory traces. About half the time I’m seeing 30-35mb and the rest of the time 2-3. I know this code is spinning off a lot of throw-away variables so I’m inclined to believe the higher numbers and speculate that the lower numbers are results of the Garbage Collector running at opportune times.

Maze pathfinder 2
source [748k]

Maze pathfinder [1mb]

I've gutted my pathfinder code and thrown it at a devilishly complex problem – specifically 4 megapixels of eye-squintingly difficult maze.

The big concern with this beast is managing resources; You can't simply jam the image into an array and go for broke, there has to be some sort of throttle to keep the code running in small, frame-sized chunks. The solution for that is to split my big loops up into loop-invariant code and run each iteration (or 20) on an EnterFrame event.

Next up is memory - my original engine was designed to run quickly so I could use it many times per frame without a noticeable slowdown. This means a lot of caching, specifically the entire map is put into memory as a 2-dimensional array, and then each node is given a link to it’s viable neighbors. This is obviously overkill for a simple pathfinder, but if you’re going to find a path on the same plane more than once, you’ve saved all the work from the first run into a crazy, multidimensional linked list (matrix? lattice?). If I were writing this from scratch I’d probably do away with the pre-caching step and do something tricky with byteArrays, but I’m not about to recode this whole thing just for a little stress-test. Consider this the official warning that this swf is a memory hog - running this swf may crash your browser/OS/hardware/whatever. Fair warning.

So the bottom line here is that this solution runs slowly…very slowly…like bring-a-tent slow. It’s thinking about 80 nodes (pixels) every frame (currently slated at 60fps but it’s dropping), and there are just under four million pixels to go through so it takes some time. My first test completed in just over 65 minutes (although about a third of that time was spent drawing the path back to the start once it had been identified). The version below has some optimizations that bring the scanning and pathfinding time down to about 25 minutes and another eight to draw the final path. A screenshot of the solution is included for the impatient.

Note: Testing this thing was a nightmare...obviously the real problems all happen after the loading and parsing passes so it takes forever. I tried socking that data into a SharedObject but it crashed safari thrice in a row so I gave up on that idea. Also, I wasted an hour getting confusing results out of my parser only to figure out that I had left jpeg encoding on and the source image was no longer true black and white.

pathfinder [344k]

original maze

solution

UPDATE: Per the comment below, I’ve pulled the limits off this baby and thrown caution (and smooth, steady framerates) to the wind. I benched this version at 51 seconds in XP. Not bad, considering it only required massaging a couple of variables.

fast version

UPDATE 2: This post has been getting a lot of direct traffic lately so I'm updating my progress here. Basically I recoded the solver to map out the solution in under 10 seconds. You can hit the pathfinding category below for the full saga or jump directly to the fastest attempt:

super-fast version

Step 2. Validate and Dispatch.
As much as I hate to admit it, JS tends to run quite a bit faster than AS3; So when the two are communicating, the real lag happens on the Flash side. It’s not such a problem if you just need to twiddle a boolean flag or set a variable, but generally when JS fires off some data, thats your cue to run a pile of code on it.

Let's take a look at that last sentance:

…when JS fires…data…your cue…pile of code

Sounds a lot like the event model, no? Well Adobe™ didn't think so, and the ExternalInterface’s sphincter-tight coupling and lack of validation are a slap in the face to anyone who disagrees.

Before we get ahead of ourselves, it’s worth bringing up my second gripe: Data validation.

Anyone who’s written AS3 for more than five minutes has seen a swf lock up as the result of a function receiving too much, too little, or unexpected data. Luckily the compiler catches these bugs and won’t allow you to publish until they’re resolved. When that safety-net is removed, most methods dealing with external data will wrap the incoming content inside a wildcard object like LoaderInfo or URLLoader. However, the ExternalInterface breaks from the rest of the API again and removes that last line of defense. By adding an EI callback, you expose that function to anything JS can send without filter.

Rest and relay.
Since there’s nothing to safeguard our inbound data, we need a small demilitarized zone where we can figure out what parameters we’re dealing with and cast them to a data type that Flash won’t choke on. It’s an ideal job for the rest statement:

ExternalInterface.addCallback('pieceOfAS', incomingJS)
 
private function incomingJS(...args):Boolean{
 
	//  lets say the real function requires an int and a string
	if(args.length < 2 || args.length > 2){ return false; }
 
	try{
		//  cast and validate the integer
		var i:int = int(args[0]);
		if(i != args[0]){
			trace('float received, expecting int');
			return false;
		}
 
		//  cast the string
		var s:String = String(args[1]);
	} catch (e:Error) {
		trace(e);
		return false;
	}
 
	trace('no errors encountered');
	return true;
 
}

This is mainly a big system of rejecting any data that isn’t perfect. We start by counting the arguments passed (if there aren’t 2, we eject), then we hard-cast the values to the types we’re expecting to get and if all goes well, only then do we alert JS that we got the message and we’re going to start work on it. Unfortunately, this method of validation is pretty specific to whatever function you’re calling, but it’s still a lot better than getting an incorrect value and having your swf flip out without letting you know.

So we’ve got the right data and we’re ready to process it. The last hurdle is solved with a custom event to wrap that data and throw it outside of the currently-running function to be processed at the start of the next frame. Let’s throw that line in the bottom of the previous code:

//  ...
trace('no errors encountered');
dispatchEvent(new JSEvent('pieceOfAS', i, s));
return true;
//  ...

And of course outside the incomingJS function we’ll need to attach a listener for that event.

addEventListener('pieceOfAS', processJS);
 
private function processJS(e:JSEvent):void{
	//  ...
}

Done! To recap, JavaScript target’s our swf and calls pieceOfAS(123, "werd"), that translates directly into a call on incomingJS(), which makes sure we’ve gotten exactly two variables, one integer and one string. The incomingJS function then puts those two arguments into an event (here's a tutorial if you’ve never made custom events) and dispatches it, and then returns ‘true’ to JS – we now have both AS and JS running in tandem again. Lastly our eventListener catches the custom event and routes it into the processJS() function, who can now run all the heavy code it wants without bogging anything else down.

⇠ Unfucking the ExternalInterface (1 of 2)

I just deleted four paragraphs of this post, since they could be summed up as “I hate ExternalInterface because it's slow,” which isn’t even an accurate grievance. ExternalInterface is pretty quick. It's the function’s being called by it that are slow.

My real frustration is that communication between Flash and JS is synchronous. That is, whenever Flash calls out to run a javascript function, all action inside Flash halts until the JS function is completed. This makes sense if you’re using getters and setters, but try anything bigger than that and you’ll start to see problems. At the very shallowest level, you’ll see your animation stutter every time you call out to a JS function that takes more than a couple milliseconds, at deeper levels you’ll enjoy long unexplained freezes and dropped calls.

Before the good stuff, a couple caveats: I’m not a JavaScript guy. I rely on two devs who work wonders with JS – whereas I curl up and stop functioning, the second I lose strict data-typing and custom classes. A lot of the credit for this method goes to them.

Second, the point of this workaround is to decouple AS and JS and let them run at the same time. Doing this sacrifices the return value you get if you wait for a function to complete before jumping back to the other side of the EI.

Step 1. Fix the outbound calls.
The good news first: JS is multithreaded. So if we can get our JS function to run in a different thread than the one targeted by Flash, we can get back to running ActionScript while JS worries about the real work. The secret (thanks to my JS guys!) is JavaScript's setTimeout() function. Here's how it works:

Normally to call a JS function you'd write something like this:

const JS_FUNCTION:String = 'myJSFunction';
const ARG:String = 'foo';
 
//  myJSFunction('foo');
ExternalInterface.call(JS_FUNCTION, ARG);

All we need to do is manually construct our JS function signature, and use that as setTimeout’s target:

const JS_FUNCTION:String = 'myJSFunction';
const ARG:String = 'foo';
const JS_CALL:String = JS_FUNCTION + '("' + ARG + '")';
 
//  setTimeout(myJSFunction('foo'), 0);
ExternalInterface.call('setTimeout', JSCALL, 0);

What does this accomplish? In the first example Flash stops running until foo runs its course. In the second example, Flash is waiting on setTimeout to complete instead. JavaScript will automatically call foo in another thread and return control to Flash, which allows AS to start running again while the foo function can run slowly on the JS side without gumming things up. To see this in action try calling a large empty loop or an alert in JS while you've got some animation going inside Flash.

Next post: Inbound calls, custom events, and data validation, oh my!

continued: Unfucking the ExternalInterface (2 of 2) ⇢

Click around to create barriers, and drag the start and end markers around the grid. Next step: diagonals!
]]> http://www.calypso88.com/?feed=rss2&p=24 0 http://www.calypso88.com/?p=23 http://www.calypso88.com/?p=23#comments Fri, 22 Feb 2008 14:59:38 +0000 Rob http://www.calypso88.com/?p=23 I’ve piddled away the better part of a year without touching this project. A few days ago I got motivated to rebuild my code and start implementing A*. The shot below is both an amusing oversight in my code as well as a visual metaphor of exactly how this project is progressing.

The two endpoints are draggable and have code to ‘snap’ them onto whatever tile they stop on. Currently the path is a direct line from A to B and untraversable tiles are ignored. Here's the code: iso_grid_01.zip.

First off, a test using hitTestObject. Every tile who’s bounding box intersects my little draggable circle will highlight. This is the same issue I had before with AS2 hitTest.

Now, a somewhat better version which uses the center point of the circle. This one gives much better results but still not quite perfect.

Failing the hit test.
The angles have been bugging me for a little while but my real brick wall right now is the hitTest method. My hope was to let characters roam around of their own accord and just worry about whether anyone was on a tile in any given situation. All of these assumptions hinged on the use of the hitTest method. I’ve put a dot on the stage that I'm using to test and it should be giving me a ‘hit’ only for the square it’s over. What I’m actually getting is a positive hit on the tile the dot is overlapping as well as any tile that shares a border with that one. In the screenshot below, all the white tiles are reporting hits...

IsoGrid
Take grid dimensions (width, height)
Generate IsoBlocks
Place blocks

IsoBlock
Take block dimensions (width, height, depth(?))
Draw fill
Draw stroke
Know it’s own position (x,y)
Set mouseOver effects

Stumbling blocks already…

To prevent later aggrevation, I’ll say that the northwest face on each block is the ‘top’, and the northeast face will be ‘right.’ With that in mind, I can say that an IsoGrid(50, 100) would generate 50 blocks to the northeast, and 100 blocks to the southeast of the initial block.

Additionally, since it’s a little odd to have each block’s origin at the top-left of the movieClip, I’ll modify my drawing method so I can keep the origin at the center of each block.