Download
MotionBrush.zip

I’m pretty happy with this new software, so I’ll try to post more videos. Still working on getting better resolution out of the video host though…

stage.width will return the width of the content on the stage and ignore any empty pixels around the edges. So if you only have a 100 px wide rectangle on stage, your stage.width will be 100.

stage.stageWidth will give you the size of the stage, more like Stage.width in Actionscript 2. Use stage.stageWidth if you’re trying to position elements relative to the stage.

Same goes for stage.height and stage.stageHeight.

The short answer: Instance Names.

For the detailed answer check out this video tutorial using Actionscript 3.

The Actionscript has to know “who” you’re wanting to talk to. Just as we know human beings by name, and talk about them and to them by name, Actionscript references objects by name. A teacher might tell “Timmy” to sit down. Accordingly, your script might tell “circle” to move 10 pixels to the left. If no symbol with the name, “circle” exists, nothing happens; just as no one sits down if there’s no “Timmy” in the classroom.

Referencing nested MovieClips works the same way, just add a dot inbetween:
var clipReference = grandparentClip.parentClip.childClip;

Remember that a symbol name is different than an instance name. You can have multiple instances of a symbol on stage, but each instance name has to be unique. Instance names are set in the Property Inspector, symbol names are set in the Library.

Keep this idea in mind when working with Actionscript and it will make your life a whole lot easier.

I’m a big believer in the open-source movement and many times I’ve been able to find an open source solution that does the trick as well or better than a packaged piece of software can. So I started searching under the assumption that I would eventually settle on an open-source solution. In the case of Actionscript documentation, I found my ideal solution in VisDoc. It was one of the few solutions that had a Graphical User Interface rather than using a command line. It produces a beautiful set of documentation files. It works for both AS2 and AS3 (and Java). The one downside is that it’s Mac only. It’s not open-source, but with a sticker price of $40, it’s well worth the time saved. If you’re still looking for open-source or you need an app for your Windows machine, OSFlash has a comprehensive list of open-source documentations tools for Actionscript.

(from Wikipedia)

… is a system design principle where the implementation takes into consideration future growth…

…the design includes all of the hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure….A good architecture provides the design principles to ensure this—a roadmap for that portion of the road yet to be built…These excess capabilities are not frills, but are necessary for maintainability and for avoiding early obsolescence.

…can also mean that a software system’s behavior is modifiable at runtime, without recompiling or changing the original source code.

—-

This idea is useful when building projects that have iterations or phases. Sometimes the client knows they’re going to want multiple versions of a given project. Realistically though, this happens all the time, even when one is working with little outside influence. An idea doesn’t usually look the same on the screen as it does in our minds or in a script. It needs tweaking and fine-tuning. As designers, we often go through myriad iterations before reaching the final product. Over time, I’ve come to realize ways to save myself future hassle by taking time upfront, at the start of a project, and planning what pieces might change how I can design them to be more flexible and more economic. This ‘brain-time’ early on reduces the ‘oh crap’ time later.

Thinking in terms of extensibility: Grouping

The simplest and earliest tricks we learn as Flash designers is to create symbols. This saves filesize because Flash only has to load each symbol once, even if it’s used a number of times. The other great advantage of using symbols is that you can edit it once and affect every instance in your file. The symbol in the library acts as a prototype, or for you philosophers out there, it’s much like a platonic form, the ethereal ideal from which all earthly instances are based. More generally, symbols could be considered to be a way of grouping. The group of instances has a common set of basic characteristics that are described by the symbol in the library. New characteristics can be added on top of those inherited from an instance’s group (like giving a movieClip instance a tint or changing it’s alpha on the stage).

Arranging problems into generic groups reduces the effort needed to solve them. Functions can be made more generic by passing in variables. Instead of writing code out for 4 tweens, why not write a tween function and pass into it the movieClip you want to tween as a variable. You can make the function more generic by passing more variables (start point, end point, duration, etc.).

This, taken to it’s logically conclusion, begs the question, ‘If I can write functions to reuse within a given file, why not write code that I can reuse for multiple files?’ Enter Object-Oriented Programming . Object-Oriented Programming (OOP) allows you to save code in Actionscript class files and access it from Flash by creating an instance of that class. A movieClip, for example, is an instance of the movieClip class. Each movieClip has several properties (x, y, width, height, alpha, etc.) and behaviors (onEnterFrame, onRelease, onRollOut, etc.). These properties and behaviors can be reused in a new class by extending the movieClip class, so that your new class will allow you add to the functionality of movieClip and will contain all the properties and methods that a movieClip does. You can also write classes from scratch. The idea, in short, is invent to the wheel once.

To learn more about OOP in Flash 8 or Flash MX 2004, check out Object-Oriented ActionScript For Flash 8 by Todd Yard and Peter Elst. A new edition for AS3 is also available, but nearly any book on AS3 will have to address OOP. Actionscript 3 is almost entirely OOP-based, though AS2 is geared toward OOP, it is a bit more forgiving of non-OOP-based code.

The Other Extensibility: ‘modifiable at runtime’

There’s probably no better exercise for extracting information into generic groups than XML. An XML document is essentially a text file, it looks a lot like HTML, except that the tags are completely made up. A tag in XML has no predefined meaning, it’s up to the application to decide what the tags mean. How’s that for generic?

Flash can pull data from XML at runtime. The XML can be used to swap images, swap text, and even change behaviors if the Flash file has been so setup up. That means that an SWF (Flash’s export format) can be altered without republishing from Flash or even having Flash installed! This can save tremendous amounts of time for a file that requires frequent updates and it can even empower clients to make small changes without having to come back to the designer. All because a little ‘brain-time’ was utilized at the beginning of the project.

There are other methods of customizing at runtime as well. I had a project a while back that was a Flash presentation. It required an IP address specific to the location of the presentation. Since the presentation was going to be given twice at two different locations, it was assumed that a duplicate presentation would need to be made. What’s more, the IP addresses weren’t easy to find beforehand, and this customization may have to take place the day of each presentation. I suggested instead, that a text input come up at the beginning of the presentation so that the presenter could enter the site-specific IP address, it would be stored temporarily, and later displayed in the presentation. This saved a handful of hours and a whole lot of headache, made me look like a genius, and didn’t even require that the presenter edit an XML file beforehand.

The Problem with Extensibility: Selling it to Clients

Design is an expensive business. Good design is very expensive. And there’s nothing like a design budget to make a client seem stingy. It’s a business that often requires designers to justify their existence and their rates.

At first blush, extensibility planning often seems like an unnecessary expense to a client, and may seem like wasted time to a novice designer/developer, but in truth, when it’s done well, it’s a no-brainer. A little brain-time upfront can save designer and client alike a whole lot of headache down the road. It ultimately tends to save money during the revision process as well. Clients (as a big amorphous group) are famous for changing their minds, and the less that you, as the designer, have to wrestle with when this occurs, the better your life will be. The trick then becomes selling it to the client at the start of the project. Some extensibility, of course, can occur without the knowledge of the client. The client doesn’t usually have to know the fine details of your library structure or coding nuisances, nor do they care. For more ambitious extensibility though, the ‘brain-time’ will be evident in the budget.

Imagine you’re the first person to suggest a car without a crank. Let’s forget for a moment the awful consequences and inefficiency of a combustion engine. You’re engineering this car as a freelancer for a large auto manufacturer. The dilemma is that it will take several extra months to engineer properly, and once it is completed, it will require a bit more testing than the existing model (because it’s new and slightly more complicated). This extra time on your behalf translates into a greater price tag for the manufacturer and hence, is significantly less attractive than the status quo. The upshot, however, is that drivers of your vehicle won’t have to crank the car (which might also prevent them from losing an arm). The appeal of this convenience compounds for drivers that live in snowy areas. Your job then (in addition to engineering the thing), is to explain to the manufacturer what this will do for their business, even though it will cost them more upfront, it will ultimately be a huge moneymaker (and may save on lawsuits from people losing their arms). This is the essence of selling extensibility.

The problem is that clients have extreme difficulty ignoring their immediate bottom line, even if it will dramatically improve their bottom line in the foreseeable future. We see this everywhere nowadays, a company cuts wages, not thinking they will lose employees or hurt morale (and therefore productivity) or that the employees may not be able to afford the goods produced by their own company. It is an unfortunate consequence of unchecked capitalism, and to some degree, human nature. Understanding that, selling extensibility must be approached with patience. I’m convinced though, that the frustration of repeated explanation will be trumped by not having to go through completely avoidable and repetitive design changes. And hopefully a little ‘brain-time’ and a little ‘explanation-time’ will still save a whole lot of ‘oh-crap’ time in the end.

So when I have to indent several lines of code, I select all the lines I want to indent and hit the TAB key. You can also decrease the indent by hitting SHIFT + TAB. This also works in external editors like SE|PY. It’s a little bit slower than auto-format, but it’s a lot faster than clicking and tabbing each line individually.

Not everybody’s a programmer, though. So I’ve provided this detailed tutorial
for anyone would like to add a preloader to their Flash web project.

Getting started:

I usually like to put the preloader in its own scene so that it doesn’t disturb
my main timeline. If you’re not familiar with using scenes in Flash, a scene
can be added in the following manner:
- Window > Other Panels > Scene
- click the “+” to add a new scene
- drag it to the top
- and double-click to rename it
- I usually name it “preloader” and from hereon out I will refer to
it as the preloader scene

Then make sure your actionscript is organized in its own layer in the preloader
scene:
- add a new layer and rename it to ‘actions’
- lock the layer so nothing accidentally get placed on the stage for this layer
- select the first keyframe on the actions layer and open the actions panel
- the actions panel can be opened by hitting the f9 key or by going to Window > Actions

Then enter the following code:

Now for a detailed description of what everything does:

stop();

The stop() command tells the playhead to halt but allows the code on the stopped
frame to run.

loaderbar_mc._xscale = 0;

This code initializes the ‘_xscale’ property of an instance with the name
‘loaderbar_mc’ so that it has no width (because the movie has just begun loading).
This is basically a rectangular movieClip. The instance name is applied via
the properties inspector panel. Select the loaderbar movieClip on the stage
(it needs to be in the preloader scene if you chose to do this the way I’ve
listed). Make sure your symbol is a movieClip. Graphic symbols cannot have
instance names and are therefore inaccessible with ActionScript.

function preloading():Void{
var bLoaded:Number = getBytesLoaded();
var bTotal:Number = getBytesTotal();
var percentL:Number = (bLoaded bTotal) * 100;

This is the beginning of a custom function that I’ve written called ‘preloading’.
The word ‘function’ is used to begin the function, then the function name.
The parentheses are empty because no variables are being sent to the function.
The word ‘Void’ tells the application that the function is not returning any
variables, and the curly bracket begins the content of the function.

The next 3 lines are variable declarations. The ‘:Number’ is what’s called
strict data-typing. It tells Flash that this variable should be a number. If
I try to load it with a string variable (“atom” for instance) or
a boolean value (TRUE or FALSE), Flash will report an error in the output panel.

The first variable retrieves the bytes loaded by Flash, the second retrieves
the total bytes, and the third divides the current loaded bytes by the total
bytes to get a percentage (multiplying by 100 gets it into the form we’re used
to, like 56 instead of .56–we’ll add the percent sign next).

if (percentL < 100){
// (A) if you want to show text in the form of xx% loaded
percent_txt.text = Math.round(percentL) + “% loaded”;
// (B) if you want to show text in the form of xx Kb loaded/ xx Kb total
percent_txt.text = Math.round(bLoaded/1000) + ” Kb / “ + Math.round(bTotal/1000) + ” Kb” ;
// (C) if you want a loaderbar to grow with the % loaded
loaderbar_mc._xscale = percentL;
}

This next block is an ‘if’ statement. The content of the if statement is contained
in curly brackets just like our function (which we are still inside). The code
inside the parentheses is the statement that drives this command; as long as
it’s true, the lines inside the if statement’s curly brackets will continue
to run. In this case it’s checking to see if the percentL variable we created
in the previous line is less than 100.

The lines that begin with ‘//’ are merely comments for reference, they have no affect on the code. They represent 3 different
options I have provided for displaying feedback to the user. They can be used
seperately or in combination. Make sure to delete the items you don’t use or
comment them out by adding two slashes (‘//’) at the beginning of the line.
The ‘percent_txt’ refers to a dynamic text box on the stage with the instance
name ‘percent_txt.’ This text box must be set to ‘Dynamic text’ in the Property
Inspector to give it an instance name that we can reference with ActionScript.
I usually choose a web font (verdana or arial) and select ‘Use device fonts’
from the Property Inspector. This utilizes the user’s own fonts and keeps the
Flash file size low. The alternative is embedding a font, and depending on
the font, that can add a lot of girth to an swf.

The first two options (A and B) are merely concatenations (lumping bits together
into a string of text). I use Flash’s built-in Math.round function to round
to whole numbers for a less cluttered display. The third option (C) uses the
‘percentL’ variable that was created earlier to determine the size of our loaderbar_mc
movieClip, hence the loaderbar will seem to grow.

Finally we close out the ‘if’ statement with a curly brace.

else {
clearInterval(loaderInterval);
play();
}

Next, we use an ‘else’ statement to clear the ‘loaderInterval’ (which I’ll
explain in a second), and play() the main timeline (i.e., start the movie).
The else statement is what gets called when the condition within the if statement
(percentL < 100), is no longer true (because the movie is completely loaded,
100%).

}
loaderInterval = setInterval(preloading,25);

Finally we close out the function with a curly bracket and we’ve come to the
interval. An interval is something that occurs repeatedly until it’s cleared.
This is an alternative to using ‘onEnterFrame.’ I’ve stopped using onEnterFrame
because I like the versatility of using intervals.

This bit of code actually gets called before the ‘preloading’ function, because
a function must be called in order to run. In this case the preloading
function is getting called every 25 milliseconds or 40 times/second. This allows
for smooth animation of the loaderbar even if the swf is only set to 12 frames/second.
Whereas, onEnterFrame will only run at the document’s frame rate.

First we need to declare
the interval with a variable name so that it can be referenced and cleared
in our ‘else’ statement, hence ‘loaderInterval.’ Next we use the setInterval
function and two of its paramenters to call the preloading function from above
every 25 milliseconds. That means that ‘preloading’ will be called over and
over until the percentL variable reaches 100.

Clearing the interval is important
because it is memory intensive to have the user’s CPU calling a function over
and over, especially when other things are occurring within the swf. That’s
why we clear the loaderInterval once we’re done using it. I called this variable
‘loaderInterval’ because that’s its purpose in this code, but an interval can
be named just about anything.

Testing The Preloader

To test your movie go to Control > Test Movie. You’ll notice the preloader
scene shows very quickly if at all. That’s because we’re testing it locally.
To see what it would look like in action go to View > Simulate Download. You
can change the speed of the connection that’s being simulated by going to View
> Download settings and selecting a different speed.

That’s it!

A quick note:
This preloader code is designed for ActionScript 2 (Macromedia Flash MX 2004
or later, Flash player 6/7 or later). To make this code function in ActionScript
1, remove all of the strict data-typing (basically everything beginning
with a colon–:Number and :Void).

Happy Flashing!

-Justin