Ok small break from work, to post some other stuff.

Here is a detail from a painting I’ve been working on. It’s soo far from finished that it’s depressing but anyway

The skintones are coming along quite nicely, but they are still way too cold. The chestpiece and tattoo are done for now, so next up are the shoulders, hair and face. I think I’m going to especially enjoy the long hair, or scream in frustration, painting hair can do that to you

Also known as:

In ActionScript 2, we had a _global object. Although this opened a world of gruelsome possibilities, it had it’s uses as well. For example it allowed to create reflection mechanism by traversing the package tree and unobtrusive logging by attaching your logger to the _global.log hook.

This prevented you from having to import your logger everywhere and allowed you to easily switch to other loggers, or disable the current one.

Although I do not find many uses for a _global object, this logging feature is one of them, and I expect that for some developers, the ability to store properties all over the place is a nice-to-have as well, although I strongly advise against that:).

In addition, when you are using traces, your traces will not show up in the release player. If you are using FlashDevelop like me, you can redirect to traces to FlashConnect however.

A simple trick you can employ is something like this:

Enjoy the abuse

You can log, without having to import any classes, and change the logging functionality on the fly whenever you wish!

Also known as:

• keeping your sources out of the injection swf
• decoupling your main class from your injection swf

Ok you probably are not going to run into this situation a lot, but I decided to post it anyway. If you develop a lot of big applications in ActionScript 2 YOU SHOULD MOVE ON TO AS3… err… what I meant to say was: if you do, chances are you are developing your apps in FlashDevelop. In a lot of cases this means you are using an injection swf.

This injection swf contains all your assets. There are two options to start your program once it’s loaded:

• tell MTASC to execute your main class once all classes are initialized
• call your main class method from the swf once everything is loaded

Note that these two points might not be the same. We’ve been using a simple fla template which contains a preloader etc, and has its classes exported at frame 20 and its main application function called at frame 40. Although you might argue that an external preloader should have been used and the main fla should only have been 1 frame, that offers new problems, and anyway that is not what this post is about.

Telling MTASC to execute the main class once all classes are initialized will cause initialization to occur at frame 20, using a call on frame 40 of the timeline will cause the application to be initialized at… yes frame 40.

Another difference is that using the MTASC main class option, causes your class file to be excluded during compilation of the injection swf (which is good), using a class hook causes them to be compiled in the injection swf (which is bad).

When the classes of your application are already compiled in the injection SWF, you will run into problems when refactoring the classes, and forget to recompile the injection swf. If you use the MTASC keep flag, all your classes will be removed, which is probably not what you want if you are using v2 components in the SWF.

So the simplest option is not to use:
com.mydomain.client.MainApplication.main (this);

But to use:
_global.com.mydomain.client.MainApplication.main (this);

When you tell FlashDevelop to include your main class, the class will be injected in the injection swf during compilation, so _global.com.mydomain.client.MainApplication.main (this); will call an existing method and your swf will run just fine. On the other hand _global.com.mydomain.client.MainApplication.main (this); will not cause any application classes to be included in your injection swf during export, which is good too.

So almost there, the only thing that’s not so good about this is that the injection swf still has knowledge about your application’s main class, since it’s right there in the _global.com..etc statement.

To fix that you can replace:

_global.com.mydomain.client.MainApplication.main (this);

with

_global.hook(this);

and include this code in your main class:

Just compiling the main class into your swf will cause the _global.hook to be set, and calling it will cause your MainClass’s main function to be called.

Spiffy ain’t it ?

I just came back from an awesome trip to London, where I was visiting my good friend Patrick and his lovely girlfriend Rosa. Almost a year ago he got a trip to the studio from her as a birthday gift, and I was very lucky to be invited to join them. After leaving here on thursday afternoon around 5 pm, I finally arrived somewhere between 12 and 1 UK time, just in time for a good night’s sleep. Next day was full of good food, cold beer and lots of practice, and yes the more I screamed the less my vocal cords hurt ( or maybe it is ‘the more I drank’, but that part is a bit hazy ). So we ended the day looking forward to the actual studio recording, although we might have been just a tad nervous.

The next day Patrick and me went to the studio first, and Rosa and Iris (a good friend of hers from Finland) joined us later, cheering us on ( thanks for your support ladies ). To make a long story short, it rocked. The song came out more than acceptable, which is more than 2 guys without any real studio experience, who had only been able to rehearse for about a day, can hope for. I’m sure there’s lots of room for improvement, but that’s not the point. What’s more important that even while we didn’t get that much sleep (sorry my fault, even though I’d been drinking until 3, I’m still programmed to wake up at 7 arghgh), I came back home full of energy feeling like practising a lot again, drawing stuff etc etc.

Since I remember promising somewhere in the first posts on this blog that I wouldn’t post too much personal stuff, I’m not going to tell you that the four of us had a very nice and relaxing afternoon/evening after the recording, having dinner and drinks in the pub, nor that I bought some very cool heavy metal T-shirts the next day in Camden for me and my sons to take back home.

Anyway, all good things come to an end, as did this trip, and so I had to leave on Sunday, and I was back home again somewhere round 0:00 Amsterdam time welcomed by the three sleeping loves of my life, right on time for work on monday, and back behind the pc to post the results for your enjoyment .

First some photos:

And ofcourse the track we recorded, a song called ‘watch over you’ from Alter Bridge, one of the coolest bands at this moment:

If you are thinking about posting something saying we’re out of tune, don’t bother, we don’t care it can always be worse

Although there are different plugins out there to help you display your code, there is a very simple solution as well. It does not provide code colouring, linenumbers and all that, but it does create a nice readable non-overflowing area to display your code.

Simply put this in your style.css:

div.codewrapper {
border: 1px solid #DDD;
max-height:200px;
overflow:auto;
width:450px;
height: expression(this.scrollHeight > 200 ? “200px” : “auto”);
white-space:pre;
line-height: 100%;
font-family: Verdana, Arial, Sans-Serif;
font-size:10px;

}

Now if you create a div with class codewrapper, it will look like this:

I was looking for a way to trace the name of the current function or the calling function and I came up with a hackish bit of code.
Don’t know if anyone already came up with something like this but anyway, I thought it was pretty cool so I’d like to share it with the world. I’m still working on making it more general, and you should take care using it in a production environment (unless the compiler directive is set to false).

Usage:
- define a compiler directive and set it to true or false (can be optimized)

Example:

Prints:

If you use DebugUtil.getCallingInfo(”here”, false) the source line is omited.

In the next version that will be a global flag as well.

I’m not sure what happens in other languages, you might need to replace \tat with \t

Have fun!
JC

ps to use this in FlashDevelop goto Project->Properties->Compiler Options->Additional Compiler Options:
and add -define=CONFIG::EXTENDED_INFO_ON,true

ps2 in the Flash IDE, goto publish settings->actionscript settings->Config Constants and enter CONFIG::EXTENDED_INFO_ON
In addition you can omit traces in the IDE, but you can’t in FlashDevelop

ps3 you’ll need to run your swf in the debug player!!

Also known as:

• alternative localization method
• grabbing bitmap data from a loaded swf in actionscript 2
• linkageExportForAS in JSFL not working for bitmaps

For Heineken, one of TriMM’s clients, I had to work on a project called the photomodule. Originally written by Paul de Jong, it required some adaptions for another site. One of the adaptions was that the module had to be running in different languages, Portugese, English & Thai (and maybe even more I don’t know).

You can watch it here by the way. Note that all the texts are localized.

Since there was little time to complete the project, I didn’t want to get involved in playing with thai fonts and embedding the right glyphs. Originally the solution was to include every screen twice, once in English and once in Thai. However that wasn’t really going to work as well, since I needed it for 2 or 3 other languages, and I wanted to simplify/refactor the setup in order to get acqainted with it.

So I came up with an idea: I would create a large jpg with all the button skins in it, and just load that skin. Then in Flash I’d have a couple component cutting the bitmap data out of the jpg. Well it turned out that most of the buttons were already available as separate images, and creating a large skin jpg was only going to be more work.

So: external swf, lots of images in it with correct identifier. Brilliant, only there is no way to get to that data except from within that swf. Since in order to get the bitmap data, I have to pass a linkage id, and that won’t work outside the swf.

However before I tell you how to cross that bridge, I hate doing things that can be automated. For example, right clicking 30 button images, and enabling ‘export for actionscript’ and ‘export in first frame’, which is the first step required if we ever want to be able to get to this data dynamically. So you think: well I’ll be damned, I’ve got JSFL up my sleeve. AHAHAHAHA! Gotcha! Macromedia/Adobe has another bug up their sleeve! Which is that you cannot change these properties for a bitmap through JSFL.

So first step is to write a script that wraps all the bitmaps in a movieclip, and enables ‘export for actionscript’ and ‘export in first frame’ for those clips. First problem solved. Now the trick to get to the bitmap data is to create a clip within the swf that contains the images and attach a helper class to it, for example BitmapLoaderHelper.

This class contains the following:

class BitmapLoaderHelper extends MovieClip  {

	public function loadBitmap (linkageID:String):BitmapData {
		var tmp:MovieClip = attachMovie (linkageID, "tmp", 0);
		var bmp:BitmapData = new BitmapData (tmp._width, tmp._height, true);
		//draw the image
		bmp.draw (tmp, new Matrix(), null, "normal");
		//copy the alpha channel
		bmp.draw (tmp, new Matrix(), null, "alpha");
		tmp.removeMovieClip();
		return bmp;
	}
}

So from your main swf, the process for getting to the BitmapData becomes very simple:

In our case we wrapped this whole thing up in a SkinFactory and SkinnedButtonComponents, which included automatic image retrieval for rollovers etc.

And here is the JSFL I used:

var dom = fl.getDocumentDOM();
var lib = dom.library;
var items = lib.items;
var item;
var newSel = [];

for (var i=0; i<items.length; i++) {
 item = items[i];
 if (item.itemType == "movie clip")  {
  fl.trace ("deleting "+item.name);
  lib.deleteItem (item.name);
 }
}

for (var i=0; i<items.length; i++) {
 item = items[i];
 if (item.itemType == "bitmap")  {

  fl.trace ("Processing "+item.name);
  item.compressionType = "lossless";
  item.allowSmoothing = true;

  var newName = item.name.substring (0, item.name.indexOf("."));
  fl.trace ("Creating wrapper clip with name:"+newName);

  lib.addNewItem( "movie clip", newName);
  lib.editItem( newName );

  var tl = dom.getTimeline();
  tl.layers[0].name = "Wrapped Bitmap";
  lib.addItemToDocument( {x:0, y:0}, item.name );

  newSel[0] = tl.layers[ 0 ].frames[ 0 ].elements[ 0 ];
  dom.selectNone();
  dom.selection = newSel;
  var mat = dom.selection[0].matrix;
  mat.tx = 0;
  mat.ty = 0;
  dom.selection[0].matrix = mat;
  dom.selectNone();
  dom.exitEditMode();

  lib.selectItem (newName, true);
  lib.setItemProperty( "linkageExportForAS", true);
  lib.setItemProperty( "linkageExportInFirstFrame", true);
 }
}

lib.addNewItem ("movie clip", "BitmapLoaderHelper");
lib.selectItem ("BitmapLoaderHelper", true);
lib.setItemProperty( "linkageExportForAS", true);
lib.setItemProperty( "linkageExportInFirstFrame", true);
lib.setItemProperty( "linkageClassName", "!replacethiswithyourpackage!.BitmapLoaderHelper");

Also known as: losing your _root reference during asynchronous calls.

I was browsing through my drafts today, since I haven’t written anything in god knows how long, and I happily started deleting everything not having anything todo with AS3, since I finally moved on. But then I ran into some posts that I thought are still worth writing about, so I’ll try to post something every couple of days for the next couple weeks, to get rid of that backlog.

For today, the _lockroot of all evil!

If you don’t know what _lockroot is, stop reading now!

Really you should stop reading now…

I’m sure we’ve all heard (all us actionscript programmers that is), that you shouldn’t rely on _lockroot. I’m sure most of us have violated that rule too one time or another, until we finally found a framework that solves it (but that’s another story).

So why shouldn’t we use _lockroot?

Well there are a couple of things I’d like to share. I think that using _lockroot from movieclip classes, although it might not be a good thing, is not necessarily problematic, at least I haven’t run into any bugs doing that, but maybe you have.

The real problem is that _lockroot seems to make it easy to access the _root for your subapplication even from non movieclip classes. Although this may seem to work correct, I’ve noticed on several occasions that _root in that case does not point to the _root of your swf, but to the _root of the swf that loaded the class you are referencing _root from (still with me?).

Another subtle bug which I have encountered twice, with no way to reproduce in a cleanroom setting, is that _root resets itself from the subswf root to the parent root during an asynchronous to for example a webservice.

For example:

trace (_root); //_level0.mysubswf
//do webservice call here and execute onResult

onResult () {
trace (_root); //traces _level0
}

So conclusion: if you do use _lockroot, do not use it from non movieclip classes.

Any solutions?

Well if we stay in the realm of easy hacking, you might want to create a global table storing your roots under an identifier. If you want a more solid approach, in our framework, each application and subapplication extends Application, which has a getTimeline() method.
The applications are registered in an ApplicationRegistry, and you can retrieve their instances by passing in a class reference. So to retrieve the root for my sub application I might do:

Application (Application.getRootApplication().getRegistree(com.objectpainters.SubApplication)).getTimeline();

I have never needed to yet though, and if I had I’d probably wrap it, cache it or whatever.

So play with _lockroot in as2 all you want, but keep this possibility of hard to track, incredibly nasty bugs in the back of your head.

I’m currently working on a project where I’m using a bit of reflection, and although I found a couple of reflection classes on the web, I was looking for something that worked out of the box without too much hassle.

Basically I was looking for something that allowed me to do new Reflection(myClip) and be done with it 9 times out of 10.
Making a reflection is not that hard (although I need to work on the alpha and falloff, will post a new version later), but getting it to work right with scaled clips with weird registration points was a little harder.

Anyway I think I came up with something nice, and it performs quite well. You can download the source and a bunch of demo’s here Reflection demo’s

Here is a list of features:

A couple samples:

The code:

A couple of screenshots of the other demo’s:

Also known as:

One of current projects involves some texteffects and I am loath to do anything on the timeline that can be done quicker by code. So my basic idea was (keeping the designer in me happy):

Doing the design stuff at design time on stage:

Doing the animate stuff at runtime through code:

At this point I was already thinking about converting the stage textfields to bitmaps but found I was thinking about optimising things too early, so back to KISS, basic principles first.

Silly me, I thought it would be easy in actionscript 2 to get the position of a character in a dynamic textfield. As in:

textfield.getCoordsOfChar (pIndex:Number)

but apparently no such thing exists. Ofcourse if you have a monospaced font, there are other ways to accomplish this, but this solution works for both monospaced and other fonts.

Although in actionscript 3 there is something like getCharIndexAtPoint, that is not quite what I needed.

Using a trick I managed to implement it in actionscript 2. Note that this is still under development, being researched etc, so it’s not a general I-will-work-everytime-approach. Anyway the basic principle is this:

• apply first the white textformat to everything, then applying the black textformat to the range (i, i+1)
  (basically in every iteration of the loop you set everything to white except the character whose position you are looking for)
• copy the textfield to the bitmap
• perform a getColorBoundsRect on the bitmap and voila an approximation of the character position

And I say approximation since it’s seems to be off by a couple of pixels, but close enough to be usuable. In addition large amounts of text will slow down the process considerably and small font sizes wreak havoc, but it’s good enough:

Download the prototype here, it includes the Greensock Tween classes, but you can use anything you like.