I’ve been kicking around the idea of starting a Flash / Flex podcast. The plan is to get drunk and talk about Flash but maybe you have a better idea.
Do you care? Would you listen? What should we call it? What should we talk about? What topics would you like to hear discussed?
Please leave us any feedback you like.
I don’t know about you, but Half-Life the first was, at the time, beyond a shadow of a doubt, the best game I had played. The AI was great to battle against, there was an honest-to-god story, there were surprises and twists and traps, and the graphics and especially audio design put me squarely in the game. I’m also a sucker for science fiction when it’s treated anywhere above the first-grade level (requires suspension of disbelief = ok, completely inane = no thanks), and for dark secretive things that you must discover. Without making a comparison, Half-Life 2 had all the same elements, with the addition of a slightly more sober and solid plot, and some absolutely astounding scripted action and facial animation. I was hooked on HL2 from the start. So now the crazy Orange Box is out, and I have a hard time not being excited, especially about the brain-fscking puzzle game Portal. (Check out Aperture Laboratories’ page - the password is “portal”).
But if you haven’t picked up the box yet, or if you did and you just now got HL2: Episode 1 for the first time, you simply must play Minerva, a three-chapter user-created mod (free!) for HL2: Episode 1. It was created over two and a half years by Adam Foster. I just finished playing it, and I’m absolutely amazed. I was on the edge of my seat for the duration (around 5 hours, about the same length as Episode 1). The level design is absolutely top-notch. The action is incredibly intense. The puzzles are challenging. Without giving anything away, parts of it definitely stir up foreboding, fear, desperation, intrigue. It’s a story tangential to Half-Life 2, and you do not play Dr. Freeman, and you do not have the gravity gun, which I rather liked. The experience is completely gripping, just like the best of Half-Life. So enough said. Try this mod now! You won’t regret it!
UPDATE: I miss my companion cube ;(
It’s the classic story in Flash development. A designer puts hours and hours of work into a Photoshop document or a Flash animation that ultimately gets thrown away and rebuilt when it comes time to develop the application. I’ve often wondered if this could be fixed by having information architects do their wireframes in FlexBuilder’s design view. Apparently, Adobe are on the same line of thinking and are taking a crack at solving this problem.
The solution they’ve come up with is a Dreamweaveresque WYSIWYG editor that can convert Photoshop elements directly into functioning Flex code. They call it Thermo and here is a sneaky video preview of it.
Check out Peter Elst’s collection of Sneek Peek sessions from MAX. I’m on the verge of tears looking at Scott Peterson’s C/C++ on Flash demonstration. What… the… hell. He seems to indicate that he’s written a C++ to AS3 translator, not a C++ compiler that targets ABC. Peterson mentions including scripting hosts for other languages into the AVM, so you could run PHP or Ruby or whatever inside a SWF. Why not? I’m really interested to see how one would implement multithreading in a performant way… you could always chunk up your translated AS3 code into equal sized blocks, managing your scope and running only one block per frame, but how would you tune this to the speed of your processor dynamically, doing more or less code per frame to fully utilize your available CPU time? No idea. Then he proceeds to shit everyone’s pants by showing his AS3 translation of Quake I. Now this baffles me. At some point he simply must have replaced one of the display libraries with a for-Flash-Player BitmapData adapter library. And the sound control seems even more improbable to have been ported automatically. Anyway, this seems completely outrageous. I thirst for more information. I’d love to read a much more detailed article on how Scott approached this; whether he really let the AS3 compiler do all that work, or how much he dug into the AVM itself. But for now, I have to pick up my jaw from the floor, please excuse me.
If you watched the video from our previous post, you no doubt have heard of Hydra and AIF - the new image processing language for Adobe products including Astro. I’ve since downloaded the AIF Toolkit and played around with it and found it’s surprisingly simple. I made my first Hydra patch which is admittedly basic but only took me about half an hour to put together. Check it out below!
Adobe demos new features of Astro/Flash Player 10 at MAX. Credit goes to Aral for the video.
Using mxmlc / Flex Builder, you can safely store any kind of binary data, text, or XML directly in your SWF if loading it at runtime is not possible or not desirable. Find out how below.
My friend EJ was wondering if there was some way to compile XML directly into an application without putting it inline in code. Of course E4X allows you to type XML literals, but doing so with large blocks of XML can be problematic for a few reasons. You can’t edit this XML with an XML editor. The XML parsing inside Flex Builder can be faulty on occasion, causing ActionScript in the same file to be misinterpreted. Placing XML in your source files can make them unwieldy and large, and slow to parse.
My initial idea was to use include. Even though #include is deprecated in AS3, the little-known include (no hash mark!) uses the same syntax and can include code in much the same way. The Flex framework uses this to include a common version number as a static field in many classes:
mx_internal static const VERSION:String = "3.0.0.0";
This line, found in the file Version.as is placed in the class definition of classes where include “Version.as” is found. However, you can’t just include arbitrary copy. The included code has to be one or more full lines. So my idea of using
protected var xml:XML = include "static.xml" ;
wasn’t going to work. It did work when I included the whole variable declaration in the XML file, but then the file wasn’t valid XML any more! Not even close. And not too much better than just typing inline.
The solution here is much, much more powerful than the original hack might have been. The MXML and AS3 compiler, mxmlc, which is used by Flex Builder as well, has the ability to embed all kinds of video, graphics, other swfs, and fonts into a SWF. The [Embed] metadata tag / compiler directive works whether you are using Flex or simply AS3. [Embed] associates a bit of data with a class that is capable of representing it.
If you haven’t seen it used before, here’s a simple example where we embed an image in the SWF:
[Embed(source="assets/photo.jpg")] private const PhotoImage:Class;
And then you can use it:
var myPhoto:DisplayObject = DisplayObject(new PhotoImage());
So, I don’t know how Adobe is really implementing things under the hood, but I say the following with some certainty. The compiler, happening across your [Embed] directive, retrieves the source, and examines it to see what kind of file it is. Depending on the type of file you’ve asked the compiler to embed, the runtime class reference will produce a subclass of a particular kind of class which is appropriate for the data you’ve embedded. The compiler will take the source of that file, transcode it, preparing the data to be inlined in the SWF itself, and possibly preprocessing it, for example parsing SVG into vector shapes.
You should also know that depending on whether you’re using the Flex framework or not, I believe you will end up with different superclasses associated with your embedded assets. If you use Flex, you might see a FontAsset subclass where you would simply get a Font subclass were you only using ActionScript.
You can also embed SWFs and symbols from within SWFs, a technique I quite like. Simply use a symbol attribute in the compiler directive:
[Embed(source="MenuAssets.swf", symbol="com.partlyhuman.assets.TopMenuItem")] protected const TopMenuItem:Class; addChild(Sprite(new TopMenuItem()));
The transcoder should automatically know what to do with these kinds of assets:
But get this! There are more things you can convince the transcoder to accept. By manually specifying the MIME type of the file, you can force the transcoder to interpret the data in some format. This is the solution to embedding any XML at compile time, and then some. In fact, you can embed any binary data you want in a SWF, as long as you know how to interpret it on the other side.
There may be additional interesting MIME types that are registered by the transcoder. These are, as far as I know, undocumented, so if you find an interesting one that’s not covered by the types above or these two introduced here, leave a comment.
Here, we see that we can import an XML file with MIME type text/xml, and it embedded as a subclass of XML.
[Embed(source="test.xml", mimeType="text/xml")] protected const EmbeddedXML:Class; var x:XML = XML(new EmbeddedXML()); trace(x.toXMLString()); //it should work!
To get this to work, you should keep the XML prolog in your XML file. With this technique, EJ didn’t have to load the XML asynchronously, it was embedded right in his SWF for instant access, binary compression, and easy deployment, and tight coupling with the build itself. He could also now use a normal, full-featured XML editor to mess with the XML source.
But it gets better! You can embed any binary data whatsoever in a SWF, as long as you know how to interpret it on the way out. To do this, use the directive to embed any file with MIME type application/octet-stream (an octet is just a fancy word for a byte, by the way, as a byte is eight bits, so a stream of octets is a fancy way of saying “a bunch of bytes”). The class comes out in ActionScript as a subclass of, can you guess? ByteArray!
Here, ActionScript genius Max knows how to parse a WAD file, which Doom and other ID games used for levels and sprites and all kinds of business. He puts it right in the SWF by embedding it as application/octet-stream and interpreting it as a ByteArray:
public class DoomTest extends Sprite {
[Embed(source="doom1-shareware.wad", mimeType="application/octet-stream")]
private const DoomWad:Class;
public function DoomTest() {
var wad:ByteArray = new DoomWad() as ByteArray;
new DoomCore(this,wad);
}
}
(Full source here) And, passing it to his Doom playing engine, you start playing the shareware level of Doom that was embedded right in the SWF!
You can apply this technique to any binary data you’ve cleverly figured out how to parse. Of course, Flash knows very well how to parse all the file types described in the list above, but with some creative coding, that’s just the beginning!