Ben Jackson has been telling me to switch to alternative Flash Actionscript tools like MTASC, but I’ve been resistant. Today, however, I’ve gotten a little fed up with the sluggishness of the built-in Flash 8 compiler. The tradeoff: I like the Flash IDE, because it’s comfortable and I like editing graphics within the environment. Plus, since I’m working on a PC, the experience doesn’t have the tradition of sucking as it has on the poor Mac platform (though this has since been fixed in Flash 8…yay!)

Anyway, MTASC is much faster and more robust, but it is a command line tool with a different workflow compared to the Flash IDE. Time to do some research!

Warning: geeky notes follow, covering what it took to convert from Flash IDE to MTASC-friendliness. Ben already has a Mac writeup, so I’ll be focusing only on Windows.

MTASC Installation Basics

On Windows, it’s pretty simple to install:

1. Go to mtasc.org and download the pre-compiled windows binary. It’s a ZIP archive.

2. Unzip the archive, and copy the resulting folder to someplace where you will keep it permanently. I have a dev folder in my d: drive, so it’s in d:devmtasc.

3. Since I’m running MTASC initially in a command-line environment, I have to add the MTASC directory to my path, so I can run it from any directory I’m working in. NOTE: This isn’t a strictly-necessary step; I describe the batch file later that allows you to just double-click. However, if you are a command-line commando, do this: right-click the My Computer icon, choose Properties, then click the Advanced tab. Then click Environment Variables. You’ll then edit the PATH System variable. I added d:devmtasc; to the end of the existing settings. You might want to first COPY the path value first and paste it into a text file…just in case you mess it up and create all sorts of problems for yourself. Yes, it’s that important.

4. Next, test that your path is set-up correctly by going to the Windows Start Button and choose Run… from the menu. Type cmd into the box: this is what will pull up your command-line shell. To test that you’ve set the MTASC path correctly, type mtasc and see if you get a help listing. If you instead see the error message mtasc is not recognized as an internal or external command, operable program or batch file, then you haven’t set your path correctly. Double check that the path is correct, and that you edited the system variable in the previous step correctly.

BTW, if you Hate the Windows Command Line Shell…

When it comes to command line interfaces, I prefer more unix-like shells. So I downloaded UnixKit and am using that instead of the Windows cmd. The main advantage is that I can type ls instead of dir, and this makes me happy. Incidentally, UnixKit doesn’t actually install anything, so you can easily move it from computer to computer on a flash memory drive and bring a unix-y environment with you when you travel. Yay! Ok, back to MTASC.

MTASC Conceptual Hurdles

MTASC is an Actionscript 2.0 compiler, pure and simple. This means it doesn’t do several things that we take for granted in the traditional Flash authoring environment:

• MTASC doesn’t know how to create any graphics assets at all, and it doesn’t understand .FLA files. Therefore, you must import graphics assets from a .SWF file during the compilation process. So you’ll still need Flash to create library assets. Alternatively, you can use something like SWFMill; I should look into it, but haven’t yet.

• Since MTASC an Actionscript 2.0 compiler, it doesn’t digest legacy coding conventions very well. And the way my Flash movies in the past have started up is by putting an #include on frame 1 of the .FLA file. This was fine back in the day, and still works within the Macromedia Flash environment, but it will not fly with MTASC. There’s another way to do it.

• Since MTASC exists outside of the Flash environment, you will also need to set classpaths. You’re used to doing that already with Flash’s “Actionscript 2.0 Settings”, so you just need to know how to set them when compiling with MTASC.

To convert my existing simple Actionscript 2.0 application (maybe a dozen of my own classes, plus Alex Uhlmann’s AnimationPackage), I had to address all these issues.

Clarifying MTASC Command Line Usage

I was confused initially by what I thought was an ass-backwards compilation process. The usage notes states this on the main MTASC page:

MTASC takes the SWF file specified with the -swf flag, compile all .as specified files, and update the SWF file by replacing all classes that are present inside it by the newly compiled classes. To use MTASC instead of Macromedia Flash Compiler, it’s simple. Open your project and publish it normally (for example project.swf). Now run MTASC using the published SWF as input : mtasc (your as files) -swf project.swf. This will compile your classes and update the SWF that you can use for your website. Please note that MTASC add the compiled classes to the SWF in replacement of ALL classes compiled by Flash.

That sounded like to use MTASC, I had to first compile with Flash to create a SWF, then compile again??? What? The first time I read that, I completely lost interest and continued to use the Flash IDE. However, today I read a little further in the tutorial:

The only thing you need to do in order to run the sample is to call MTASC with the following arguments :

    mtasc -swf tuto.swf -main -header 800:600:20 Tuto.as

A hah…all that stuff about “compiling your source files with Flash first” isn’t necessary…it’s only if you want to, for some reason, use MTASC to recompile your SWF movie after you, uh, have already compiled it. You have the option of specifying a new entry point and generating a new SWF. That’s the piece I was missing. Speculation on usefulness of the other way:

• It’s possible that MTASC produces more optimal bytecode than the Macromedia compiler, and therefore produces faster code. That would be the traditional reason for switching compilers in the first place, but as the ‘compiled’ code is actually interpreted bytecode, I don’t think this is the case…however, I haven’t looked into this at all.

• It’s also useful if you want to do stricter source code checking on your existing source, as the Macromedia compiler is a little more forgiving and at times flaky.

• UPDATE: After thinking about this, it actually does make sense if you already have your .SWF set up and are doing incremental changes…you just need a stub class and can recompile into the existing .SWF. It just seemed counter-intuitive based on my past command-line compiler experiences (admittedly, a bit limited).

Reorganizing your Flash Project for MTASC

Conceptually, this is how I broke down my Flash project to make it MTASC-compatible:

1. Designate or create a class that will be your “startup class”. Mine is called Application.

2. Get rid of any initialization script code on the Timeline. You’re coding in pure Actionscript 2.0 now, even more than you were before, so we must say goodbye to our hybrid scripting techniques; that includes using #include statements in Frame 1 of your Timeline. You will move your initialization code to the startup class, in a static method called main in a class of your choosing. For me, that’s my Application class.

3. After you move all your initialization code to the main() static method of your start up class, test that it still works in Flash. I nuked everything out of my frame 1 script and replaced it with a call to Application.main().

4. If you’re using any graphic assets in the library programmatically through the use of linkages, you still need Flash to create the .SWF file. The SWF will be imported into MTASC using a command-line option (more on that later).

Running MTASC from the Command Line

After I checked that the application was working within Flash, I was ready to run MTASC. As with any command-line compilation process, we need to know a few things up front:

• The classpath of our Actionscript 2.0 .as source files

• The path to the “startup class” Actionscript 2.0 file.

• The path to the graphic assets .SWF file.

• The path to any supporting classes, if they aren’t in the same package structure of our application. For example, I keep animationpackage in d:devanimpackage, which is outside the classpath of my test project. We’ll be entering this information into MTASC so it doesn’t complain. You don’t need to include the Macromedia Flash classpaths; MTASC comes with its own.

• The filename of our final compiled .SWF file, which I want to be separate from the “assets” file.

Here’s how my project breaks down as far as directory structure; I’ll be using this in the compilation example:

• my application’s classpath: d:devmyprojectflashclasses

• filename of startup class: d:devmyprojectflashclassesappApplication.as

• path to graphics assets (named movieclips in the library): d:devmyprojectflashassets.swf

• path to other libraries, in my case animationpackage: d:devflashanimpackage

• name of the final output file: d:devflashmymovie.swf

The next step is to create an MS-DOS batch file that will execute the mtasc command line compiler. Making this batch file will allow you to double-click the batch file to compile; you could also run it from the command line directly by typing the full name (include the .bat extension). Here’s what the batch file looks like:

Line  Batch File Line
01    "D:/dev/mtasc/mtasc.exe" ^
02     -main ^
03     "d:devmyprojectflashclassesappApplication.as" ^
04     -swf "d:devmyprojectflashassets.swf" ^
05     -cp "d:devmyprojectflashclasses" ^
06     -cp "d:devflashanimpackage" ^
07     -out "d:devflashmymovie.swf" ^
08     -version 8 ^
09
10    pause

Instead of copying/pasting this example, you should download this file by right-clicking and choosing “save link”. If it’s been a while since you’ve seen a batch file, the ^ symbols are MS-DOS “line continuation” characters, which makes the file a lot more legible. Here’s what’s going on:

• Line 01: This is the MTASC compiler program. Everything after this is a parameter that tells MTASC what to do.

• Line 02: Tells MTASC that the “startup class” has a main() static method, and that the SWF should start program execution there.

• Line 03: The “startup class”. MTASC will automatically parse and recursively compile all other classes, starting with this class. If you tested your application in Flash before converting it, then everything should be fine.

• Line 04: The swf file that has all those named Library assets that you’re using with methods like MovieClip.attachMovie(). If you’re not using any, you can just leave this out and replace it with the -header option, which will create a brand new swf file. See the MTASC documentation for more.

• Line 05: The classpath to my project’s Actionscript files.

• Line 06: The classpath to my installation of AnimationPackage. If you have other classpaths, just add more like this.

• Line 07: Specifies the name of the output SWF file. If you don’t use this, then the file specified in Line 04 is used, leaving all library elements intact. I have them separate because I like the idea of having my asset files separate from my compiled output.

• Line 08: Tells MTASC to compile for Flash 8 instead of the default. Note that there are some missing definitions in the Flash 8 Video object, so if you get any undefined parameter errors, you’ll need to go into the MTASC installation directory, go to the std8 directory, and edit the appropriate intrinsic class file.

• Line 09: Left blank, so the previous line’s trailing ^ spills into it and doesn’t collide with Line 10.

• Line 10: Pauses the output of the command, so you can read it if there’s a problem with compilation.

Once you’re done editing the file for your own purposes (there are instructions in the REM statements to help you), give it a whirl by double-clicking the icon (remember it has to have the .bat extension to run, and you need to use full pathnames in the file). If you’re a masochist like me, type it into the command shell.

• If you’re having a good day, you should see the command line executing, and quite probably some compilation errors; MTASC is a lot pickier about the correctness of your code syntax compared to the Macromedia Compiler, so you’ll probably have some cleanup to do. There are also some things you can’t do in MTASC, like nested functions, referring to static class properties inside anonymous functions without fully qualifying the package name, or leave extra ; marks lying around. I’m still figuring it all out, so don’t ask me for help…I probably won’t know :-)

• If you see any errors related to missing files, you’ve goofed up…go back and make sure everything is correct. I will have no patience for your typos, but will accept responsibility for mine :-)

That’s It!

<

p>I’m feeling a little better about using MTASC for future projects. My next step will be actually picking an IDE like Actionscript for Eclipse, or possibly trying to figure out how to make this work with Flasc or Enterprise Architect. I’m just starting to look at these.

Hope this saves someone a bit of time…enjoy!