• Compiled library to a SWC
• Added BlendHSL macros including: hue, saturation, luminosity and color blend functions
• Added ColorSpace macros, featuring conversion between RGB & HSL, desaturate, colorize, etc.
• Added new functions to RegisterType: isConst(), isTemp() , isReadOnly()
• Corrected an error in Component.as, register type was not passed on to component

So, with the addition of those HSL color space macros, that finally completes the library of color blending functions. Though, I do still need to add a little something to handle alpha blending… (Coming soon!) Online documentation has also been updated: http://barliesque.com/easy_agal/docs/

I’ve also just begun work on a testing suite. What that means is that you’ll be able to write a shader in the usual way, and then run it in a sort of test mode; which means you’ll be able to do things like add trace statements to find out what values are in a given register to find out where a calculation is going wrong. It’s a pretty big undertaking, but I think I’ve got it figured out. I welcome any suggestions here about what sort of features you’d like the EasyAGAL test suite to include.

Happy coding,
David

In case the term is unfamiliar to you, a macro is similar to a function in that it’s a bit of code that gets used and re-used repeatedly. The difference is that, where a function exists in one place in memory and is called by multiple points in an application, a macro is literally duplicated wherever it’s needed at compile-time. Presently, there is no way for AGAL to redirect program execution to call a function, or branch or loop — AGAL programs are executed in a straight shot, from top to bottom. So, in place of functions we must use macros.

Wherever you use a function from the Easy/EasierAGAL library, instructions are appended to whatever code is being assembled at the time. So you can write a set of handy static functions in their own class, to be called as needed. You can pass EasyAGAL registers as parameters, or any other data that may be useful to customize the macro. And you can organize your macros along with the rest of your ActionScript classes into logical packages so they’re nice and easy to find when you need them.

Interface types

There is one important rule in writing macros with EasyAGAL: you may not use any register that is not passed to your macro as a parameter. This is a good rule to abide by because it means that the user of the macro retains control over how registers are used; it helps to keep your macros as reusable as possible. When you define function parameters, or alias variables, you have four data type options:

• IRegister
  Just as it sounds, this type specifies an AGAL register. The whole register, that is, so CONST[0] is an IRegister, but CONST[0].xyz is not. If the user of your macro tries to pass VARYING[1].x where an IRegister was specified, they’ll get a compile error.

• IComponent
  Strictly a single component of a register. CONST[0].x is an IComponent, but CONST[0].xyz and CONST[0] are not.

• IField
  This type specifies any AGAL register (except for texture samplers) — either the whole register, or a selection of components.

• ISampler
  This type specifies a texture SAMPLER register. Trying to pass ATTRIBUTE[3] to an ISampler parameter again results in a compile-time error. No component selections of sampler registers are supported by AGAL.

So, for example, we can use ActionScript variables as aliases to AGAL registers, like so:

var position:IRegister = ATTRIBUTE[0];
var projection:IRegister = CONST[0];
 
multiply4x4(OUTPUT, position, projection);

A Simple Macro

Here’s a really simple macro to set a register or component to zero:

static public function setZero(dest:IField):void {
	// Subtract anything from itself and the result is always zero.
	subtract(dest, dest, dest);
}

I used IField for the parameter type because this allows the macro to be applied either to whole registers or individual components. Nothing is returned from the function, since its purpose is to append to the current shader code by calling the EasierAGAL command set. You might wonder, “Why bother to write a macro when there’s only one operation inside?” Simply because it’s clearer what the purpose of setZero() is compared to the subtraction statement.

Here’s another macro function to clamp a value to a range:

static function clamp(dest:IField, source:IField, minValue:IField, maxValue:IField):void {
	min(dest, source, maxValue);
	max(dest, dest, minValue);
}

I’ve placed these two functions in a class called Utils, so I can now use them in any Easy/EasierAGAL shader code, like so…

Utils.clamp(TEMP[2], TEMP[1], CONST[0], CONST[1]);
Utils.zero(TEMP[2].w);

As if you didn’t already know how to call a static function! Anyway, you’ll find these and more in the package: com.barliesque.shaders.macro

Other Parameter Types

Obviously, when writing macros you can specify whatever parameter types you want, not just AGAL registers. Have a look at the parameter list of the following function, specifically the comparison parameter.

static public const EQUAL:String = "equal";
static public const NOT_EQUAL:String = "notEqual";
static public const LESS_THAN:String = "less";
static public const GREATER_THAN:String = "greater";
static public const LESS_OR_EQUAL:String = "lessOrEqual";
static public const GREATER_OR_EQUAL:String = "greaterOrEqual";
 
/**
 * Return one of two results, based on a comparison of two values, componentwise
 * dest = (operandA compared with operandB) ? trueResult : falseResult
 * Contains 5 to 8 instructions.
 * @param       comparison      The type of comparison, e.g. Utils.NOT_EQUAL
 * @param       temp            A temporary register that will be utilized for this operation
 */
static public function setByComparison(dest:IField, operandA:IField, comparison:String, operandB:IField, 
                                        trueResult:IField, falseResult:IField, temp:IRegister):void {
 
        // First make the requested comparison
        // and set the temporary to the inverse
        switch (comparison) {
                case LESS_OR_EQUAL:
                        setIf_GreaterEqual(dest, operandB, operandA);
                        setIf_LessThan(temp, operandB, operandA);
                        break;
 
                case GREATER_OR_EQUAL:
                        setIf_GreaterEqual(dest, operandA, operandB);
                        setIf_LessThan(temp, operandA, operandB);
                        break;
 
                case EQUAL:
                        setIf_Equal(dest, operandA, operandB, temp);
                        //  temp = 1 - dest
                        setIf_GreaterEqual(temp, operandA, operandA);
                        subtract(temp, temp, dest);
                        break;
 
                case NOT_EQUAL:
                        setIf_NotEqual(dest, operandA, operandB, temp);
                        //  temp = 1 - dest
                        setIf_GreaterEqual(temp, operandA, operandA);
                        subtract(temp, temp, dest);
                        break;
 
                case LESS_THAN:
                        setIf_LessThan(dest, operandA, operandB);
                        setIf_GreaterEqual(temp, operandA, operandB);
                        break;
 
                case GREATER_THAN:
                        setIf_LessThan(dest, operandB, operandA);
                        setIf_GreaterEqual(temp, operandB, operandA);
                        break;
 
                default:
                        throw new Error("Unrecognized comparison type: " + comparison);
        }
 
        // Now apply result values to each...
        multiply(dest, dest, trueResult);
        multiply(temp, temp, falseResult);
 
        // ...and combine results
        add(dest, dest, temp);
}

So, now I can perform a comparison and get a result value in a single line…

 
//
// OUTPUT = (TEMP[1] <= CONST[0]) ? CONST[2] : CONST[3]
//
Utils.setByComparison(OUTPUT, TEMP[1], Utils.LESS_OR_EQUAL, CONST[0], CONST[2], CONST[3], TEMP[2]);

Watch Your Operation Count

Do be careful how you use macros, however. It’s easy to forget that a single macro might produce dozens of operations. Remember: There is a limit of 256 operations per shader program! That’s a pretty tight space to work in, but with multiple shader programs chained together, we can do just about anything. You can keep a tab on your operations count by looking at the following properties in the EasyAGAL base class:

trace("Operations in the vertex program: " + vertexInstructions);
trace("Operations in the shader program: " + fragmentInstructions);

By the way, you can also access the generated opcode, with optional line numbering:

trace("VERTEX SHADER:");
trace(getVertexOpcode(true));
trace("------------------");
trace("FRAGMENT SHADER");
trace(getFragmentOpcode(true));

Download EasyAGAL from GitHub.

Learning how to work with matrices to achieve rendering effects is challenging enough without having to take on a new and strange programming language. Given that there is no IDE especially for AGAL (at least for the time being!) I decided to write a small library that would assist me in writing AGAL programs, just as easily as writing ActionScript. So, what does that mean?

• Code completion and hinting
• Far more easily readable code
• Dynamic coding advantages

Two Flavors: Easy & Easier

Two base classes are provided for you to choose from: EasyAGAL.as which uses the original AGAL opcodes for function names, and EasierAGAL.as which uses fully expressed function names.

Compare these corresponding samples:

	"m44 vt1, va2, vc8 \n" +
	"nrm vt1.xyz, vt1.xyz \n" +
	"sub vt2, vc12, vt0 \n" +
	"nrm vt2.xyz, vt2.xyz \n" +
	"dp3 vt3, vt1, vt2 \n" +
	"mov v2, vt3"

	// With EasyAGAL...
 
	m44( TEMP[1], ATTRIBUTE[2], CONST[8] );
	nrm( TEMP[1].xyz, TEMP[1].xyz );
	sub( TEMP[2], CONST[12], TEMP[0] );
	nrm( TEMP[2].xyz, TEMP[2].xyz );
	dp3( TEMP[3], TEMP[1], TEMP[2] );
	mov( VARYING[2], TEMP[3] );

	// or with EasierAGAL...
 
	multiply4x4( TEMP[1], ATTRIBUTE[2], CONST[8] );
	normalize( TEMP[1].xyz, TEMP[1].xyz );
	subtract( TEMP[2], CONST[12], TEMP[0] );
	normalize( TEMP[2].xyz, TEMP[2].xyz );
	dotProduct3( TEMP[3], TEMP[1], TEMP[2] );
	move( VARYING[2], TEMP[3] );

You’ll notice that the EasyAGAL code simplifies the use of registers a bit — depending on whether you’re writing a vertex or a fragment shader, the appropriate register will automatically be used. So, for example, you don’t need to worry about vt1 versus ft1, only TEMP[1] which will be translated appropriately. We can make the EasyAGAL code more readable still, by assigning registers to variables with descriptive names:

	var normal:IRegister = ATTRIBUTE[2];
	var normalMatrix:IRegister = CONST[8];
	var xformedNorm:IRegister = TEMP[1];
	var intensity:IRegister = TEMP[2];
 
	multiply4x4( xformedNorm, normal, normalMatrix );
	normalize( xformedNorm.xyz, xformedNorm.xyz );
	subtract( intensity, CONST[12], TEMP[0] );
	normalize( intensity.xyz, intensity.xyz );
	dotProduct3( TEMP[3], TEMP[1], intensity );
	move( VARYING[2], TEMP[3] );

Skeptical?

Some may say “PixelBender3D does the same thing…” …which is actually quite inaccurate. PixelBender3D is a high level language that is pre-compiled down to AGAL byte-code. When writing AGAL from ActionScript (with or without the aid of this library) we have the oportunity to dynamically make some decisions about how the shader is written, e.g. whether to include vertex fogging, etc. We can instantly rewrite the shader to include or exclude any number of options. True, PixelBender3D was created as a friendlier alternative to AGAL, but at some cost to efficiency and outright hands-on control.

Others will say, “If you take the time to learn AGAL properly, you’ll be able to read it more easily and you won’t need any of this.” I expect that for many the hurdle of making sense out of the hieroglyphics of AGAL when first meeting the language will prove too much of an obstacle to progress beyond basic tutorials. This library provides training wheels to learning AGAL. I have not reinvented the language, but merely made it much easier to read and write, leveraging the features of our IDE’s. All methods of EasyAGAL and EasierAGAL maintain the same parameters, in the same order, as AGAL opcodes; They are all documented with ASDoc tags providing help for every instruction and every register as you type. The code-hints from EasierAGAL also include the original AGAL opcodes to help you learn them.

Happy Trails

AGAL is not easy, but hopefully this library will make it easier, and assist your learning experience. Here are some excellent links to tutorials and introductions to AGAL and the Molehill API:

My Name is AGAL, and I Come from Adobe by Marco Scabia
Molehill – Getting Started by Mikko Haapoja
Tutorials by Pixelante

Once you’ve explored some of these tutorials and are ready to try your hand at coding some AGAL, please visit the repository for my new open source project EasyAGAL now on GitHub.

(Please open the article to see the flash file or player.)

This was also a chance to get to grips with the new Motion Editor in Flash CS4.  I’ve made that and a CS3 version available for download if you’d like to have a look.

Download the .fla (CS4)
Download the .fla (CS3)

Have a look at www.imageafter.com if you’re looking for more texture images.

As seemingly exhaustive as Adobe’s gigantic article by Jeff Kamerer is, many answers were not to be found there. I wanted to make an SWC-based component that did not rely on the UI Component framework — after all, not every component is a UI gadget! I wanted to write a simple class to draw something to the stage, with a few options I could control with my own control panel and see updated with a live preview right on the stage.

Along the way to a solution, I encountered a host of problems getting the control panel to communicate with the authoring tool, and for the authoring tool to communicate properly with the component and the control panel… and then even with all of those problems cleared up, there was still the problem of parameter settings being retained in the finished compiled product. It seems quite clear that several aspects of component creation do not work as they should–at least not when you add a custom control panel into the mix. However, in spite of all the problems, there is a reasonable workaround to make this possible.

Eventually, after a lot of googling about, and a whole lot of trial and error, I managed to piece together this jigsaw puzzle, and can now present to you a method for creating your very own components with custom control panels, all in Actionscript 3, which works for both Flash CS3 and CS4.  In this article, I’ll give you a tour of the code for a simple component and its control panel, with notes on how to make your own components.

CLICK HERE to download the complete source files.

THE COMPONENT

Defining Parameters

First, let’s take a look at the source code for the component. Open up “MyComponent.as”  …In order to inform Flash what the parameters for this component will be, we have to include [Inspectable] metadata tags in the class code.

 [Inspectable (name = "color", variable = "color", type = "Color", defaultValue = "FF0000")]
 [Inspectable (name = "radius", variable = "radius", type = "Number", defaultValue = "10")]

I’ve placed them right at the top of the class, for easy reference. Both parameters–radius and color–are going to call getter/setters which you’ll find near the end of the file. There are a few important things to notice here:

• The name and variable for each parameter MUST be the same
• All of the parameters MUST be in alphabetical order
• The default values must be set BOTH in the meta-data and the code

Of course these are hardly official requirements for writing a component, and I’m sure there are plenty of components out there that were not written following these rules. However, in order to create this component with a custom user interface in the Component Inspector and with live preview… all three of these rules must be observed.

Note also that the default value for color is represented as a hex string without the leading “#” or “0x”

The setSize() Method

Moving on, the setSize() method is where we handle resizing of the component. The Flash authoring tool will automatically call this function for live preview, so it must be defined as public, and with parameters for width and height.

public function setSize(w:Number, h:Number):void {
	_width = w;
	_height = h;
	draw();
}
 
private function draw():void {
	_background.graphics.clear();
	_background.graphics.beginFill(_color, 1);
	_background.graphics.drawRoundRect(0, 0, _width, _height, _radius, _radius);
	_background.graphics.endFill(); 
 
	_tf.text = Math.floor(_width) + " x " + Math.floor(_height);
	_tf.x = (_width - _tf.width) * 0.5;
	_tf.y = (_height - _tf.height) * 0.5 + 2;
}

Some component source examples I’ve come across have defined a draw() method as protected, with a drawNow() method to provide public access. I have found no requirement for this, except perhaps when working with the UIComponent framework.

Parameter get/set functions

Next, the getter/setter functions for our parameters, color and radius. We need to use getter/setter rather than public properties so that whenever these values change, we can redraw the component.  This will keep the component updated both for live preview and at runtime.

public function get radius():Number { return _radius; }
public function set radius(value:Number):void {
	_radius = value;
	draw();
}
 
public function get color():int { return _color; }
public function set color(value:int):void {
	_color = value;
	draw();
}

Override width and height

Finally, we must override the getter/setter functions for width and height. If we don’t, then when an actionscript call is used to change the dimensions of our component, it would merely be stretched or squashed.  What we want is to redraw the component with the new size.

override public function get width():Number { return _width; }
override public function set width(value:Number):void {
	_width = value;
	draw();
}
 
override public function get height():Number { return _height; }
override public function set height(value:Number):void {
	_height = value;
	draw();
}

Compile and Test

Let’s compile the component and try it out without any custom control panels, just for starters.  Open up “Make a Component.fla”  You’ll find just one library item, a MovieClip called “MyComponent.”  It’s not quite ready to be compiled as it is.  Double-click the item to open it up on the stage.  You’ll find just one object, called “avatar” which the component code will use for default dimensions and as a simple means of setting font format properties as well as embedding the font.  All right let’s compile…

1. In the Library, right click “MyComponent” and click on “Properties”
2. Tick the box: “Export for ActionScript”  Since the class box will have automatically set itself to “MyComponent” it will use our component code.
3. Click OK, and again, right click “MyComponent” in the Library and click on “Component Definition…”
4. As redundant as it is, type “MyComponent” into the Class box here also, and then click OK.
5. Again, right click “MyComponent” in the Library and click on “Component Definition…”

NOTE: The parameters part of this dialog will now show our parameters, radius and color.  Frankly, this dialog was built backwards:  it ought to have filled in the Class from the Properties dialogue, and from that the Parameters.  But that’s not how it works.  What’s more, don’t bother trying to rearrange your parameters using the buttons provided–those changes will be lost.  You see, as soon as you click OK in this dialog, Flash reads in the Class file, searching for meta-data and rebuilds the parameters table…!

6. Tick the box: “Display in Components Panel” and click OK.
7. Now right click “MyComponent” one more time and click on “Export SWC File…”
8. Make a new folder in: “C:\Program Files\Adobe\Adobe Flash CS3\en\Configuration\Components” called “My Components” or “Test Components” or whatever you like.
9. Export the SWC file to this foler.
10. Open up the Components panel (ctrl-F7 / -F7)
11. Click the panel options button (the tiny black triangle in the upper right corner of the panel) and click on “Reload”

NOTE: Whenever you re-compile your SWC file, you must reload the Components panel for Flash to load in the updated version.

12. You should see the name of the folder you created your component in, so open that and you’ll find your new component.
13. Make a new Flash document where we’ll give the component a try out.
14. Drag the MyComponent from the Library panel onto the stage.  You should see something like this:



Tthe avatar has been replaced.  Our component code has been run, right on the stage.

15. With the component selected, click on the Parameters tab of the Properties panel.
16. Try changing the parameter values.  Immediately as you change the values, the component updates itself.
17. Save this file as “Test Component.fla” and we’ll come back to it later.

CUSTOM CONTROL PANEL

Something to keep in mind is that our custom control panel will not communicate directly with the component instance. Rather, the control panel adjusts parameter settings in the authoring tool, and the authoring tool in turn modifies the component instance. The component instance receives information via the setSize() method and property setters, and has no means of its own to communicate with either the authoring tool or the control panel. Keeping our parameters in alphabetical order, rather than trying to arrange them in some logical order, allows us to avoid a minefield of problems.

Reading Parameter Values

Let’s have a look at the source code for our control panel.  Open up “ControlPanel.as”  Once again, right near the top of the file are references to our parameters:

private const PARAMETER_COLOR:String = "fl.getDocumentDOM().selection[0].parameters[0].value";
private const PARAMETER_RADIUS:String = "fl.getDocumentDOM().selection[0].parameters[1].value";

These instructions refer to parts of the Flash authoring tool’s user interface using the JSFL language–specifically, the parameters panel of the selected object.  (See below under Further Reading for more details about JSFL.) Notice that the numbering of the parameters follows the alphabetical order we’ve maintained.  Although it’s not required to set these constants, it makes the rest of the code considerably more readable.

public function ControlPanel() {
 
	color.text = MMExecute(PARAMETER_COLOR);
	if (color.text.substr(0, 1) != "#") color.text = "#" + dec2hex(uint(color.text));
	color.addEventListener(Event.CHANGE, setColorFromText, false, 0, true);
	colorPicker.addEventListener(ColorPickerEvent.CHANGE, setColor, false, 0, true);
 
	radius.text = MMExecute(PARAMETER_RADIUS);
	radius.addEventListener(Event.CHANGE, setRadiusFromText, false, 0, true);
	radiusSlider.addEventListener(SliderEvent.CHANGE, setRadius, false, 0, true);
 
	addEventListener(Event.ENTER_FRAME, setControls, false, 0, true);
}
 
//......................
 
private function setControls(e:Event):void {
	setColorFromText();
	setRadiusFromText();
	removeEventListener(Event.ENTER_FRAME, setControls);
}

In the class constructor function, we read the current control panel values and apply them to our controls.  Using the MMExecute() function (which is made available by importing the package: adobe.utils.MMExecute) allows us to execute our JSFL code defined in those two constants above.

The slider and the color picker components’ default parameter values will be applied right after our control panel is instantiated.  Hence, the code to set those controls had to be called from an ENTER_FRAME event listener, so that it would occur after those components had been initialized.

Setting Parameter Values

Whenever parameters are changed, either with the handy slider & color picker, or with the text fields, setting the parameters in the authoring tool requires another simple call to MMExecute():

MMExecute(PARAMETER_RADIUS + "=" + value);
 
	// Which, assuming value is 20, is equivalent to...
 
MMExecute("fl.getDocumentDOM().selection[0].parameters[1].value = 20");

That’s really there is to it.  The remainder of the ControlPanel.as code works like any other Flash form, updating text and components to work together, and using l to MMExecute() to update the authoring tool. The authoring tool in turn sets variables in our component instance to update the live preview.  Now let’s add this control panel to our component…

Compile the Component with Custom UI

1. Compile the control panel (Shift-F12) creating “Component Control Panel.swf”
2. Now, re-open “Make a Component.fla” and right-click MyComponent in the Library panel, then click “Component Definition…”
3. Across from “Custom UI:” click on the Set button.
4. Select “Custom UI in external .swf file”
   • Select “Display in Component Inspector panel”
   • Assign the Custom UI .swf file by clicking on “Browse…” and selecting ”Component Control Panel.swf” which we just created.
   • Click OK
5. Click OK
6. We’re ready to re-compile the component.  Right-click MyComponent and click on “Export SWC File…” and overwrite the older SWC file we created
7. Update the Component panel by clicking the panel options button (the tiny black triangle in the upper right corner of the panel) and click on “Reload”
8. Re-open your test file: “Test Component.fla”
9. Click and drag the updated component from the Coponents panel, into the Library panel.  You should see the dialog: “One or more library items already exist in the document.”  Select “Replace existing items” to update your test file.
10. Now when you click on a component instance on the stage, the Parameters panel will no longer allow parameters to be set there, but will give you a button to launch the Component Inspector, which is where our control panel will appear.

NOTE: By choosing “Display in Property Inspector” in step 4, you can get your control panel to appear in the Parameters tab.  However, in this example case, the color picker demands more space than is available there.

11. Try making a few variations of the component on stage and compile your test movie.

CONCLUSION

Thanks for reading!  I hope you’ve found this tutorial helpful.  Check out the file “Use the Component.fla” and its base class “UseComponent.as” for various tests which helped me to refine this method and write this tutorial.  There is also an illustration of the one issue, described below, that I have as yet been unable to resolve.  If you should come up with a solution, please be sure to post about it here!

Known Issue:

If I rotate the component on the stage in the authoring tool, its width and height are incorrectly reported as an unrotated bounding box, which will inevitably be larger than the correct dimensions, as shown below:

The selected component shows its correct dimensions as 83 x 17, while the authoring tool shows the incorrect dimensions 70.2 x 70.2.  At runtime, the component is initialized with those incorrect dimensions:

[UPDATE]  A solution to this problem is presented by Juan Carlos in a comment that follows this post.

Further Reading:

Read about the [Inspectable] meta-data tag:
http://livedocs.adobe.com/flex/3/html/help…
http://livedocs.adobe.com/flash/9.0/main/…
It seems this information does pertain to AS3 as compiled by Flash CS3+, but I have never found documentation except as it pertains either to Flex or to AS2.

To find out more about JSFL and what you can do with MMExecute(), take a look at this excellent video by Lee Brimelow about creating panels to extend the Flash IDE:
http://gotoandlearn.com/play?id=66

This reference to extending Flash provides full details of JSFL support in Flash:
http://livedocs.adobe.com/flash/9.0/main/flash_cs3_extending.pdf

…and a tutorial on creating FLA-based components:
http://www.flashbrighton.org/wordpress/?p=31

The problem lies in a small javascript file: brwsniff.js, a handy dandy browser sniffer that checks for the installed Flash Player version number. The bit of code written for non-IE browsers wasn’t expecting a player with a version number of more than one digit; so, seeing only the one’s place digit, if you’ve got Flash Player 10 installed, the script comes up with a version number of ZERO!

Unfortunately, the author of this otherwise delightful script has not updated the file since before Flash Player 10 was released. Having made the minor repair necessary, I’m making my updated version available for download HERE.

Please note: If for some reason you needed this script to detect the browser software in use, I’m afraid you’re still out of luck. The script seems to see everything as either IE or Firefox.

[UPDATE]
Got a message from Pau Garcia i Quiles, author of jsbrwsniff.  He’ll publish a bugfix soon—until he does, download the version posted here.  I’ll announce when an official bug fix becomes available.  New features he’s planning to add in the coming months:

My new portfolio site is finally ready for public viewing. The design of the site is an homage to one of my favorite artists, the Belgian surrealist René Magritte. Even if you’ve never heard the name, you’ve probably seen his most famous image somewhere: A man in a bowler hat, with the sea behind him… and a green apple floating mysteriously right in front of his face. Monsieur Magritte is responsible for numerous iconic images like this one, and in my design of this site (as with the background image for this blog) I’ve created various sorts of references to his style, some spoofs of his most famous paintings… with the addition of animation!

Another point of interest is that this site is the first project I’ve completed using my new Actionscript 3 framework: MORFsite. Although there’s still a fair bit more functionality yet to be added to it before it’s complete, MORFsite already covers these features…

• handles overall site architecture and navigation events
• manages media and data resources
• maintains the visual layout of the site

I still need to integrate SWFaddress and tie up some loose ends. When I do, my plan is to release MORFsite as an open source project.

Anyway, enough babble! Go visit my new portfolio site: http://studio.barliesque.com

[UPDATE] The site was just awarded a PickA Gold Award!  (21 January 2009)

http://www.pv3d.org
http://papervision2.com
http://www.dehash.com/?page_id=202
http://www.flashbookmarks.com/PV3D-Beta2-DOC
http://blog.zupko.info/?cat=8
http://www.madvertices.com

…and here’s a little 3D experiment I’ve been tinkering with as I learn how to use this exciting library:

(Please open the article to see the flash file or player.)

I’ll post some source code eventually for PV3D experiments soon… 

A tiny object being masked by a huge shape will cause getBounds() to return the extents of… the mask, not the visible object.  It gets even better if your object happens to move beyond the masked area–thus making it totally invisible.  Now getBounds() exapands to include the area of the giant mask plus that of the tiny object, which is no longer being drawn to the screen at all.

In fact, there appears to be no built-in method for reliably determining the actual screen area a MovieClip is occupying.  Do we call this a bug, or was it really meant to work this way???

I decided to try writing a handy dandy function to remedy this problem, and in so doing discovered another serious limitation involving masks.  When you create an arrangement of layers in the Flash IDE with, let’s say three or four objects being masked by one mask, you’ve done something that apparently is only possible with the Flash IDE, and not with AS3.  If you have a look at the .mask property of each of those masked objects, they’ll all be set to NULL.  There’s no sign of any masking going on, as far as ActionScript is concerned.  Suppose you manually set the .mask property of one of those three or four masked objects?  The result is that all the other objects will be unmasked.  Using the .mask property strictly pairs one mask to one display object.  So now you’ve got to find a way of duplicating your mask, so each object has its own mask…! 

Well, nonetheless I wrote my own routine: getVisibility() which reliably tracks down whatever is actually visible, and nothing more.  It’s reliable, that is, as long as you manually set your masks in code–one mask for each object.  If a better solution exists, I’d like to know about it.  For now, here’s a little demo of my function versus AS3′s native functions…

(Please open the article to see the flash file or player.)

There’s only one error I can detect in the result of getVisibility() …When objects are rotated, their visibility is based upon a rotated bounding box, rather than the precise shape of the object.  Still, this gets us considerably closer to a solution.

The .fla can be downloaded HERE.  Here’s the code for my getVisibility() function…

function getVisibility(obj:DisplayObject):Rectangle {
 
	var vis:Rectangle;
 
	if (obj.parent == null) return new Rectangle();
 
	if (obj is DisplayObjectContainer) {
		vis = getChildVisibility(obj, obj.parent);
	} else {
		vis = obj.getBounds(obj.parent);
	}
 
	// Is the DisplayObject masked?
	if (obj.mask != null) {
		vis = vis.intersection(obj.mask.getBounds(obj.parent));
	}
 
	// Is the DisplayObject partly or completely off-stage?
	vis = vis.intersection(obj.stage.getBounds(obj.parent));
 
	return vis;
}
 
function getChildVisibility(obj:*, target:DisplayObjectContainer):Rectangle {
 
	var vis:Rectangle = new Rectangle();
	var child:DisplayObject;
	var childRect:Rectangle;
	var i:uint;
 
	for (i = 1; i <= obj.numChildren; i++) {
		child = obj.getChildAt(i-1);
 
		if (child != null) {
			if (child.visible) {
				if (child is DisplayObjectContainer) {
					childRect = getChildVisibility(child, target);
				} else {
					childRect = child.getBounds(target);
				}
				if (child.mask != null) {
					childRect = childRect.intersection(child.mask.getBounds(target));
				}
				vis = vis.union(childRect);
			}
		}
	}
	return vis;
}

All these years of designing and developing and I’ve never had a blog to call my own.  The shame of it!  Well, through the magic of WordPress I’ve finally rectified this. Thanks also go to TheBuckmaker for the Aeros theme, to which I’ve added my own Magritte-inspired background image and a few minor modifications.

I’ll be posting about my travails with Adobe Flash and ActionScript3 in particular, but who knows what else may find its way onto this blog?

Sometime soon, I plan to release a proper announcement of my AS3 framework, MORFsite.  At present, I’m using it to complete a new website for myself–finally an up-to-date portfolio!  I’ll post about MORFsite soon, which I plan to release as an OpenSource project.  But not until it’s had a chance to mature with a couple of real live projects.

Well… on with the blog!