Synja Dev Blog

Well I haven’t posted in a while, and that’s because I’ve been busy at work learning Pixel Benders and doing some experimentation. I wrote my first Pixel Bender which I’m calling RGBDistortion. It basically diffracts the R G and B channels from an image and then runs them through a simple sine wave transposition. The end result is a cool effect that reminds me of an old school analog TV with bad reception and bad guns.

Please note I added a standard GlowFilter to it with the following constructor: (0xffffff,1,40,10,4,1). It makes it look a lot nicer.

I have also released the source code to the Pixel Bender so the community can play around with it. I hope it makes it into some cool Flash stuff

RGB Distortion Pixel Bender Kernel

If you have any suggestions or performance improvement tips, let me know. My next step is going to be adding an “interlacing” effect to really make it grungy and analog looking.

So you just finish your awesome Flex app and unleash it into the wild. It’s great, except for an annoying blue flash that happens before the movie renders. Despite setting the background color to many things when embedding your SWF, it still flashes blue. It only happens in some browsers, but it’s enough to be a total eyesore.

This is because Flex has a “default background color” that it likes to present to the user before any rendering is done. The busier the web page, the more noticeable this flash is.

You’d think Flex would offer an easy way to access this property and change it, but it doesn’t (at least as far as I know). What you can do however, is change the color using a compiler option. I know, compiler options are the bandaid for every annoying thing with Flex these days, but at least they are available.

-default-background-color=0xffffff

This will change the color to white. I would make this color whatever value your most common backgrounds are that your SWF goes on top of. You could probably sidestep this with using wmode=”transparent” but that’s a rather drastic measure to take for just fixing an annoyance such as this.

A little known feature of AS3 is the ability to not only list an object’s properties but their values as well. They expose this functionality in a really weird way though. Both the for and for each key words yield different results. As a rule of thumb I would suggest always using for because it gives you not only the properties of the dynamic object, but also the values:

var obj:Object = new Object();
obj.foo = "bar";
obj.hello = "goodbye";

for(var key:* in obj)
{
     trace(key + ": " + obj[key]);
}
// Output:
// foo: bar
// hello: goodbye

for each(var value:* in obj)
{
    trace(value + ": " + obj[value]);
}
// Output:
// bar: undefined
// goodbye: undefined

You’ll notice that the first keyword usage, just the for, populates the property name into the iterator “key” , so you can access the property using the Array notation. The second keyword, for each populates the iterator “value” with the value of the properties. Hardly useful when you are serializing a dynamic object and would like to know what property the value belongs to!

So I would suggest always using for unless you really want to use for each for a specific reason.

I’m pleased to announce my latest Flash endeavor has gone live. I have built Current’s new embeddable video player in Actionscript 3.0, using Flex Builder 3 and Flash CS3:

It’s taken me about a month of nonstop development and I’ve been very pleased with the results. You can check out more info from Mario Anima’s great post over at the official Current.com Blog.

There are still some kinks to work out, but nothing major. This is definitely the most highly visible project I’ve done for the internet so I was a little nervous letting it out but so far the feedback’s been great.

If anyone has any questions on how I accomplished any specific aspect of the player, feel free to comment here and I will gladly share any advice.

We’ve had an issue with Facebook where our video player embeds were broken for IE users. I could tell right away that our FlashVars were not being parsed into the player, and couldn’t figure out why.

Eventually I tested to see if circumventing our HTTP redirect (which translates our friendly URL format to a long complicated one with many query string vars) would fix the issue. Sho’ nuff, it did. Once I realized the redirect was involved I did some Googling and came across this post by Mark Ledford about IE trying to parse query strings from redirects when using the <embed> tag. Simply put, it can’t.

This bug, which only occurs in IE when using an <embed> tag to load a SWF through HTTP redirect, effectively strips the query string values and precludes them from ever becoming FlashVars.

The solution (are you listening, Facebook?) is to wrap all your <embed> tags in <object> tags. As much as we’d like to get rid of the <object> tag, the time is not right, especially in the age of widgets. For sites like Facebook to ignore this bug would pretty much cut off any widget provider from using HTTP redirects for their widgets, forcing them to stuff all of their configuration parameters into their public-facing URL. Or they could simply ignore everyone who falls into the blue portion of this graph:

It turns out there’s a straight up BUG in IE. When ExternalInterface checks to see if allowScriptAccess is on (via same domain or always), the “available” property returns true, even if access is NOT allowed. This will fool any SWF into thinking it’s allowed to use the ExternalInterface even when it can’t, thus throwing an exception if it’s attempted.

So sadly, not only must you use ExternalInterface.available, you also have to wrap it in a try/catch.

If anyone can tell me why IE behaves this way, I’m all ears.

IE7 and IE8 both have serious issues with regard to <object> based embedding of Flash when utilizing the ExternalInterface.addCallback function. When embedding a SWF using this method, you may (and probably will) run into issues when leaving or reloading the page, which will throw up an “Object doesn’t support this property or method” error. This error will pop up for every single ExternalInterface.addCallback you add in your code.

This is happening because the “id” and “type” tags are probably not defined in your <object> code. Here are some examples:

This will throw an error when trying to unload the SWF:

<object height=”400″ width=”300″> … embed code here … </object>

This will not throw an error:

<object height=”400″ width=”300″ id=”current_embed” type=”application/x-shockwave-flash”> … embed code here … </object>

But what if you made an awesome widget already, and there’s a billion people already embedding it with the old code? That’s exactly what happened to us at Current, so the only fix that works for us must come from within the Flash (because we have the ability to replace it for everyone). To fix this we had to find the root of why IE was failing, and it was doing so because it was trying to map the external interface calls using the HTML defined ID, rather than an internally generated one (which I presume is how all other browsers do it). You will have a hard time controlling a SWF through Javascript if it doesn’t have an ID anyways, so I think MS assumed that anyone who used ExternalInterface.addCallback would also be defining an ID for it.

Luckily, Actionscript has a little known property in it’s ExternalInterface object called objectID. If the <object> is not declared correctly, this property will be null. So the solution is quite simple, check to see if it’s null before adding any callbacks. The code looks like this (AS3):

if(ExternalInterface.available&&ExternalInterface.objectID!=null)

{

ExternalInterface.addCallback(”myFunc”,_myFunc);

}

This will fix the issue, however please note that you won’t actually have any methods available to you in your Javascript code if you were identifying it through the name attribute instead.

Yet another crappy thing to deal with in IE.

Say you have a Flex project with a reference to a SWC that you are working with in Flash. This is a common scenario as Flash is the best place to visually organize graphic elements into a single spot for inclusion into a final build of your Flash or AIR project.

You also have a bunch of images in the SWC that you’d like to instantiate without creating wrapper MovieClips for them. A simple strategy would be the following:

1. Link all your images to their own class names in Flash using the “Linkage” menu option and publish the SWC.
2. Attach the SWC to your Flex project
3. Instantiate the classes when you want to using the getDefinitionByName utility function.

Sounds straight forward and simple, right? Unfortunately it’s not the case. Adobe has a couple “Features” baked in that cause a lot of headaches when trying to access these classes dynamically.

SWC Classes (including Bitmap assets) Do Not Get Embedded Automatically Into Your Project

The first problem is that Adobe will not compile any of your library objects that are exported for Actionscript unless you specifically name them inside your Actionscript. This creates unnecessary clutter in your code and wastes resources during runtime because you have to instantiate objects that you very well may never even need to use, simply so Flash can find the class it wants. There are some really weird solutions on the web trying to solve this problem, but the most simplest one is the addition of the “-include-libraries” directive in your compiler options:

-include-libraries “/absolute/path/to/my/assets/assets.swc”

This will force the compiler to include every single linked object, without the need of creating dummy instances (and other such nonsense).

We aren’t out of the woods yet, though.

BitmapData Objects Require 2 Parameters in it’s Constructor … Parameters You Don’t Know The Values For!

Once you have a reference to your bitmap asset’s class, trying to instantiate it will look theoretically impossible. It requires a width and height to be instantiated, but you don’t know these dimensions. The whole point of dynamically loading a class is to take care of all this at runtime, not prior to compiling, so the class is more or less asking you for information that it itself knows but you don’t. Kind of screwy but there’s an easy fix:

var MyCustomBitmapClass:Class = getDefinitionByName("MyCustomBitmapClassNameFromSWC") as Class;
var myUsableBitmap:Bitmap = new Bitmap(new MyCustomBitmapClass(0,0));

Even though we’re passing 0s, the BitmapData class knows to ignore them and instead use its actual image data dimensions. I’m not sure if this is a documented caveat with Adobe, but it works and I’m not complaining.

A quick little note, if you want to pass anonymous functions as parameters as well as regular function pointers, there is a small difference in their Qualified classnames. An anonymous function is not considered a real function but rather a “method closure” and has an internalized classname:

function detectFunctionType (obj:Object)
{
   trace(getQualifiedClassName(obj));
}

detectFunctionType(detectFunctionType);
detectFunctionType(function () {  // This is an anonymous function });

And your output is:

Function
builtin.as$0::MethodClosure

Just something to keep in mind when passing function pointers. In general usage you may want to support both anonymous functions along with declarative ones, so if you are using getQualifiedClassName in your code when working with callbacks, you should accept both of them.