nodename » ActionScript

What I Did On My Summer Vacation

alan — Sat, 30 Jul 2011 07:46:06 +0000

I attended the Dynamic Abstraction Workshop taught by Joshua Davis at the Anderson Ranch Arts Center in Snowmass, Colorado, along with several flashy flexy friends. Click on the image to see my student project.

I don’t even want to tell you what Josh has planned for next year’s workshop until after I get my ticket!

Generating Generics: Creating Classes at Run Time in Flash

alan — Wed, 27 Apr 2011 04:24:16 +0000

Class Creation Test

This is a simple demonstration of class generation in Actionscript using the as3-commons-bytecode library.

Here I demonstrate creating parameterized classes (generics). In this example we create a Tuple class given a spec containing the names, types, and visibilities (public, protected, or private) of the class’s data members. The class is named appropriately, e.g. Tuple, and it is given a constructor method that requires parameters of the indicated types in the order that they will have in the tuple. I use the as3-commons-bytecode library to generate the class, and then load the class into the current ApplicationDomain. Once a couple of specified classes are loaded, I examine them with describeType() and construct an instance of each generated class.

The bytecode for the constructor doesn’t depend in any way on the types of the parameters; it’s just a matter of putting them on the stack and initializing the respective properties with them.

One thing that held me up for a while was determining the proper namespace for protected and local properties. It turns out to be the fully qualified classname with a single colon as the final separator; who knew.

I haven’t provided accessors for the tuple properties, so for non-public members that would be an ‘exercise for the reader’.

I’m loading the generated classes immediately, but there’s code to write them out in swf format as well. So an AIR app like this could be included in a build process…

I was led to play with as3-commons-bytecode by the exciting work that Mike Labriola and James Ward presented at 360Flex in Denver. They demonstrate a bytecode-based framework for intercepting the load process of a Flex application and performing arbitrary changes before allowing Flex to start up. The possibilities are vast:

Introducing Mixing Loom – Runtime ActionScript Bytecode Modification

Generating Generics? Somewhere, somebody must already be Making Mocks!

Playing 52-Card Pickup To Win

alan — Mon, 18 Apr 2011 00:13:35 +0000

So you come on board without having had a look at the code base. First off you find that the developer build process consists of a page of instructions that require you to do about fifteen more steps than “svn checkout; import Flash Builder project; profit.” Then, looking at those steps, you see no mention of “linking” “libraries” into the application, but rather of adding a couple of source paths that contain about a thousand Actionscript files.

Your mission, should you choose to accept it, is to sort out the dependencies and break this Close Encounters heap into a tree of libraries. Of course this won’t be easy; when the code base has grown for a year — or FIVE — without that kind of discipline, you’re bound to have to hack through some pretty thick vines sooner or later. But there are one or two tools you can use to ease the pain a bit and let you explore the tree, even while you’re just beginning the inevitable refactoring, and without moving a single source file. This way the development team can continue exactly as before while you fiddle around under their skirts.

The first goal is to separate all those “other” source files into one or more projects. So let’s try to make a single library swc out of all those source files.

You’re going to need enough heap space to build this uber swc, so follow Hasan Otuome’s instructions for that. Don’t be stingy here: I gave myself 4096M. You’re not going to accomplish this on a MacBook Air.

You’re not going to want the IDE trying to build everything every time you save a little code change, so from here out keep “Project -> Build automatically” turned off.

Make a Flex Library Project to hold this swc. You do NOT have to make this project reside at the root of the source path. You can put it anywhere you like, out of the way of the other developers. Just ignore the “Main source folder” for your library project, and add the (ideally just one) path to the source as an “Additional source folder.”

If the IDE stops responding for a while, be patient. If you run out of Java heap space while trying to build the swc, clean all projects and try again. If that doesn’t work, give yourself even more heap space.

It may be that your entire tree is just too big to build a single swc from. Barring a RAM upgrade or something, you’re back to square one. You’ll have to get started right away figuring out where your first Voronoi shatter will take place. You’ll want to use smarter tools like “Find References” to get a feel for the structure of the code. Ask around – the other devs may have a pretty clear idea of what should depend on what, even if it’s not yet strictly true. An obvious choice is sectioning off any third-party code that’s in the tree. But first check to see whether the developers have modified it so that it depends on in-house code. I have seen this happen.

Once you’ve got a swc, you can of course link that into your application instead of having all that code as “Additional source folders.”

Repeat.

Eventually you’ll have to edit some source files. If you’re still on the project :-)

NEW RULES

Describe the source layout of your project in terms of folder structure and library dependencies.
What third-party libraries do you use? Have you modified them? How and why?
Does your app use a framework? What parts of your app are allowed to communicate with the server and why?
Describe the process for prioritizing tasks. What are the criteria for setting deadlines?
If your project involves FLA animations, how are they integrated into the build? Do they contain code?
Describe your commitment to developing reusable software components. Define “discovery phase.”
Do you have any unit tests? Automated build?
Who’s in charge here?

The Arrogant Enum

alan — Thu, 14 Oct 2010 02:49:21 +0000

This enum thinks it’s the last word in ActionScript enumerated-type implementations. In fact it thinks it’s so hot that it calls itself the Ultimate Enum. Check it out and see if it doesn’t do the trick for you. If it doesn’t, please let me know and I hope we can improve it further.

Example enum classes using this implementation are here.

Blobs in Games: Polygon Map Generation, by Amit Patel

alan — Sat, 02 Oct 2010 23:20:07 +0000

Amit Patel has published a great article on map generation based upon Voronoi polygons. He generates the Voronoi polygons using my as3delaunay library. But the polygons are just the beginning of his process…

Try the demo! And — yum — see the source code!

Trees Grow

alan — Mon, 14 Dec 2009 13:54:48 +0000

Constrained minimum spanning trees as shape fills, the moving version of my earlier post The Name of the Node. On each frame one point is added, all the points move, and their spanning trees are drawn. Character: JIE2, “knot”.

(Be sure to view the movie in 480p.)

Note that since the segments are filled with trees, which may branch but never loop, the KOU3 (“mouth”) in the lower right quadrant is never a closed box. In every frame there is an escape path from the inside to the outside.

Roll Over, Delaunay: Voronoi Library Goes Open-Source

alan — Thu, 03 Dec 2009 04:28:55 +0000

A few people have asked for the code for my Voronoi Toy. I haven’t made the entire program public yet, but I have released the underlying as3delaunay library, which I originally ported from Steven Fortune’s C implementation of his plane-sweep algorithm.

In addition to the Voronoi diagram and the Delaunay triangulation, the library also provides the convex hull, minimum and maximum spanning trees, and several other related geometric entities.

You can download the source and compile it, or just get the compiled swc from the downloads page.

So far I have had two users, JakeTastic (Voronoi shattering complete!) and Li (Faster Voronoi Noise); thanks to them both for jumping on, and to Jake also for finding the two bugs :-)

There’s no documentation yet, but there is a test suite which incorporates an example of using the library for nearest-site queries, and there’s also a mailing list, where I’ve archived Fortune’s paper and his C code, as well as a growing page of interesting links related to Voronoi/Delaunay.

The library is hosted on github, so YOU can conveniently modify, fix, or enhance it!

Roadmap for possible enhancements:
Generalize to support weighted Voronoi diagrams, both additive and multiplicative (This is described in Fortune’s paper)
Generalize to use an arbitrary polygon as a boundary
… what else?

Implementing Enumerated Types in ActionScript 3

alan — Sun, 06 Sep 2009 03:39:33 +0000

UPDATE I’ve improved on this implementation; please see the later post The Arrogant Enum.

This is about implementing an enum in AS3 with value restriction ( i.e. the programmer should be unable to diminish or add to the set of values) and type safety.

We’ll implement the data type as a Class. In order to keep the programmer from adding to the set of values, we need to disallow invocation of the constructor.

Back when AS3 came out, there was much talk about the lack of private constructors and what to do about it, especially with regard to implementing the Singleton pattern. My favorite of the solutions is to define a file-level class and require it (the class, not an instance!) as a constructor parameter.

From there we can proceed just as Daniel Savarese describes in Implementing Enumerated Types in Java.

I don’t show how to implement an ordering on the enum values. See the Savarese article for that, too.

package
{
	import flash.errors.IllegalOperationError;

	public final class PailContents
	{
		public static const WATER:PailContents = new PailContents(PrivateConstructorEnforcer, "water");
		public static const CHICKENFEED:PailContents = new PailContents(PrivateConstructorEnforcer, "chicken feed");
		public static const MILK:PailContents = new PailContents(PrivateConstructorEnforcer, "milk");
		public static const OATS:PailContents = new PailContents(PrivateConstructorEnforcer, "oats");

		private var _name:String;

		public function PailContents(lock:Class, name:String)
		{
			super();
			if (lock != PrivateConstructorEnforcer)
			{
				throw new IllegalOperationError("Invalid constructor access");
			}
			_name = name;
		}

		// don't forget to implement toString() to support implicit conversion to String for trace() etc:
		public function toString():String
		{
			return _name;
		}

	}
}

// defined outside the package, and therefore visible only within this source file:
class PrivateConstructorEnforcer {}

Crystals, Evil Rangers, and Voronoi without an Engine

alan — Wed, 01 Jul 2009 20:41:03 +0000

In Flash we can HARNESS THE POWER OF BITMAPDATA (as it might be put in a conference session blurb) to grow Voronoi regions under differing conditions, without doing any algebra. Click on the image to launch the Voronoi Generator.

Variations on Voronoi Diagrams, from Geometry in Action:

One way of getting Voronoi diagrams is by growing crystals. If you start a number of crystals, all growing at the same rate, and all starting at the same time, you get a number of growing circles. As these circles meet, straight line boundaries appear between them. Eventually, the entire plane will be filled up. Each crystal will exactly fill up the Voronoi region of its point of origin.

This is a little too simple. In reality, crystals start growing at different times. Even if they still grow at the same rate, if they start at different times, they will no longer meet in straight lines. Instead, they will meet in hyperbolic segments. The diagram you get is called the “additively weighted Voronoi diagram”. It’s defined just like the usual Voronoi diagram, but each site has a weight, and you measure distance to a site, you add its weight to the usual Euclidean distance.

Now suppose instead that all the crystals start at the same time, but grow at different rates. Now you get what’s called the “multiplicatively weighted Voronoi diagram”. Once again, each site is given a weight, but when you measure the distance to a site, you multiply by its weight. Now the boundaries between different regions are segments of circles.

This model still has some problems. For example, in a multiplicatively weighted Voronoi diagram, it’s possible for a region to be disconnected [ see picture above -- AS ]. Obviously, this can’t happen with real crystals. So there’s yat another version which treats existing crystals as obstacles, and lets fast-growing crystals grow around the slower ones. Now the boundaries between neighboring regions are sort of tear-shaped. This variation is called the “multiplicatively weighted crystal growth Voronoi diagram.”

There are several other variations. You can change the metric from the normal Euclidean distance to L₁, or L_p, or L_infinity, or even stranger distance functions. You can weight the sites additively and mulitplicatively. You can change the sites from points to line segments or circles or polygons. You can generalize to higher dimensions. You can associate points with the farthest site, instead of their nearest site. And so on.

Different applications of Voronoi diagrams require different variations. For example, motion planning algorithms for circular robots often use the Voronoi diagram of the obstacles. If there is a path from one location to another, then there must be a path that follows the edges of the Voronoi diagram, since those edges are by definition as far from the obstacles as possible.

The “L₁ metric” is called the Manhattan metric or city-block distance. “Manhattan metric” is a misnomer, though, because in Manhattan the east-west blocks are much longer than the north-south blocks.

The crystal-growth model is equivalent to the “evil forest ranger model,” in which instead of watching for forest fires, the rangers set fire to their lookouts, sometimes at different times, and the fires may spread at different rates. Voronoi diagrams indeed find application in crystallography and in forest-fire modelling.

And here is a post about a far-from-evil lookout.

Marching Squares: Boundary detection

alan — Thu, 18 Jun 2009 23:30:59 +0000

A little code for a change.

Sakri was working on this, and I ported a class from Java which I believe he adapted into his final implementation. It’s a basic tool for morphing, 3D surface reconstruction, and vectorization.

I’ve cleaned up my version of it and I offer it here. The important function signature looks like this:

public static function perimeter(data:BitmapData, x:int, y:int):Vector.

It returns a list of pixels representing the boundary between opaque and transparent pixels, starting from a single boundary point that you provide.

You can get a boundary point using Sakri’s and Mario’s EdgeFinder class.

Download the source.

How it works: Marching Squares on Wikipedia