Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)

scrottie
  scott@slowass.net
http://slowass.net/

My email address is scott@slowass.net. Spam me harder! *moan*

Journal of scrottie (4167)

Wednesday March 25, 2009
04:16 PM

Starting to "get" Flash and ActionScript

[ #38699 ]

All that about "timelines" and "movies" threw me and the GUI interface to manipulating this machine just made it all more obtuse. But I'm starting to get it. Every description I've read in books was built on piles of unvoiced assumptions.

A "movie" can be an image, a line drawing (either/or procedurally created in ActionScript or manually created using the GUI environment), mpeg data, or perhaps other things. If the movie is a line drawing, it may be "tweened" so that it has a start shape and end shape and morphs between the two in in-between frames. This may be as simple as a zoom effect where the object gets larger or smaller over time. Any type of movie may have any of the basic simple attributes change over time, as the animation progresses: x position, y position, alpha transparency, rotation, and other things. The shift in values for the variables can be arranged in the GUI builder.

Each movie may have code attached to it. onFrameEnter runs each frame the movie appears in and is the place where tweaks to parameters are usually made: tweaking x position, or stopping the movie, and so on. Buttons are a variation on movies that have onRelease and other events.

The timeline in the GUI marks up when the movies start and stop. Any number of movies can be stuck in there and their layer properties decide which appear over which other ones. A lot of movies are full-screen, covering up everything below them. Layers can change while the movie plays and this varies from the order that the movie clips are listed on the screen.

A few things can happen when a movie ends: it stops (corresponding to the stop() function) and stays on screen, not moving. Or it's layer or alpha (usually alpha) is tweaked to make it disappear behind (or disappear over) other things. Or its x or y is tweaked to move it off-screen. Or it might be configured to play again.

"Movie" is also the name given to the assemblage of movie clips/objects, the timeline, and any ActionScript code in the system.

It is entirely possible to make a "movie" (.fla file) entirely in code linked to resources such as jpegs, for example using mtasc and swfmill. The work of starting and stopping movies clips, moving them on and off of the screen, and tweaking variables over time can be done entirely in code.

Let me get back to you with the details...

Other thing of note... rendering itself is entirely non-procedural. There's no draw() method, and no clipping. It's implicit. It'll re-render every stupid thing on the screen 30 times a second (or whatever framerate gets picked) even if nothing is moving, calling onFrameEnter for each object that isn't stopped as well (I think that's right).

Since everything gets re-drawn every frame without any sort of request being made for it to happen, affecting on screen objects by tweaking variables works. ActionScript programmers completely embrace this philosophy. Movies, buttons, network layer stuff, and about everything communicates in a typical ActionScript app not so much by calling methods on things but by setting global variables or instance variables in little objects. Next frame, 1/30th or 1/10th of a second later, code somewhere else will notice the variable has changed and do something else. The general effect is sort of a big, broken up program that runs top-to-bottom n times a second while at the same time graphics are redrawn.

-scott

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That's the animator paradigm for Flash development.

    The programmer paradigm is where you make a one-frame movie, stop it in the onEnterFrame, and do everything via alarms or asynchronous user actions. That is, you avoid Flash's conventions and DIY.

    In my experience, the best Flash programmers fit somewhere in between. They use Flash's innate animating power where it helps and just program the rest. In this mixed paradigm, you end up with a lot of nested movies, some animated some not.

    The Flash I've built l