Category Archives: Flash

ZIP it up!

Posted on by

Did you ever write an image gallery or a game in Flash? Did it bother you to write rather complicated load queues to load lots of small files such as image thumbnails or game assets like tiles? Are you working with big text files and need a reliable way to compress/uncompress them to save valuable bandwidth?

I’m proud to announce FZip, a cute little Actionscript 3 class i’ve been working on together with Max Herkender that enables you to load standard ZIP archives and extract contained files while the archive is still loading.

FZip is released under OSI approved zlib/libpng license.

Sample usage:

public function YourApp() {
   var request:URLRequest = new URLRequest("your.zip");
   var zip:FZip = new FZip();
   zip.addEventListener(FZipEvent.FILE_LOADED, fileCompleteHandler);
   zip.load(request);
}

private function fileCompleteHandler(evt:FZipEvent):void {
   var file:FZipFile = evt.file;
   trace("File loaded: " + file.filename)
   trace("  " + file.sizeCompressed);
   trace("  " + file.sizeUncompressed);
}

Check it out: FZip at côdeazur brasil lab

Real Coders do Assembly

Posted on by

So our Flash Commodore 64 emulator project, FC64, got nominated for the Flashforward Film Festival recently (read my previous post). The 60 finalists are given the opportunity to submit a 45 second trailer showcasing the work, that will be shown live in front of 1000 people at the ceremony.

I won’t spoil it so i won’t show the trailer here (you gotta wait until after the Flash Film Festival ceremony or better yet attend it to see it). What i can do though is – in the spirit of open source – show you the source code:

http://codeazur.com.br/stuff/fc64trailersource.asm

The trailer is written in 6502 assembly and runs in FC64 – a real ‘Demo’. It actually should run as is in the original C64 hardware, and in any other C64 emulator. If i ever find the time, i’m going to prepare a binary image to load it into other emulators.

By the way, FC64 features an assembler (the souce code above is loaded and compiled at runtime into the emulator), as well as a disassembler and debugger. This is currently not reflected in the emulator UI and undocumented. Plans are to make the UI a full featured IDE for developing stuff for the C64.

I had hell of a fun coding the trailer demo, and it put me right back in the mid 80es when i used to waste night after night coding on my beloved bread box. Ahhh, memories.. :)

Back to AS3 development now, listening to Depeche Modes ‘See You’. Ha :)

Innovation, or the lack thereof… W3C, anyone?

Posted on by

I originally posted this on the OSFlash mailinglist, but i thought it would make a good blog post, so here it is:

My vision of a next generation web application framework.

(or: Innovation, or the lack thereof… W3C, anyone?)

There’s a sh*tload of XML dialects for GUIs either available or being developed at the moment. Just to name a very few: Adobes MXML, Microsofts XAML, Laszlos LZX, Netscapes XUL, and from the OSFlash camp ActionSteps ASML (or Renaissance) and ASWings AWML.

All of them are proprietary formats (plus most of them are direct projections of the underlying, proprietary APIs), and all of them require some decent amount of script code to be written in order to actually make the UIs work. Problems: to author sophisticated applications i need extensive knowledge of the XML dialect itself, of the API and the scripting language, and probably of the underlying platform API too. For most ‘next gen’ RIA platforms much of this is proprietary stuff, so i better choose wisely what technology to dive into for the next months/years. I also better be able to think ‘code’ in order to make my RIA a successful reality.

Wouldn’t it be nice to develop web applications using open, standardized technologies that everyone is already very familiar with? Let me introduce you to the W3C, and please try to forget about browsers in general and men with white beards wearing birkenstocks in particular for a moment.

Contrary to popular belief, the W3C is working on really cool stuff. Some of it you’re already very familiar with: (X)HTML and CSS. The *real* cool stuff though are W3C technologies that haven’t made it into the mainstream yet (because they aren’t supported by mainstream clients, or because they’re being worked on yet). I pick two of those technologies, XFrames and XForms, and briefly introduce them here, as i think that together with XHTML (2) and CSS (3), they pretty much cover everything a RIA framework needs.

XFrames
The technology that is supposed to supersede HTML Frames. XFrames of course is going to support framesets as we know (and hate) them today, but there’s so much more. Using CSS, frames can be styled to appear as floating windows or tabbed panes for example, and using a new URI scheme it will be possible to easily link not only a frameset but also it’s content, example: http://example.org/index.xframes#frames(id1=uri1,id2=uri2,...).

XForms
The technology that is supposed to supersede HTML Forms. XForms is going to significantly change the way we author forms. Basically, it separates the model from view and controller, as you can now have multiple data instances (usually XML, both inline or external) that you can use as data provider for controls and widgets (controls can be bound to data provided by instances using XPath). Validation is handled in a purely declarative way via XML Schema datatypes. But again, there’s much more, for example: <switch> and <case> to show/suppress parts of the UI (to be used for e.g. wizards, tabbed interfaces or dynamic forms), or <repeat> (to be used for e.g. filling tables with rows, or datagrids, or just about anything UI that repeats itself). Of course everything is styleable by CSS and can be bound to data instances. Sounds familiar? It sure is. And did you know that the latest ColdFusion uses XForms under the hood? Yes it does.

I recommend the W3C articles “XForms for HTML Authors” (Part 1 and Part 2) and Micah Dubinkos XForms Institute (hey look, he’s using DENG!) for a leightweight introduction to XForms (The XForms Institute also links a free online version of the O’Reilly book “XForms Essentials” in case you’d like to dive in further)

If you mix all those technologies mentioned above, and throw in some more, like SVG, SMIL, and maybe even XUL, that’ll be my vision of a sane platform for Web 2.0 [sm][tm](c)… ok, Web 3.0 it is then. A sane platform to develop RIAs on. Don’t even get me started ranting about the current state of the web as too many people see it. What the web needs is innovation, not hyped acronyms for old crap, or yet another proprietary markup language.

Of course such a framework needs to be developed yet. With the Flash Player 9 in our hands, the great performance boost compared to version 8 and a way better API (minus native text rendering.. still sucks), i’m sure it’s absolutely doable. If only somebody with some angel $$ would share my views, or if only everybody would work together with open minds instead of cooking their own soup…

We even have a proof of concept, anybody remember DENG? That was Flash Player 6. I’m also writing all this because i think most people misunderstood DENG and see it as a better HTML-enabled TextField or something, or worse, as a HTML browser. It was supposed to be the beginning of an application framework. Of course it’s missing A LOT yet to really become one (and of course Flash Player 6 was way too slow to do such stuff), but again, with Flash Player 9 and some likeminded developers, this could become quite a blast.

Thanks for listening :)

Addendum: Some good and valid remarks and questions i got in the OSFlash mailinglist:

This is, in my mind, a brilliant idea especially when you throw in Haxe‘s planned ability to render to different (and future) runtimes (I assume that you would use Haxe to do this).

One of the most frequent issues on the Haxe list is the lack of a component written for Haxe. I think that a project like this would solve that issue for Haxe.

I’ve looked into Haxe. It sure looks promising, and It’d be a major plus that a framework written in Haxe potentially wouldn’t have to be tied exclusively to the Flash Player. The first thing i would do if i would start to develop such a framework in Haxe is write a compliant DOM3 Core implementation that works exactly the same in Flash 6, 7, 8 and 9 and in all mainstream browsers. That alone would already kick some serious bottom.

I glanced through the XForms documents on w3c and was wondering if it would be possible to leverage one of the existing component sets (specifically ActionStep or ASWing) to complete this task? To me, it would seem like a much smaller job if we used an existing framework.

But could we imagine to bind a standard Flash XFrames/XForms/CSS parser with any/a few GUI toolkits? That would actually be great, but is it possible to achieve?

I have been asked this question many times already. Theoretically, this is possible. However, if i would develop such a framework, i would surely want to implement CSS3 which features styling and skinning mechanisms that imho beat those implemented in all current GUI toolkits together, and integrates perfectly into all mentioned W3C technologies. So depending on what toolkit you use, you probably can only implement a subset of CSS3. I also think that it wouldn’t be very easy to integrate custom component sets, or rather, i think it wouldn’t be worth the pain.

C64 Emulator for Flash Player 9

Posted on by

I’m happy to finally be able to let the cat out of the bag. Darron Schall and myself have been working on a low level 6502/6510 emulator and, based on that, on a Commodore C64 emulator/simulator.

The emulator is completely written in Actionscript 3 and runs on Flash Player 9. It loads the original binary C64 Kernel ROMs at runtime, and executes them just like the original hardware would do.

The sources are released under GPL, get them here:
Trac: https://mirror1.cvsdude.com/trac/osflash/fc64/
SVN: http://svn1.cvsdude.com/osflash/fc64/

Quoting Darrons blog post from today:

It’s still a work in progress, and we’re looking for hardware-nerds to step up to the plate and help us finish it. The CPU code is complete, but hasn’t been extensively tested. The memory code is a work in progress, and we haven’t had a chance to start on the display code yet. Still though, it’s a good start.

At this point, we’re just running the CPU as fast as possible without trying to get the timing completely accurate. On the debug Flash Player, it runs at ~2.5 MHz. On the release Flash Player, it runs at closer to 6 or 7 MHz. This is a good thing, as the original Commodore chip only runs at 1 MHz. So, in theory, it should be possible to emulate the games in real-time without any slow down or speed delays (holy @#!@).

DENG and OpenLaszlo

Posted on by

Inspired by a user i wrote a proof of concept DENG proxy today, to be used in OpenLaszlo applications.

Follow these steps:

  1. Download and install OpenLaszlo
  2. Create a folder “deng” in your my-apps folder ([openlaszlo]/Server/lps-3.1.1/my-apps)
  3. Download the DENG test application for OpenLaszlo and extract it into the folder you just created
  4. Point your browser to http://localhost:8080/lps-3.1.1/my-apps/deng/deng.lzx

You should get a minimal application with buttons to load two test documents and to set the size of the rendered documents:

OpenLaszlo & DENG test application

I must admit i’m a OpenLaszlo newbie (installed it today for the first time), and the solution smells a bit like a hack (it certainly is). I also have no idea yet how to send events from DENG to the OpenLaszlo app. Any pointers highly apprechiated!

AS3: Loading Class Libraries at Runtime

Posted on by

The Flash Player 8.5 features a nifty API to dynamically load assets at runtime, using the flash.display.Loader and flash.system.ApplicationDomain classes. Let’s assume we have a package, test.c1, that we want to keep in a separate SWF and only load it into the main SWF when needed.

We create a project Main that has the following structure:

  • Main.as
  • Child1.as
  • test/c1/TestClass.as

Child1.as is compiled into Child1.swf and contains test.c1.TestClass.

Main.as is our main application class that loads Child1.swf and uses test.c1.TestClass.

test/c1/TestClass.as

package test.c1
{
   public class TestClass
   {
      public function TestClass() { }

      public function method():String {
         return 'test.c1.TestClass.method()';
      }
   }
}

Child1.as

package
{
   import flash.display.Sprite;
   import test.c1.TestClass;

   public class Child1 extends Sprite
   {
      public var TestClassInst:TestClass;

      public function Child1() { }
   }
}

Main.as

package
{
   import flash.display.Sprite;
   import flash.display.Loader;
   import flash.system.ApplicationDomain;
   import flash.net.URLRequest;
   import flash.events.*;
   import flash.util.trace;

   public class Main extends Sprite
   {
      private var child1:Loader;
		
      public function Main()
      {
         var url1:URLRequest = new URLRequest('Child1.swf');
         url1.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain);

         child1 = new Loader();
         child1.addEventListener(EventType.COMPLETE, onChild1Complete);
         child1.load(url1);
      }

      private function onChild1Complete(e:Event):Void {
         trace('onChild1Complete ' + e);
         var c:Class = child1.loadeeInfo.applicationDomain.getClass('test.c1.TestClass');
         var co:Object = new c();
         trace('test.c1.TestClass.method() returns: ' + co.method());
      }
   }
}

Using this method we could have different implementations of an API in different SWFs, and load the one we need at runtime. Naturally, we would want to use interfaces to ensure the API implements the right things, and use those interfaces for both the external modules and the main app. Note that i instantiate test.c1.TestClass as an anonymous object in the above example (var co:Object = new c();). I actually should have provided an interface definition test.ITestClass that describes the features of that external class (var co:ITestClass = new c();), however the alpha of Flex Builder has a bug that currently prevents us from doing so. Macromedia is aware of that bug so hopefully this is fixed soon.