I read this post on what not to do with private properties. It’s for Java, but applies to Flash as well. Apparently declaring a property is the “amateur” way to do it. This is how I would do it.

public class Person {
private var _age:int;
public function Person(age:int) {
_age = age;
public function birthday():void {

According to this fellow, that’s bad practice. You should always use accessors! Why write short concise code when you can write three times as much? Instead of age, use getAge() and setAge() because apparently its a lot better to write setAge(getAge()+1), rather than write age++.

Flash’s accessors would allow you to write age++, but this is still the most disturbingly defensive code I’ve ever seen. It’s a private property! A class is supposed to be able to manage its own properties. It’s other classes you’re supposed to mistrust, not your own. If a class has become so big it requires this kind of nonsense that’s a pretty good sign it should be split up into smaller classes.

In my opinion his only valid complaint is that its easier to make breakpoints. Fortunatly most of the comments for that article disagree with his opinion.

Presenting Doomed Online

September 16th, 2007

I finally got around to open-sourcing my Flash Doom port. It’s under the GNU General Public License (v2), and hosted by Google Code. You can see the current trunk here. If you checkout the source code (more details here), compile src/DoomTest.as or you can try working with my build.xml.

I actually wanted to name it ActionDoom, but turns out there’s already something called that. Since I refuse to mess with a guy called Scuba Steve, I went with Doomed Online instead.

Update: I added a demo to the page.

Update 2: I have temporarily suspended the project, since it’d be better to just port it from C anyway.

Flash Plays Doom

July 20th, 2007

Update 3: Visit the home of Doomed Online here.

Update 2: There’s a bigger, badder, version up now.

Yes, that’s THE Doom. This uses the original Doom shareware wad file and gets all content from it at runtime. There’s no preloader, so be patient, it’s 1.7 MB. Use the arrow keys to move.

You’ll need to view this in a browser with Javascript and Flash 9 in order to see it.

There’s no sprites yet (enemies, barrels, that sort of thing) and you can walk through walls too. There’s also a mysterious bug that erects unnecessary walls in the outer areas of the map, but altogether it’s still pretty fast and stable right now. There’s some rudimentary sound support too, although for some reason it sounds scratchy at the end of a sound right now. Press the spacebar to hear.

It took some trial and error to get this far, since making a fast rendering system is so important. I tried using the same method for drawing bitmaps as Papervision at first, and while it was very fast, it also looked terrible. Papervision’s technique doesn’t seem to work well in an FPS environment because the wall textures skewed as you walk along them. I tried again with another method that used Flash’s draw method heavily, but it was far too slow and hard to work with. I was about to trash the whole thing, but I tried a more basic system, roughly resembling how environments were drawn in the original Doom where each pixel is drawn one-by-one. It seemed like it was still too slow, but after a few key optimizations to the drawing routine it ended up being very fast. I honestly wasn’t expecting that, but it’s actually playable now on a decent computer.

I don’t know exactly where I’m going with this, but I’m pretty sure it’s worth it. The only thing I can’t do is the music, the format is roughly the same as midi, and as far as I can’t tell it can’t be preloaded. Everything else Doom is capable of is possible. This whole thing was developed entirely using Flex 2 and the Flex 3 beta with Eclipse on Ubuntu Linux. In other words, with only free tools, right down to the OS.

Update: Apparently nobody knows my name. I think that’s kinda cool, but it’s actually Max.

FZip – Updated

June 22nd, 2007

FZip has been updated, it has a couple nifty changes.

  • Apollo/Air has built-in deflate support (ironic, isn’t it?), so if you make an Air app, you don’t need to “prepare” the zip file like before. This means FZip can open any zip file from within Air.
  • There’s better support for foreign language filenames. Unicode is now the default, but that can be easily changed.
  • There’s a new class, FZipLibrary, which is an (optional) processor that makes it easier to convert incoming files into other formats (images, swf files, etc).

The Air support is the most significant change, but if you’re putting the zip online you’ll have to run it through fzip-prepare.py first.

I spotted this article describing how to make Ubuntu send mailto: links through Gmail. It’s not wrong exactly, but I wanted to improve upon it a little. I have my own version which requires no external files, and all it needs is that you send your mailto: links through this command…

sh -c "firefox 'https://mail.google.com/mail?view=cm&tf=0&to='$(echo "$1" | sed -e 's/mailto:(//)?//' -e 's/?/&/' -e 's/&subject=/&su=/I')" custom-mailto-launcher "%s"

On Ubuntu, go to System -> Preferences -> Preferred Applications, change your mail reader to “Custom”, then put this line in. If you use another version of Linux, you’ll have to figure that part out yourself. Keep in mind %s is the variable and firefox is the default browser in my example.

Mine removes the “mailto” part a little better, and makes a hacky attempt to parse the subject/cc/bcc arguments these links sometimes have. Most importantly though, it’s a one-step process.

Debugging Flash on Linux

February 27th, 2007

While the standalone Flash Player on Linux is pretty good, but it kept crashing on me the other day when I tried to use fdb with it. I thought up another solution, and it works surprisingly well. It uses wine with the Windows version of the standalone player as an alternative player for Linux.

First, make sure wine is installed. If you’re using Ubuntu, you’ll need to enable the community maintained (universe) repository in Synaptic in order for it to become available. You should already have the Flex SDK, if not I have more on this in my guide to Flash development on Linux. Create a file called gflashplayer in Flex’s bin folder unless it already exists. If that’s the case then it’s probably your regular debug player. Rename the old one flashplayer-debug and then create the empty file gflashplayer. Open gflashplayer as a text file and write this…

if $USEWINE; then
wine $(dirname "$0")/../player/debug/SAFlashPlayer.exe $*
$(dirname "$0")/flashplayer-debug $*

Now whenever gflashplayer is run, it will redirect it to the wine-powered instance of SAFlashPlayer.exe. It works for debugging too, at least on my computer (Ubuntu 6.10, wine 0.9.30-0). You may need to configure wine first, try typing winecfg in the terminal and adjust the settings.

I still like the Linux version better, but it’s good to have the alternative ready when you need it. If you want to switch back, change USEWINE=true to USEWINE=false. You’ll need to have the Linux debug player (available here) named flashplayer-debug and located in Flex’s bin folder.

Update: How strange, the wine-powered standalone player is the most stable Flash player I’ve used yet. On Windows it would occasionally be unable to connect to the debugger until I restarted Eclipse, usually related to having to many players open at the same time. On Linux it will crash unexpectedly. Now I can have a dozen debuggers open at the same time with no crashes yet.

EDIT: This guide still seems to get a lot of attention but it should go without saying, at this point it’s a bit outdated. The ant flex tasks and the standalone Flash player are now included with the Flex 3 SDK for one thing. I don’t use Eclipse and fdb anymore myself since I learned to dislike Eclipse and the debug version of the standalone Flash player will dump trace messages to stdout (so it will appear in a terminal).

This guide isn’t particularly definitive, mostly because right now all the tools needed lack real cohesiveness, paticularly on Unix. This is simply how I pulled everything together to make things work using freely available software.

Step 1: Get Eclipse

Download Eclipse. Put it somewhere. If you’re using Linux, install using it using your favorite package management software. This guide will probably only work if you use 3.2 or above. (NOTE: If you use Ubuntu for this, then at the time of this writing Eclipse 3.2 is only in the “universe” repository, you can enable “universe” using Synaptic)

Step 2: Pull Flex together

Download the Flex 2 SDK. You’ll probably need to sign up for an account. Extract it. Download the Flex Ant Tasks and extract flexTasks.jar (in lib) to lib in your Flex directory.

You’ll need to set up the standalone player so you can debug your swf files. This varies between Operating Systems…

  • Linux: Download the Linux Flash Players and extract the debug player (in standalone/debugger/flashplayer.tar.gz) to bin in your Flex folder. Rename the the debug player (which is named flashplayer) to gflashplayer. You can also install the debug plugin for browsers if you’d like.
  • Windows: Run SAFlashPlayer.exe (in your Flex directory, under player/debug/) and it will register itself as the debug player. There’s also two installers for debug plugin if you care to install them too.
  • OSX: Use SAFlashPlayer.dmg (in your Flex directory under player/debug/) to install the debug player. There’s an installer for debug plugin there too.

Step 3: Create a project

Create a general project in Eclipse and put various Actionscript-related files there. Create a file called build.xml. This will be your Ant build file, and what you’ll use to compile your project. There’s more details on Ant here. Here’s a sample…

<project name="sample" basedir="." default="build">

<property name="FLEX_HOME" value="/path/to/flex"/>
<taskdef resource="flexTasks.tasks" classpath="${FLEX_HOME}/lib/flexTasks.jar" />
<target name="build" description="Build">

<mxmlc file="example.as" output="bin/example.swf" use-network="false" compiler.optimize="true">

<load-config filename="${FLEX_HOME}/frameworks/flex-config.xml"/>
<source-path path-element="${FLEX_HOME}/frameworks"/>
<source-path path-element="/path/to/as3-library"/>




The taskdef entry and the FLEX_HOME variable need to be there in order to use the mxmlc task to compile swf files. On Linux the property use-network="false" mysteriously allows the compiled swf to access files on your computer, without it an error is thrown when you try to access a file

Step 4: Syntax Highlighting (optional)

There is no free Actionscript 3 syntax highlighter, and the only one for Actionscript 2 is poor (sorry guys). Luckily Actionscript resembles heavily resembles Java. Simply associate .as files with the Java Editor in Eclipse (Window->Preferences, then General->Editors->File Associations) and hope nobody notices.

  • To change the formatting (particularly tab width) go to the Formatter (Java->Code Style->Formatter) and toy with the settings until it looks like your preferred coding style.
  • To change the colors go to the Syntax Coloring section (Java->Editor->Syntax Coloring)
  • To prevent Java from making suggestions, go to auto-activation (Java->Editor->Content Assist) and remove any characters in the “Auto activation triggers for Java” section.

Step 5: Compilation

Open the Ant viewer in Eclipse (Window->Show View->Ant) and drag your build.xml file to it. Use it to run build files.

Step 6: Debugging Preparation

You’ll need another target in your build.xml used for creating a secondary swf for debugging.

<mxmlc file="example.as" output="bin/example-debug.swf" use-network="false" incremental="true" debug="true">

Run this target whenever you want to update the debug version of your swf. The debug="true" property needs to be there in order for it to work. Make sure the output/swf file has a different name than your optimized build since this version is purely for debugging and will be slower.

Step 7: Debugging

Open the External Tools window in Eclipse (Run->External Tools->External Tools…). Select “Program” and create a new configuration. Set “Location” to the location of fdb, the Flash debugger (it’s in your Flex directory, under bin). The working directory should be the location of your compiled swf files. The only argument should be the file name of the swf file you’ll be debugging.

Run the external tool configuration you just created (there’s a button for it on the toolbar) whenever you want to debug the swf. When you do a console will open up, and the debugger will start. The Flash Player window will open, but it will remain frozen until you type “continue” in the Eclipse console. All output (trace) will appear in the console. If you familiarize yourself with fdb you can make use of many more features. To stop debugging, type “exit” in the console or just close the player window and terminate fdb.

Javascript is Very Fast?

January 10th, 2007

Apparently my previous post was premature. My world has shattered and I have discovered the single most impressive example of Javascript. Ever. Considering that just this morning the very same event took place (but with Flash) this is one hell of a day.

It’s an emulator. In Javascript. Take a deep breath and let that sink in.

I really wish this guy would switch to Flash. I programmed in Javascript in the old days and it’s really no good for certain things. What those “things” are is vauge, but basically, writing emulators is one of those things. In any case, Flash got there first and FC64 is cooler.

Beware of Flash Hacking

January 3rd, 2007

I spotted this post (via Digg) this morning. It’s a guide to hacking high-score boards in Flash games and he knows what he’s talking about. He uses Flasm to disassemble and find information in a SWF file. All the more reason to make sure the methods you use for this kind of thing are carefully hidden.

I heard a great idea from someone named Dan on Flashcoders. Send fake variables alongside real ones when a score is submitted. It could get even better if you make them interrelated and sensitive to hacking – something involving bitwise math perhaps? You could also include checksums of course. There was also my idea to “record” user input (mouse movements, key presses, etc), encode it, and send that to a server. Then simply add in the ability to playback these recordings when you want to make sure they’re legit. It’s pretty tricky though, and could have lots of problems, for starters you wouldn’t be able to change your code without breaking old recordings and you can’t use Math.random().

While I don’t like this guy, it’s not as if these methods aren’t known already. Why did people have to digg it though? It’s cheating. What’s the point? I suppose Flash coders just have to get smarter when it comes to this kind of thing.

Bad Wii Design

December 30th, 2006

Update: I wasn’t really able to test this until now, but it looks like both media=”tv” and media=”handheld” (for when you press the “2” button) aren’t implemented. Like most beta software, there’s flaws. Hopefully this will be implemented in the future.

I’ve seen some WordPress plugins lately that change how WordPress looks if the user is accessing it with a Nintendo DS or the Wii’s Internet Channel.

Stop it. Stop it right now.

While I can’t really speak for the DS browser, if you wanted your site to be easily viewable on the Wii then use the features that are out there specifically for that purpose. CSS stylesheets can be loaded based on what’s displaying the website, and wouldn’t you know it? There’s a type specifically for televisions. It’s crazy enough to work.

<link rel="stylesheet" type="text/css" href="/css/special-tv-stylesheet.css" media="tv" />

Besides the fact that it’s the easier way, it also doesn’t use user agents improperly. By changing the site when the user agent has a “Wii” in it you’re assuming that people actually want it to be changed. I sure don’t. The Internet was never meant to be customized for Wii users, it’s already prepared for that. It’s not even a real way to detect Wii users either, it’s just a hack. I already went over this a few weeks ago, but relying on user agents is almost always poor web design. You’re also completely forgetting other lower-resolution devices that could use the attention as well.