Whenever i find some free time i’m working on adding new, useful features. One feature of as3swf, that i haven’t talked about much yet but is implemented for quite a while already, is the reconstruction of timelines as you know them from Adobe’s Flash IDEs.

In the first place, timelines in as3swf help you to export and render layered animations. Having a long list of parsed SWF tags won’t help much if you want to export or render frame X, as the Flash Player would display it.

Flash Player Display List

When executing a SWF, the Flash Player reads sequentially through all its tags, from start to end, and builds and maintains an internal display list along the way. This display list is manipulated by PlaceObject and RemoveObject tags, and rendered every time the Flash Player encounters a ShowFrame tag. Characters placed on the display list by PlaceObject tags stay on the display list until they are removed by a RemoveObject tag. PlaceObject tags are also used to manipulate a previously placed character (tweens).

In order to figure out which characters are displayed how and at which depths in any given frame, as3swf simulates the Flash Player behavior and builds its own display list structures while parsing the tags.

as3swf’s SWF (root) and TagDefineSprite (movieclips) classes each have a timeline property, containing an instance of the SWFTimeline class. Other than the tags itself, this class contains the following goodies:

• dictionary – Contains references to all characters that may be placed on the display list. The dictionary’s key is the character ID as defined by the definition tag, the value is the index of the definition tag.
• scenes – Lists all scenes with their names and frame numbers.
• frames – Lists all frames. For each frame, you can access the contained characters and their depths, what tag placed the character on the display list, what tag modified its transformation/color matrices if any (for tweens) and whether this frame is a key frame or not.
• layers – Lists all layers. Each layer contains an array of active frames.
• soundStream – If present, contains this timeline’s sound stream complete with raw MP3 data, start frame, length, number of samples etc.

Example

Consider the following very simple FLA. It has two layers, one containing a motion tween, the other a static on-stage shape starting at frame 5:

Published to SWF:

Parsed by as3swf, we get these timeline infos (get the full trace dump here):

  Scenes:
    Name: Scene 1, Frame: 0
  Frames:
    [0] Start: 0, Length: 9
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, IsKeyframe
    [1] Start: 9, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 9
    [2] Start: 11, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 11
    [3] Start: 13, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 13
    [4] Start: 15, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 15
    [5] Start: 17, Length: 4
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 17
      Depth: 3 (Layer 1), CharacterId: 3, PlacedAt: 19, IsKeyframe
    [6] Start: 21, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 21
      Depth: 3 (Layer 1), CharacterId: 3, PlacedAt: 19
    [7] Start: 23, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 23
      Depth: 3 (Layer 1), CharacterId: 3, PlacedAt: 19
    [8] Start: 25, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 25
      Depth: 3 (Layer 1), CharacterId: 3, PlacedAt: 19
    [9] Start: 27, Length: 2
      Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 27
      Depth: 3 (Layer 1), CharacterId: 3, PlacedAt: 19
  Layers:
    [0] Frames 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
    [1] Frames 5, 6, 7, 8, 9

Lets take a closer look at frame 6:

  [5] Start: 17, Length: 4
    Depth: 1 (Layer 0), CharacterId: 2, PlacedAt: 5, LastModifiedAt: 17
    Depth: 3 (Layer 1), CharacterId: 3, PlacedAt: 19, IsKeyframe

This tells us that this frame:

• displays character ID 2 (the red square movieclip) at depth 1. This character was originally placed on the display list by tag index 5 and was modified by tag index 17 (this character is tweened).
• displays character ID 3 (the blue square shape) at depth 3. This character was placed on the display list by tag index 19. As the character was placed in this very frame, this is a key frame.
• starts at tag index 17 and consumes 4 tags total:

  17: [26:PlaceObject2] Depth: 1, Matrix: (1,1,0,0,1400,400)
  18: [83:DefineShape4] ID: 3, EdgeBounds: (2200,3200,1800,2800)
        FillStyles:
          [1] [SWFFillStyle] Type: 0 (solid), Color: FF0000FF
        LineStyles:
          [1] [SWFLineStyle2] Width: 200, Color: FF000000
        ShapeRecords:
          [SWFShapeRecordStyleChange] MoveTo: 3200,1800, FillStyle1: 1, LineStyle: 1
          [SWFShapeRecordStraightEdge] Vertical: 1000
          [SWFShapeRecordStraightEdge] Horizontal: -1000
          [SWFShapeRecordStraightEdge] Vertical: -1000
          [SWFShapeRecordStraightEdge] Horizontal: 1000
          [SWFShapeRecordEnd]
  19: [26:PlaceObject2] Depth: 3, CharacterID: 3, Matrix: (1,1,0,0,0,0)
  20: [01:ShowFrame]

As you can see, this info is a quite exact reconstruction of the original FLA’s timeline, and can be used to rebuild the original FLA (XFL, rather), to publish SWFs to run natively on alternative runtimes and platforms (HTML5, iPhone OS), or as a very first step to creating a web based version of the Flash IDE.

Happy hacking!

I originally posted the following article as comment to an article by Serge Jespers, “Flash is as open as HTML5“. Serge is an Adobe Platform Evangelist. I thought this comment deserves its own post, so here we go.

No, it isn’t.

And it is beyond me why so many independent Flash Platform developers fail to see it. I completely understand of course why Adobe evangelists downplay it.

It is irrelevant for the so called “open web” whether the Flash Player is going to get open sourced or not. That’s not the point. Microsoft won’t open source their browser, Opera won’t open source their browser, etc.

Relevant is who decides about the development of the data format that a runtime consumes, and the APIs a runtime provides to access that data. In the Flash world that’s SWF and the Flash Player APIs, both controlled by a single vendor: Adobe. In the HTML world that’s HTML and DOM, controlled by many vendors, including you and me, via standards bodies.

Adobe neither provides formal means for other companies and individuals to participate in the development of SWF and Flash Player APIs, nor does it provide detailed work-in-progress specs to the general public for discussion. This effectively rules out the possibility for third parties to provide alternative runtimes. The runtime and its specs are released to the public at the same time.

This is the exact opposite of “open”.

To make matters worse, the specs released by Adobe are incomplete and buggy (e.g. the SWF spec fails to explain how exactly shapes are supposed to be rendered and leaves out information on codecs, the ABC spec is plain wrong on some things) and generally infested with patented technologies.

Of course i understand why it is how it is (and likely always will be). If Adobe were to become truly open and put the development of SWF etc in the hands of standards bodies, the 1.5 year release cycle would become a 10+ years release cycle. Innovation would slow down significantly. I as a Flash Platform developer wouldn’t want that to happen.

However, sorry to say that, but to tout “Flash is as open as HTML5″ is pure FUD.

import com.codeazur.as3swf.SWF;
var swf:SWF = new SWF(root.loaderInfo.bytes);
trace(swf);

Trace output:

[SWF]
  Header:
    Version: 10
    FileLength: 149405
    FileLengthCompressed: 149405
    FrameSize: (550,400)
    FrameRate: 24
    FrameCount: 1
  Tags:
    [69:FileAttributes] AS3: true, HasMetadata: false,
      UseDirectBlit: false, UseGPU: false, UseNetwork: false
    [09:SetBackgroundColor] Color: #FFFFFF
    [86:DefineSceneAndFrameLabelData]
      Scenes:
        [0] Frame: 0, Name: Scene 1
    [82:DoABC] Lazy: true, Length: 149219
    [76:SymbolClass]
      Symbols:
        [0] TagID: 0, Name: Untitled_fla.MainTimeline
    [01:ShowFrame]
    [00:End]

Excercise: Draw something on stage, and run the code again.

Want more? Drop by my session Hacking SWF at FITC Amsterdam (Feb 22th, 16:00).

[Edit] Jim Cheng deserves credits. He was the one who whispered “root.loaderInfo.bytes” into my virtual ear on IM.

The problem is that the user needs to install the RPC server before she installs the actual AIR application. The install process should be seamless (one installer installs RPC server, AIR runtime if needed, and the application itself in one go) and the installer should be as small as possible. Currently there is no info available from Adobe on how to write custom installers that automatically download/install the AIR runtime if needed (is there?).

Artemis is another project aiming at extending AIR using a local socket server, but it seems that the project has been shut down because of the reasons stated above.

So i have been pulling out my hair lately on how to solve that problem.

I think i found a feasible solution. I am not sure because i haven’t tested all this, but i wanted to throw it online for discussion. The drawback is that the user needs to install your application with a OS native custom installer.

First you write standard installers for both Mac OS X and Windows, that install the local socket server either as a service/daemon or as an agent so that the server always starts at system launch or user login. Nothing special here yet.

The trick would be to write a simple SWHX application that basically implements the code included with the AIR Installer badge. That helper application can then be included with the installer, which executes it after the local socket server has been installed.

As i said i haven’t tested this yet (will do soonish), but this should work, no?

The question remains why i don’t just use SWHX for the main app and screw AIR alltogether.

So i finally sat down this weekend and added that.

The code is not tested very well (it works for me but may not work for you) and has no ASDocs yet, so i release it as an alpha version, with the hope of massive bug feedback.. :)

Download: fzip_1_0_52_alpha.zip fzip.zip

New methods in class FZip:

• addFile(name:String, date:Date, content:ByteArray)
• addFileAt(index:uint, name:String, date:Date, content:ByteArray)
• removeFileAt(index:uint)
• serialize(stream:IDataOutput)

Sample code:

// Create file contents
var ba:ByteArray = new ByteArray();
ba.writeUTFBytes("Hello World!");
// Create ZIP archive and add file
var zip:FZip = new FZip();
zip.addFile("hello.txt", null, ba);
// Serialize ZIP into a new file
// (we use the Adobe AIR specific class FileStream here,
// but you can as well use ByteArray or anything that
// implements IDataOutput)
var file:File = File.applicationStorageDirectory;
file = file.resolvePath("hello.zip");
var stream:FileStream = new FileStream();
stream.open(file, FileMode.WRITE);
zip.serialize(stream);
stream.close();

FZip now uses ByteArray.uncompress(CompressionAlgorithm.DEFLATE) instead of the now deprecated ByteArray.inflate(). I also tweaked FZip to throw an exception when a parsing error occurs and no event listener is registered for FZipErrorEvent.PARSE_ERROR events.

AIRRemoteUpdater now gets the local descriptor XML via Shell.shell.applicationDescriptor which was added in AIR Beta 2, and uses the upgraded FZip sources.

Enjoy, and please let me know if you run into any problems with this new release.

It transparently checks version numbers, downloads the .AIR installer file if needed and triggers the AIR-native update process.

It grabs the version number directly from the remote .AIR file without having to download the entire file, eliminating the potential error prone need of having to put a separate descriptor file online along with the .AIR installer file.

Background:

An .AIR installer file is a PKZIP archive containing metadata files along with the packaged application files. The files contained in a .AIR installer file are, in this order:

1. /mimetype
2. /META-INF/AIR/application.xml (contains version info)
3. /META-INF/AIR/hash
4. /META-INF/signatures.xml
5. packaged application files

The file we are interested in, /META-INF/AIR/application.xml (the “application descriptor file” that contains the version number), is always the second file in the archive. AIR Remote Updater uses FZip to stream in the remote .AIR until (and only until) the application descriptor file has loaded. We can then close the stream, uncompress that file and extract the version number.

More info and download here:
http://codeazur.com.br/lab/airremoteupdater/

• Added support for Adobe Air. The Adobe Air runtime provides a low level inflate method, making it possible to load any ZIP archive and decompress compressed files without the need of injecting Adler32 checksums.
• Added FZipLibrary class for higher level access to files in a ZIP archive. “FZipLibrary processes files (based on file extensions) from an FZip instance and converts them into usable formats. Files can be converted to either a BitmapData or DisplayObject classes. Data embedded in SWF files (like classes) can also be retrieved. Flash’s built-in Loader class is used to convert formats, so the only formats currently supported are ones that Loader supports. As of this writing they are SWF, JPEG, GIF, and PNG.”
• Bug fix: There was a problem with filenames containing special characters. Filename encoding now defaults to UTF-8. In case the filenames are encoded differently in your ZIP, you can specify the encoding in the FZip constructor.

Special thanks to Daniel Wabyick at Adobe for contributing the Adobe Air support!

Enjoy!

http://codeazur.com.br/lab/fzip/

Last.fm provides an application along with plugins for pretty much all existing media players on all major platforms (Windows, MacOS, Linux, etc) that does exactly that. During installation of the Last.fm client, the user is prompted to install the required plugins for the media players she uses. When a media player executes and plays a song, the plugin establishes a TCP socket connection with the client application and sends status and song infos.

The problem: The Apollo runtime (alpha) that is currently available on Adobe Labs doesn’t provide any documented way of (a) talking to shared libraries, (b) launching executables or (c) serving as a socket server, and Adobe indicated that Apollo likely is not going to support those features in it’s 1.0 release version.

There is hope though. Afaik, the last word on launching executables at runtime from an Apollo app isn’t spoken yet, and there exist some undocumented hacks that enable Apollo apps to do just that. If Adobe should decide against letting apps launch executables, then the only way of solving it is to provide second installers that install a socket server of some sort to do the dirty work.

However, i sat down last night and wrote a proof of concept Flash application that can live in Apollo, which talks to a custom daemon via sockets. The daemon in this proof of concept runs as a Windows Service. I took the Last.fm iTunes plugin and modified a bit so that it also connects to that daemon. The daemon then simply echoes the messages it receives from the Last.fm plugin to the socket listener in Flash. Voilà.

Here’s a screenshot of the app in action (iTunes on top, Flash below):

[Update] I also modified the Last.fm Windows Media Player plugin to work with my daemon. All plugins can be used simultaneously. See this screenshot (Windows Media Player on top, Flash below):

Note that this is only a proof of concept, and sources aren’t ready for release yet. I would very much like to make this an open source project (The Last.fm plugins are released under GPL), so if there are any interested developers out there who like to help, please contact me or leave a comment. Thanks!

If you’re in central Europe early May, please drop by. Among others, Mario Klingemann, Andre Michelle, Peter Elst and Marcos Weskamp will be presenting, and as the flashconference is taking place as part of the fmx (“12th International Conference on Animation, Effects, Realtime and Content”, May 1st-4th), there’s almost a full week of top notch events to attend.

Check out the full schedule here.

I’ll stay in Germany for two weeks and will be traveling Munich, Stuttgart and Bremen, so if you like to meet, please drop me a line!