Flex Enterprise Services: Airplane Chat

A few weeks ago, I opened the Chat example that comes with Flex Enterprise Services 2 to see how it works. Utilizing Flash Media Server (formerly known as Flash Communication Server) Remote Shared Objects requires low-level ActionScript. Since Flex is all about concise, high-level tags, I was curious how easy they had made it. Using the Chat example file as a basis, I tried to make a multiplayer airplane game where each person in the chat has an airplane avatar they can fly.

I’m sort of ambivalent towards their message implementation. Considering I haven’t read the documentation either, I’m sure I have missed a significant amount of information about the API and only used part of it. Glancing at the docs, this appears so. Additionally, I didn’t take advantage of the server at all; I just added 1 entry to the config and left. Flash Media Server has a lot you can do with the server to help you build multi-user applications, so I’m assuming the same for Flex Enterprise Services 2 as well.

I still feel from coding this that the API is just as low-level as writing pure ActionScript, only cleaner and AS3 compliant. This was only a 4 hour project, though, so I can’t really make any firm decisions on how I feel about it.

Bottom line, creating push based applications for most people will be f’ing cake. Using just 1 tag that allows you to bind various controls to data is pushed to the server is extremely powerful, and even those who barely use this feature will have immediate, and clearly visible benefits. For those of us creating games, I don’t know… more research & reading is needed.

Basically, install the server, open the flex-config.xml, copy the chat tags and name it “fly-jms”, and reboot the server. Either setup your Flex 2 project in the Flex server it installs, or write an ANT task to copy files there. Don’t forget, it installs in the Program Files > Adobe, not Macromedia, hehe!

Airplane Chat – Example | Source ZIP

FlickrMobile: A Flash Lite 2 Applicatio

*** Update 4.25.2006: Provided a Flash Player 6 version for PSP.

*** Update: Yes, I used FAME (Flashout + ASDT + MTASC + Eclipse) to build this.


As has been reported by Scott F. and Scott J., the Flash Lite 2 Update for Flash Professional 8 has been posted, allowing Flash Developers to create content for the Flash Lite 2 player which has been on sale for only a short while. Since the update gives you the SDK, all the documentation you need to get started creating Flash Lite 2 applications, and the emulator to preview your content in Flash 8 Professional, I figured I’d show you an example of what can be done.

FlickrMobile – A Flash Lite 2 Application

FlickrMobile is a small app I put together showcasing my favorite apps for phones; using Flash as the front-end to access server-side content. All of the web API’s that have been appearing are just ripe for harvesting, and Flickr is one of the best.

Now, you can email/multmedia message your pictures to Flickr from your phone AND view them from your phone… how cool is that!? I am constantly emptying my memory card on my phone where my images are stored, and my other camera that takes better pictures already has all of its images up at Flickr. So, even if I am not posting anything, it’s nice to show friends some images I have no matter where I am (one of these days I’ll get a laptop).



I used phpFlickr on the back-end with AMFPHP. Since Flash Lite 2 doesn’t support Flash Remoting (found this out in the middle of development, hehe), I just used a simple PHP FrontController pattern to take LoadVars commands, and spit back XML. Easy stuff. I love PHP.


Flash Lite 2 Components

If you are like me, you thought using Flash 4 syntax was a joke. I swore I’d never do Flash Lite development until I got AS2. Macromedia over delivered, giving me other features I didn’t even think about using on a phone.

One key thing missing, though, were components. It is implied you should use the Flash Lite 1.1 ones, but I’d rather be thrown in a burlap sack tied shut with a dog, snake, and a monkey all inside with me as the sack is thrown into a deep river vs. using those things for “application development”. (context: the Romans did that, George Carlin told me so)

Richard Leggett felt… somewhat the same way. So, we made a lighter version of the v2 components to work in Flash since the v2 ones that come with MX 2004 & 8 do not work on phones; they are too bulky.

Unfortunately, they were also a testing ground for seeing what Flash Lite 2 can do, as well as my failed attempt at doing deferred instantiation like Flex does, so they really aren’t mature enough for mass developer usage. However, they are something, and allowed me to create this application as a proof of concept.

What did it prove? Flash Lite 2 is f’ing sweet. J2ME just got served.



Once connected, use left and right keys to change images.


Source Code

FlickrMobile – ZIP

Tested and works on my Nokia 6680.

Known Issues:

  • Slow – Flickr’s sometimes extremely slow and unresponsive and my Cingular MediaNet is dog slow.
  • Cannot press next and back quickly; if you do, it’ll wait to download the images in order, before downloading the next, thus causing a long wait to see the image you selected. Known bug in Flash Lite 2.
  • Some Flickr images from their static server do not load. Unknown cause.

To use, just install Flash Lite 2 on your phone, copy the compiled SWF to your phone (included in ZIP), and run from Flash. At the connect screen type in your Flickr name in the field, and click “Connect”.

Creative Commons License
This work is licensed under a Creative Commons Attribution 2.5 License.


Diesel & Battlefield: ActionScript 3 Blitting Engine for Tile-Based Games

Diesel is a blitting engine for Flash Player 8.5 using ActionScript 3. Uses 1 bitmap to paint to vs. using many DisplayObjects in an effort to utilize less CPU & RAM.

Skip to Introduction if you want to know more about Diesel, or read on for background as to why I’m posting this.



I was originally using this project as a part 2 & 3 followup to my blitting post, but realized it is a ton of work. Even getting simple benchmarks down on alpha software is pointless because many memory bugs are fixed in later versions, rendering your previous benchmarks worthless. For example, I’ve found a bug with flash.display.Loader where, if you issue a ton of loads, say over 1900, each load allocates almost a meg of memory. The problem is, even if you delete the loader as well as what it loads, the memory isn’t freed. This is known and will apparently be fixed in a later build.

Not to mention I’m still learning ActionScript 3, so my style of coding has changed the more I learn, making it hard to keep 2 different approaches to a problem in sync: using Sprites vs. blitting to 1 bitmap.

I will say this with confidence; blitting is far more scaleable than using a multitude of Sprites. While the memory usage for blitting is far below what the Sprites use, the processing isn’t what I’d hope it’d be. Additionally, I’d forgotten just how much RAM bitmaps can take. So, even if you make a 2880×2880 blank, transparent bitmap in RAM, it still takes about 44megs.

I still believe, however, that blitting is the future of Flash games, and all I need to do is optimize the Diesel engine a bit more, and she’ll be a more attractive alternative to utilizing Sprites for game development.

My original goal in posting was to show my older version of Battlefield, a simple tile-based map engine based on Sprites, and one based on Diesel. A milestone I had reached as getting the TileMap, a base class, to using blitting only, and scrolling via double-buffering (copying pixels from a larger bitmap, not-shown off-screen). While this made the map scroll really fast, when I started adding Sprites, it still kept a good refresh rate, but started using way more processor than I had experienced in earlier tests on a smaller scale using Flash Player 8.

Frustrated, I realized I had to re-write even all of the sub-classes in Battlefield that rendered sprites, as well as the main walking character. I did so at the cost of not updating the older Sprite one with which to do benchmarking at a later date. Don’t care, though, because again, I feel blitting is worth spending more time on perfecting and optimizing.

So, without further adu, I present a really early build of Diesel, a blitting engine, and Battlefield a simple tile-based engine example that uses Diesel.



With the addition of Bitmap classes in Flash Player 8, developers now have the ability to utilize blitting and double-buffering techniques to create resource efficient gaming engines in the Flash Player. Diesel is a set of ActionScript 3 classes that provide a conveinent display engine to take advantage of these new player features.


Why should I care?

Diesel uses 1 bitmap to draw to vs. hundreds of MovieClips. This results in a more scaleable engine, allowing for more moving sprites, lower usage of RAM & Processor, and better refresh rates.


What’s wrong with MovieClips for games?

While MovieClip’s are conveinant to code & design with, they are not efficient when dealing with a multitude of bitmaps for games. They also do not scale well when you need to create many of them, and have them all move on the screen at the same time. Finally, large bitmaps in Flash traditionally have not scrolled very fast when used as tile-based game backgrounds. You either have to use 1 large bitmap that is pre-rendered, or you can use tiles in the traditional sense, but neither is an optimal solution for games.

Big bitmaps are not an ideal solution for a couple reasons. First off, it’s not dynamic; you have to create this before hand. While you can load it in dynamically, you have to use MovieClips atop it to generate any effects. Secondly, even if you mask a certain area of the screen, the rest of the bitmap is still drawn the screen, taking up a lot of processor & ram and sacrificing a good refresh rate (smoothness of the animation).

For tile based games, you have 2 solutions. Either draw all of your tiles as multiple MovieClips, and have all of them created in one parent MovieClip. When moving your map, you simply move the main MovieClip that houses them. While this makes coding easy, it suffers from resource usage, namely reduced refresh rate, and it gets worse the more tiles you create. This is even before you start putting gaming sprites on the screen.

Your other solution is to create the tiles on the fly based on the direction the character in the game moves. While this is a lot more scalable than the above, allowing you to create bigger maps, you suffer from redraw speed when creating the new tiles. The creation & destroying operations that you use on the tiles takes up a lot of processor, reducing the continual smoothness of your animations.


How is Diesel better?

It uses a technique called double-buffering. By using 1 bitmap, you solve a bunch of issues MovieClips have traditionally caused. First, you have 1 bitmap, not hundreds. Each sprite in your game is represented as a data object, but it’s bitmap data is copied to the main big bitmap. All sprites are copied to this main big bitmap. This big bitmap is actually not shown, but is off-screen and not in the Display List. A portion (or all of it) is copied to an on-screen bitmap that is repainted when something moves or changes.

This uses significantly less RAM because each sprite in your game is actually just a data object vs. a Sprite or MovieClip. You store basic information like x and y position as well as width and height as BitmapSprites. They are then added to the BitmapDisplayObject, much like you add MovieClips to the Display List. BitmapDisplayObject is just a flash.display.Bitmap that renders all of the BitmapSprites added to it’s list of things to draw.

Additionally, the entire bitmap does not have to be drawn. For example, many tile-based games consist of a large map, but only a small portion is shown. For this reason, only a small portion of the map can be shown, and thus drawn, not the whole thing. So, when repainting, only those portions of the screen that need to be redrawn are, not the whole thing, nor things not shown.


Why not use the Display List in Flash Player 8.5?

In my tests, Diesel uses less RAM, and uses less processor vs. using Sprites and the Display List.


How do I use it?

Simply import the classes into your project. I’ve done my best to match the syntax like the ActionScript 3 flash.display.DisplayObject syntax.

For example in ActionScript 3, if you want to create a sprite and show it, you do something like:

import flash.display.Sprite;
var my_sprite:Sprite = new Sprite();

Diesel’s code works on the same concept of seperating the object from the actual drawing. However, instead of adding your BitmapSprite, the Sprite equivalent, to the normal Display List, you instead create a BitmapSpriteDisplayObject, and add your BitmapSprites to it. The BitmapSpriteDisplayObject class is just a flash.display.Bitmap with optimized code to handle drawing BitmapSprites.

An example of creating a BitmapSprite, and showing it, just like you would create a Sprite to show it, is:

import com.jxl.diesel.view.core.BitmapSpriteDisplayObject;
import com.jxl.diesel.view.core.BitmapSprite;
// create your BitmapSpriteDisplayObject
var bsdo:BitmapSpriteDisplayObject = new BitmapSpriteDisplayObject();
// add it to the Display List so it's shown

// now, create your BitmapSprite
var my_bSprite:BitmapSprite = new BitmapSprite();
// and add him to the BitmapSpriteDisplayObject

You can add and remove as many BitmapSprites as you want. Additionally, you can create multiple BitmapSpriteDisplayObjects.



I am definately interested in contributions, suggestions, and/or criticisms. If you’re seriously interested in helping improve the engine so it performs like Andre Michelle wrote it, and/or taking Battlefield to another level, drop me a line in the comments, and I’ll hit you up with Subversion access.



Example of Diesel & Battlefield drawing sprites on a walkable map. Click once on the tiles to give focus, and then use arrow keys to move.

Example of Diesel loading tiles at runtime, extracting the bitmap data from a bunch of PNG’s, and drawing them to the map.


Source Code

Diesel & Battlefield Source Code

  • SVN
    username: public
    password: public
  • SVN
  • ZIP (beta1) Get latest build from SVN

Creative Commons License
This work is licensed under a Creative Commons Attribution 2.5 License.


Code Share: Real-time Code Sharing (like Pastebin)

As a contract developer, I work remotely a lot. Additionally, I share code with a lot of fellow developers across Instant Messeaging (AOL, Yahoo, MSN, IRC, etc.). One of the tools I utilize is called Pastebin. It’s a site where you can post code, and it’ll give you a unique URL. You can then send that URL other others via IM by pasting it in. They can then see your code that you pasted, formatted and highlighted all pretty (since Pastebin knows a bunch of programming languages). It even has diff support (to see differences in code if someone modifies what you posted). Quick, simple, fast.

Additionally, you can host Pastebin on your own site.

I wanted to see if I could do it in Flex utilizing Flashcom to enable it real-time. Although Pastebin is fast, it still requires you to do a page refresh to see the most up to date postings. Since Flashcom is push based, I can see code as it’s posted, real-time.

It doesn’t have diff support, but it does format ActionScript, Java, PHP, and Python using Igor Dimitrijevic’s phat Flash Text Formatter. Using Kevin Lynch’s deep linking, you can get a URL so you can send it to your colleagues’, and they can paste it into the browser and see your code that you posted.

Any comments, problems, or suggestions let me know!

3 days, 2 hours a night. I love Flex & Flashcom.

Code ShareUse App | Source Under Creative Commons (ZIP)

Known bugs:

  1. No code in there currently to get around Firewalls via HTTP Tunneling.
  2. Sometimes, Firefox’s URL does not update when you click on a code posting.
  3. Sometimes the view doesn’t change to show the code you just posted.