I’ve run into a bug with the released version of the Adobe Flex 4.5 SDK. The 4.5 version of the SDK does not respect keeping [Embed] metadata in your SWF. This is problematic because we use this metadata extensively in PushButton Engine.

Take the following example into account:

TestMetadata.as

package
{
    import flash.display.Sprite;
    import flash.utils.describeType;
 
    public class TestMetadata extends Sprite
    {
        public function TestMetadata()
        {
            var typeInfo:XML = describeType(TestClassWithEmbed);
            trace(typeInfo);
        }
    }
}

TestClassWithEmbed.as

package
{
    public class TestClassWithEmbed
    {
        [Embed(source="assets/flip.png", mimeType="image/png" )]
        public var Flip:Class;
 
        [SomeMeta(source="assets/flip.png", mimeType="image/png")]
        public var Test:Class;
    }
}

In version 4.1 of the Adobe Flex SDK, we get the following back from describeType.

<variable name="Test" type="Class">
  <metadata name="SomeMeta">
    <arg key="source" value="assets/flip.png"/>
    <arg key="mimeType" value="image/png"/>
  </metadata>
  <metadata name="__go_to_definition_help">
    <arg key="file" value="/projects/zaalabs/workspace/TestMetadata/src/TestClassWithEmbed.as"/>
    <arg key="pos" value="243"/>
  </metadata>
</variable>
<variable name="Flip" type="Class">
  <metadata name="Embed">
    <arg key="source" value="assets/flip.png"/>
    <arg key="mimeType" value="image/png"/>
  </metadata>
  <metadata name="__go_to_definition_help">
    <arg key="file" value="/projects/zaalabs/workspace/TestMetadata/src/TestClassWithEmbed.as"/>
    <arg key="pos" value="136"/>
  </metadata>
</variable>

However, in version 4.5 of the Adobe Flex SDK, you can see the Embed metadata is being omitted. Same exact code, same compiler arguments, nothing has changed except the SDK.

<variable name="Test" type="Class">
  <metadata name="SomeMeta">
    <arg key="source" value="assets/flip.png"/>
    <arg key="mimeType" value="image/png"/>
  </metadata>
  <metadata name="__go_to_definition_help">
    <arg key="pos" value="243"/>
  </metadata>
</variable>
<variable name="Flip" type="Class">
  <metadata name="__go_to_definition_help">
    <arg key="pos" value="136"/>
  </metadata>
</variable>

As you can see, the Embed metadata is being stripped out, even though I explicitly set “–keep-as3-metadata+=Embed,SomeMeta” in the compiler. Since I don’t believe that the Adobe Flash Player team would break describeType in a minor release, I’m led to believe that this is a bug that was introduced in the 4.5 version of mxmlc in the Flex SDK.

Rant

:: UPDATE ::

This seems to have been an isolated incident on this specific day, bugs.adobe.com has worked well for me many times since then.

————————————————————————–

So I tried to do the “correct” thing and file this as a bug on bugs.adobe.com. And would happily do so if the site worked. In fact, in the time I’ve been waiting for bug.adobe.com to load and let me login… not only did I write the test case, but I wrote this entire blog post as well.

[UPDATE]
I was finally able to file the bug, I think… it won’t pull it up. SDK-30485.

10 minutes to diagnose the issue…
15 minutes to blog about it…
45 minutes… and counting to file a bug through the proper channels.

Can I grab a version number from the app-descriptor via ant and add that to the AIR filename? Anyone know?

This is a pretty straight forward thing to do using Ant-Contrib tasks, that are publicly available.

You can download the example files –> here.

Let’s take a quick look at the ANT script.

<project name="PopulateVersion" default="populateVersion" basedir=".">
 
  <taskdef resource="net/sf/antcontrib/antcontrib.properties">
      <classpath>
          <pathelement location="./ant-contrib.jar"/>
      </classpath>
  </taskdef>
 
  <property name="app.descriptor" value="air-app.xml" />
 
  <target name="populateVersion">
 
    <echo message="Parsing application.version from ${app.descriptor}"/>
    <xmlproperty file="${app.descriptor}" prefix="airApp.appdescriptor"/>
    <propertycopy property="versionNumber" 
                  from="airApp.appdescriptor.application.versionNumber" 
                  override="true" />
    <echo message="Parsed application version: ${versionNumber}"/>  
 
    <propertyregex property="fileVersionNumber"
                  input="${versionNumber}"
                  regexp="\."
                  replace="_"
                  casesensitive="false" />
 
    <echo>Version Number: ${versionNumber}</echo>                    
    <echo>File Version Number: ${fileVersionNumber}</echo>
  </target>
 
</project>

As you can see it’s very straight forward to parse the version number out of the Application Descriptor. The only other thing we do is us RegEx to change the periods in the version number to underscores to make for more friendly file names.

Using the same concept it is very easy to also populate a Version file that gets compiled into your application which can include build numbers, or other interesting things… but we’ll save that for another day.

My talk was titled, Searching for Adam Savage, and was based around a research project that I conducted called Seeker. The basic premise is this:

Modern cell phones frequently include a camera and a GPS. Even if a GPS is not included, cell phone towers can be used to establish the location of the phone. Image formats include special headers that can be used to store this information, so called EXIF tags. In this talk, I described the process that was used to find the information that many consumers (including celebrities) unknowingly broadcast out on the internet.

The article that resulted from my research can be found over at ZaaLabs.

During the presentation one of my slides was missing, somehow creating the slides in Apple Keynote and then converting them to PowerPoint caused some issues.

So here is the slide that was missing.

Also, Ben Huh of Cheezburger Network wants everyone to know that they are hiring.

One of the really cool features that PushButton Engine has is the ability to use XML to define your entities and templates, and how to wire all of the components together. It looks very much like MXML… (side-note: changing the level files to be compiled MXML is a feature we’ve discussed heavily and are considering doing in the future) which I think is causing a lot of confusion.

We get asked multiple times a week how to define a main menu, a high score screen, a tutorial screen, the list goes on and on… using PushButton Engine. The answer is… you don’t.

Terminology

So let’s get some terminology out of the way, for purposes of this blog post, I’m going to call menus, tutorials, and everything in that bucket… the User Interface (or UI). I’m also going to use the term Game Simulation, we’ll get to that in a moment.

What better way to explain these two concepts than to do so with some examples.

User Interface

Here is an example of UI in a game that we’re currently working on at ZaaLabs along with PushButton Labs:

This is the main menu to Grunts Skirmish. There isn’t a single piece of PushButton Engine here on this screen… in fact… it’s 100% Flex 3… even using mx:State and mx:Transition. Everything on here is UI.

Game Simulation

The Game Simulation is the actual rendering of the game, it’s what you play. You don’t “play” the menu system.

Here is an example once you get into the playable part of Grunts… this is the Game Simulation:

The Game Simulation is where we make use of PushButton Engine… animations via sprite sheets, process manager, renderers, scenes, components, entities, etc… all of the good stuff that PushButton Engine has to offer.

Putting it all together

Now… this doesn’t mean that you are limited to one or the other… the two work together to make your final game. Using Grunts Skirmish again as an example… you’ll notice that we actually have UI elements layered on top of the Game Simulation.

As you can see… both pieces are needed to make a successful game.

Just remember… PushButton Engine is a framework for building simulations.

When you need help building your User Interface… there are tons and tons of UI Frameworks out there… for Grunts Skirmish we used Flex 3.

Here are a few of my favorites UI libraries:

• Adobe Flex SDK
• Minimal Comps
• Flight XD
• Reflex

Exception

There are always exceptions… perhaps you want to build a menu system that plays like a game. A fantastic example of this is Fancy Pants Adventures.

Here is the menu system for the game.

Conclusion

As you can see with Fancy Pants Adventures you’re playing the menu. If you’re not playing… it’s probably not a simulation… this is ultimately the biggest difference between User Interface and Game Simulation.

For more information on using Flex with Pushbutton Engine, checkout my Flexible Games Video over on ZaaTV. The beginning is more of a PushButton Engine overview… skip towards the end for information on FlexSceneView and integrating the simulation with Flex UI Components.

For example, here is Eden pulling a screen capture from HanClinto’s Platformer Starter Kit.

Really cool! However, I quickly ran into an issue when I tried to take a screen capture of a more basic game.

On the right is the game running in Flash, and on the left is the screen capture.

As you can see, my screen capture doesn’t include the green background. So what happened?

Well it turns out the background color of a SWF isn’t actually part of the stage. The background color that you set using the SWF Metadata tag, or set in Flash Professional is drawn directly by Flash Player.

package
{	
	import flash.display.Sprite;
 
	[SWF(backgroundColor="0x00FF00")] // <--- How can I get this programmatically?
	public class SwfBackgroundExample extends Sprite
	{
		public function SwfBackgroundExample()
		{
		}
	}
}

So I had a dilemma… how could I access the backgroundColor of the SWF? I scoured the API docs, I asked the Twitter-sphere, but no luck. All I learned was that the backgroundColor was hard coded into the bytes of the SWF. So I decided that’s where I needed to look for it.

SwfData to the rescue.

I read up on the Adobe SWF specification, and consulted with my good friend James Ward. He pointed me in the direction of loaderInfo.bytes, which gives us access to the bytes of the currently running SWF.

After a few hours, I had a fun little class I like to call SwfData, which parsed the background color out of the currently running SWF’s bytes… as well as some other fun things. Here’s how you use it:

package
{
	import com.zaalabs.utils.SwfData;
 
	import flash.display.Sprite;
 
	[SWF(backgroundColor="0x969696")]
	public class SwfDataExample extends Sprite
	{
		public function SwfDataExample()
		{
			var data:SwfData = new SwfData(loaderInfo.bytes);
 
			trace("version \t"+data.version);
			trace("frameRate \t"+data.frameRate);
			trace("frameCount \t"+data.frameCount);
			trace("fileLength \t"+data.fileLength);
			trace("bgColor \t0x"+data.backgroundColor.toString(16));
		}
	}
}

Using SwfData, I could now use the background color as the fill color of my BitmapData class.

Get It Here

SwfData is MIT licensed under ZaaUtils (do with it what you will). It is available on GitHub

Questions, comments, complaints are all welcome below.

== UPDATE ==

So I just found out that Claus Wahlers has an awesome, more feature complete version of an AS3 SWF parser. It’s also available on GitHub. I’m still going to keep SwfData up since it’s much more specific to getting the background color of the swf. If you need more features, use as3swf by Claus, it’s very well done.

The Flex Show – Episode 115

RIARadio – Episode 17

GangstaCast Episode 1: Celebrity Stalker Edition

Also, I was thrilled to find out that I was mentioned on TWiT.tv’s Tech News Today for an article I wrote regarding tracking celebrities by scraping exif data from photos uploaded to TwitPic, yfrog, TweetPhoto and TwitGoo.  The part when they talk about the article is about 15 minutes into the episode.

Tech News Today 34: Take Off Your Pants, America

Article on ZaaLabs

So all in all, it’s been a very interesting week.

There is now an update for Flash Builder 4 which downloads and installs the Adobe Flex 4.1 SDK. According to Renaun Erickson’s post, Flex 4.1 includes Flash Player 10.1 and AIR 2.0.

Now, if you’re like me and loathe the Adobe Updater… then you probably turned off the Adobe Updater notifications.

So here’s how to update Flash Builder to version 4.0.1 which includes the 4.1 SDK.

Go to Help > Search for Flash Builder Updates…

This will launch the Adobe Application Manager and then proceed to update your software, including Flash Builder 4.

== UPDATE ==

Once the update is completed you can see Flash Builder is now at version 4.0.1.

And you now have the option for Flex 4.1 as an installed Flex SDK. You can use Flex 4.1 to develop against Flash Player 10.1 and Adobe AIR 2.0.

This process has gotten much easier, you can now use software update to get AIR 2 as well as Flash Player 10.1 in Flash Builder… check out this post.

Adobe AIR 2 and Flash Player 10.1 were released on June 10th, 2010. It’s an exciting time. This weekend I decided to do some development on AIR 2 to try out some of the new features.

On the Adobe AIR Team blog’s post they mention that the free standalone download of the AIR 2 SDK will be available on Tuesday, June 15th… but I wanted to play with the SDK today.

So I went over to the Adobe AIR labs page and downloaded the AIR 2 Release Candidate SDK which is –> here.

You can download the released SDK from –> here

After downloading the Adobe AIR 2 SDK, I followed the directions on the release notes which explained how to overlay the AIR 2 SDK with my current version of Flex 4.

I’m on a mac, here are the commands I used in Terminal:

cd /Applications/Adobe\ Flash\ Builder\ 4/sdks/
ls
cp -r 4.0.0 4.0.0AIR2
ls
cp ~/Downloads/air2_rc1_sdk_mac_051110.tbz2 4.0.0AIR2
cd 4.0.0AIR2
tar jxvf air2_rc1_sdk_mac_051110.tbz2

I then added a new SDK to the installed SDK’s inside of Flash Builder:

Now, I already had an Adobe AIR application project set up, and I switched over to the new SDK the I installed:

However, when I tried to run my AIR application, I ran into this error:

VerifyError: Error #1014: Class IIMEClient could not be found.
 
	at flash.display::MovieClip/nextFrame()
	at mx.managers::SystemManager/deferredNextFrame()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:267]
	at mx.managers::SystemManager/preloader_preloaderDocFrameReadyHandler()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:2460]
	at flash.events::EventDispatcher/dispatchEventFunction()
	at flash.events::EventDispatcher/dispatchEvent()
	at mx.preloaders::Preloader/timerHandler()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\preloaders\Preloader.as:488]
	at flash.utils::Timer/_timerDispatch()
	at flash.utils::Timer/tick()

After doing a bit of research I found out that my Adobe AIR project’s application descriptor file wasn’t using the correct namespace for the AIR 2.0 SDK. According to the Adobe AIR 2 Release Notes:

You must update your application descriptor file to the 2.0 namespace in order to access the new AIR 2 APIs and behavior. If your application does not require the new AIR 2 APIs and behavior, you are not required to update the namespace from 1.x based namespace. To update the namespace, change the xmlns attribute in your application descriptor to: http://ns.adobe.com/air/application/2.0

Sure enough, I hadn’t changed my namespace from AIR 1.5.3 to AIR 2.

I made the change in the descriptor file, and now everything works perfectly.

Built in image support of Adobe Flash Player limits you to 3 image formats: gif, jpg and png. While this has worked well for many, many years… I recently have needed to expand the types of formats that I could use in Flash Player. I should also note that you can absolutely add support for these formats directly in ActionScript using ByteArray. For example Mike Chambers blogged about an AS3 BMP parser.

I was originally looking for support for TGA, BMP and PSD, when my friend Ben pointed me to DevIL and challenged me to port it using Alchemy.

Porting C code using Alchemy is not a very straight forward process, but between Aaron and I… and with help from Ben Garney and Branden Hall… worked our way through it. We plan on a series of blog posts discussing the process of using Alchemy in detail. Hopefully we can garner enough interest in the community around Alchemy to get Adobe to continue work on it.

ZaaIL is being released as open source software (MIT if you’re interested). We will post it all on GitHub when we get the chance.

[sidenote]
I have been asked by a few people if I think Adobe should expand from their three image formats and use something like DevIL in Flash Player… I don’t think they should. Adobe has given us the tools to create really cool things such as ZaaIL. I’d rather the Flash Player team focus on things I find way more important… such as 3D support, mobile performance, hardware accelerated graphics, etc…
[/sidenote]

ZaaIL allows developers to now to load more that 40 different image types… go ahead give it a try, I particularly like using a PSD file or cover art embedded into an MP3 (View source is enabled):

More information can be found over at ZaaLabs.