Needless, they were excited about the possibilities.

Pretty nifty?

Thanks, Toothpaste for Dinner.

Firstly, embedding binary data

How to embed? Check this article on embedding binary data at dispatchevent.org. For those in a hurry, this is what I took away from it:

[Embed(source="relative_or_absolute_path_to_my_data_file.dat",
       mimeType="application/octet-stream")]
private static var __PuzzleData:Class; // This class object constructs a ByteArray subclass
protected static var data:ByteArray = new __PuzzleData(); // statically constructs an instance
...

// Example usage of the embedded byte array
public function getPuzzle(puzzleNumber:int):void {
  // set the data ByteArray to the start of the puzzle
  data.position = puzzleNumber * PUZZLE_BYTE_SIZE;
  // let the puzzle stream its data from the byte array using read*() calls
  var puzzle:Puzzle = new Puzzle(data);
  return puzzle;
}

Endianness in Flash

There’s one more thing you might need to take special notice of if you’re reading multi-byte numbers, which most numbers are. That is to note which Endian the data is formatted in.

The Endianness of a number is simply the order that its bytes are recorded in the file (or transmitted over the network). As far as I understand it, most compiled programs running on x86 hardware that write numbers to a file do so in “Little Endian” format, which means they write the least significant bytes first. Flash’s default Endianness is “Big Endian”, which expects the most significant bytes first, because that’s the standard endianness for network transmission.

So if your data file seems corrupted when you read it in Flash/Flex, this is very possibly the reason. Setting the Endianness is done on a per-ByteArray level:

myFancyByteArray.endian = Endian.LITTLE_ENDIAN; // set the reads/writes to use little endian

HaXe is awesome. It can compile to heaps of different targets (including flash obviously), and can be translated automatically to many programming languages, including PHP, ActionScript, C++, Neko, …

It brings a whole lot of awesome features to swf that aren’t even available yet in Actionscript 3, including inline functions, and direct virtual memory access (only currently available otherwise when using Alchemy).

Plus the syntax is very much like Actionscript 3, but more consistent. A+

Amazing.

For a coding noob, C’s requirement for manual memory management is perhaps the most time- and brain-consuming ‘feature’. Writing anything but the most basic of programs (i.e. using only “stack” memory) required consistent focus on the task of correctly allocating, managing, and deallocating memory. Accidentally accessing data from a part of memory that you hadn’t allocated resulted in that familiar spartan sting: Segmentation fault. No fancy stack trace, elaboration, or even an apology. The machine just smugly states how  you fucked up and dumps you back to the shell. I remember an amusing graffiti on the computer lab’s whiteboard: “it’s all seg’s fault!”

Since I’d just come from a Java background the previous year, I found this “memory stuff” initially very frustrating and intimidating. Though I didn’t write off C as “just a stupid or difficult language” because I firmly believed that this overhead must be a tradeoff for some other benefits which I had yet to discover or fully appreciate.

Although I learned later that there was a debugger (gdb) that took away a lot of the pain of seg faults, it didn’t make the task of managing memory any easier: it was just helpful when things went wrong. The debugger doesn’t help, for example, with memory leaks. If you repeatedly allocated memory but forgot to deallocate it, even a small, simple program could eventually end up hogging a very large amount of memory.

As time went on, I got comfortable with managing memory, but I never forgot about my assumption that there were something(s) so amazing about the language that balanced up the overhead for manual memory management.

And to be fair, C is an inately quick language, which is fairly obvious from the start. This is mostly because it’s pretty much the CPU’s roommate: CPUs and the C language have evolved together over the last few decades, and they’ve formed a pretty formidable partnership. But also, some features of C (e.g. memory pointers) open up algorithmic possibilities that don’t really have a comparable equivalent in other managed languages, like Java.

Memory Management as a Focus Burglar

Having said this though, I remember the day that I decided “this isn’t worth it”. I had grown to really enjoy aspects of memory management and the associated benefits, but for me, it just wasn’t worth the significant overhead of time and focus. The tasks of manual memory steal focus from the programmer, and make it more difficult to concentrate on the actual problem at hand.

So since then, I’ve hardly touched any unmanaged languages. I’ve had many arguments about whether or not this is a bad thing, but in the end I’m pretty happy with it. So there.

I’ve relatively recently taken an interest in Flash, mostly because of its relatively new, strongly-typed, compiled, managed language: ActionScript 3. It’s a super groovy language, with a decent community and lots of sweet libraries (some of which have been ironically ported from C and C++). Although its previous version was a lot like JavaScript, AS3 is more akin to Java than any other language. AS3 makes conventional, structured application development possible.

And, since the world seemed to be moving inexorably toward managed languages, I thought that I had left the world of memory leaks in the archaic past, and that it would henceforth be dredged up only in drunken thought experiments with old-school hackers in dingy bars at 4am.

Not ’til the Fat Lady sings

But I was wrong. Because addEventListener() is the new malloc().

If you repeatedly (or naïvely) add event listeners but forget to remove them, even a small, simple flash application can eventually end up hogging a very large amount of memory. Sound familiar?

Typically this happens when an developer creates load listeners, or mouse listeners, then removes assets from the display list without removing the listeners. Those assets still remain in memory as long as they are “listened to”. This is because the listener (e.g. the stage) retains a list of all of its dispatchers, so the listener can’t be garbage collected until it is removed from this list. Using “weak links” when creating adding listeners can help, but I have historically found this too buggy to rely on.

In ActionScript 2, although this mechanic was also possible, it manifested itself less often, because Flash assets were removed from all dispatcher lists (and from memory) when they were removed from the display list using unloadAndStop() or similar. In AS3, however, assets can exist before or after they’ve been removed from the display list, which is less forgiving for sloppy coding.

This of course, isn’t specific to ActionScript: just any managed language which includes or supports event dispatchers and listeners (C#, Java, etc.). Extra care needs to be taken when using this model. Everytime you add a “transient” listener, there should be code somewhere else to remove that listener, just like malloc/dealloc.

Here’s some psuedo-as code to demonstrate:

loader.addEventListener(COMPLETE, onLoadComplete);
function onLoadComplete() {
  loader.removeEventListener(COMPLETE, onLoadComplete);
  // ... (Loader handling code)
}

So that’s pretty much it.

I’m using Flash CS4, and the fps is set to 30. However, when I run it normally (within flash using “Test Movie”) I get a frame rate of 19.95 fps or so, and it’s quite steady. When I run it externally, with the flash player or in a browser, I get pretty much exactly 30 fps.

The frame rate in Flash remains at about 19.95 even if I bump up the fps to 60, even though this is faster fps is reflected correctly when it’s run externally. The game is a simple tile-based puzzle game, and is certainly not CPU bound. When running inside Flash, it’s using about 13% of the CPU.

When I set the framerate to, say, 10 fps, it runs at the correct speed everywhere.

Anyone have similar experiences with Flash? Any advice?

So don’t bother meticulously violating DRY principles when creating these things dynamically. You can pass any integers you like, including zero or negative one, but I particularly like using NaN because it makes it clear that you’re not even trying to supply a number that could possibly be interpreted in any meaningful way (even if that’s a tad passive aggressive…)

// e.g.
var myBitmapData:BitmapData = new MyFancyBitmap(NaN,NaN);
trace(myBitmapData.width + ", " + myBitmapData.height); // outputs: 45, 45

It seems a bit ugly to me that the generated BitmapData subclasses require their parameters. I really do think they should be optional at the very least, and ideally, illegal.

Hope this saves someone some time.

Here’s a class that will do that for you. It uses a “Catmull-Rom” spline (named after its inventors), which draws directly through any number of points.

It’s not a spectacular or pretty looking curve. It’s very “dowdy”, and somewhat ugly, but it doesn’t make wild swinging curves like many other equations. This humble quality makes it really good for situations where it’s important that the curve stays pretty close to the control points.

Example SWF (actionscript code)

CatmullRom curve actionscript class

BlackScreen's normal state

BlackScreen is an extremely simple utility application that displays a full screen of blackness for you.

I created it because I wanted to be able to easily see where my screen was dirty without shutting down or sleeping my computer. It could also be useful if you want to quickly hide what’s on your screen from beady prying eyes.

It’s built on AIR, so it’s cross-platform as long as you have Adobe’s runtime installed.

Download BlackScreen 1.0.

(Safari users should disable Open “safe” files after downloading in Safari’s preferences before downloading.)

Windosill.

My love for ancient bone china is unrivaled.

Bull in a china shop? It seems that’s not quite funny enough a premise for a computer game these days. Thankfully, Minotaurs are funnier than bulls in this context. Whew.

Minotaur China Shop is perhaps the most fun in-browser game I’ve played in a long time. And it made me laugh. Maniacally.

After you’ve played it (or while you’re waiting for it to load, if you’re a New Zealander), check out the back story. Never before has the phrase “tragic comedy” made so much sense to me.