I am currently working on a Flash based iphone game code-named “pewpew”, which is maintained within my projects repository. As I have begun to work on it more and more, I decided that I wanted to have pewpew in its own git repository. This will make it easier to track issues, as well as give me the option of open sourcing it and allow others to create and submit forks.

Initially it looked like the way to do this was to use git submodules. However that seemed to keep the code linked to the original repository, which I did not want. I could have simply copied the code over and then initialized it as a new repository, but I wanted to maintain the commit history. Finally, I came across an article at GitHub titled Splitting a subpath out into a new repo. This does exactly what I needed (basically, create a new repository from a directory within an existing repository).

After following the steps in the article, I had to do one additional step before I could push the new repository to GitHub. I had to change the origin from the old repository url, to the new one. You can do this by changing the [remote "origin"] url property in the .git/config file to point to the new repository.

Anyways, this worked perfectly, and maintained the history. If anyone has any suggestions for other or better ways to accomplish this, please post it in the comments. Thanks for to everyone who had suggestions about this on twitter.

You can download the slides from here.

Btw, really great conference and vibe, and the speaker list was simply amazing. Congrats to Shawn and the FITC crew for putting on another great event.

Developer FAQ : Official FAQ which answers common questions about creating content for iPhone using Flash.

Why you should NOT care about building apps for the iPhone with Flash : Blog post I made which puts the announcement into the context of the other Flash Player 10.1 announcements.

Flash to iPhone : Excellent article by Veronique Brossier (who was on the private pre-release) going into deep technical detail about creating applications for the iPhone using Flash.

Flash on iPhone : My Experience : Blog post by Ben Garney (of pushbuttonlabs) talking about his experiences building the “Trading Stuff in Outer Space”" game for the iPhone using Flash.

Designing Flash Applications for the iPhone : Max session from Arono Gourdol from the Adobe AIR team, talking about designing content for iPhone applications using Flash.

Optimizing Flash Content for iPhone Applications Max session from Scott Petersen and Chris Brichford (two of the engineers who are working on the Flash to iPhone compiler technology), which goes in depth into how the toolchain works, as well as tips and tricks for optimizing content for the platfrom.

Designing and Developing for the Multiscreen web : Max session from Thibault Imbert (bytearray.org) talking about tip and tricks when developing for mobile devices.

I am also starting to work on a small project which works with pixel data from images, and on which I anticipate performance might be an issue when working with larger images. I figured this would be a good opportunity to use some of the early code as a case study. I wanted to post the process and results here.

The task that I will focus on is grabbing a palette of 16 colors from an image, created by averaging the colors within that image. Upon searching on google, I found a very good solution over at soulwire.co.uk, which I will use as the base for creating the palette. I want to point out that the original code targeted Flash Player 9 (and thus couldn’t take advantage of some things such as Vectors), and already ran pretty blazingly fast.

I am using Grant Skinner’s performance test harness to profile performance. Each test is run 50 times, and is tested in Flash Player MAC 10,0,32,18 (debug) in the browser.

You can download all of the code from here.

First, here is the original test case, based on soulwire’s code:

/*
	Code adapted from:
	http://blog.soulwire.co.uk/flash/actionscript-3/colourutils-bitmapdata-extract-colour-palette/
*/

package
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.geom.Rectangle;
	import flash.geom.Point;

	import com.gskinner.utils.PerformanceTest;

	public class PixelSort extends Sprite
	{

		[Embed(source="../graphics/image.jpg")]
		public var TestImage:Class;

		public function PixelSort()
		{
			addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
		}

		private var d:BitmapData;
		private function onAddedToStage(evet:Event):void
		{
			removeEventListener(Event.ADDED_TO_STAGE, onAddedToStage);

			var b:Bitmap = new TestImage();

			d = b.bitmapData;

			var perfTest:PerformanceTest = PerformanceTest.getInstance();
			perfTest.out = trace;
			perfTest.testFunction(run, 50, "averagecolors", "averagecolors");
		}

		private function run():void
		{
			var out:Array = averagecolors(d, 16);
		}

		public function averageColour( source:BitmapData ):uint
		{
			var red:Number = 0;
			var green:Number = 0;
			var blue:Number = 0;

			var count:Number = 0;
			var pixel:Number;

			for (var x:int = 0; x < source.width; x++)
			{
				for (var y:int = 0; y < source.height; y++)
				{
					pixel = source.getPixel(x, y);

					red += pixel >> 16 & 0xFF;
					green += pixel >> 8 & 0xFF;
					blue += pixel & 0xFF;

					count++
				}
			}

			red /= count;
			green /= count;
			blue /= count;

			return red << 16 | green << 8 | blue;
		}		

		public function averagecolors( source:BitmapData, colors:int ):Array
		{
			var averages:Array = new Array();
			var columns:int = Math.round( Math.sqrt( colors ) );

			var row:int = 0;
			var col:int = 0;

			var x:int = 0;
			var y:int = 0;

			var w:int = Math.round( source.width / columns );
			var h:int = Math.round( source.height / columns );

			for (var i:int = 0; i < colors; i++)
			{
				var rect:Rectangle = new Rectangle( x, y, w, h );

				var box:BitmapData = new BitmapData( w, h, false );
				box.copyPixels( source, rect, new Point() );

				averages.push( averageColour( box ) );
				box.dispose();

				col = i % columns;

				x = w * col;
				y = h * row;

				if ( col == columns - 1 ) row++;
			}

			return averages;
		}
	}
}

And here is the initial performance test:

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1264    25.28
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

First, considering what the code is doing, it is already pretty fast, taking only 25 ms to split the image into a grid, and loop through all of the pixels and averaging the values. However, there is probably some room for improvement, especially given that the original code targets Flash Player 9 and thus cant take care of Flash Player 10 optimizations such as using Vectors.

Now, the first thing I would normally do is to profile the SWF using the profiler in Flash Builder to find out where the most time is being sent. However, in this case, there are only two methods that do anything, averageColors and averageColor. averageColors is called once, while averageColor is called once for each swatch we want to create (in this case 16), and ends up looping over each pixel in the image (over those 16 calls). So these are the two areas we will focus on, with particular attention directed to averageColor.

The first thing I did was look at updating the content to Flash Player 10 by converting all of the Arrays to Vectors. I expected to get a decent boost from this, but the improvement was minimal.

Within the averageColors method, I looked at reusing the Point, Rectangle and BitmapData instances, instead of creating new ones on each iteration of the loop. Again, on the desktop this didn’t really make any difference. However, one thing to consider is that on a mobile device where memory allocation can be more expensive (and there is less RAM altogether), this change may have had a bigger impact (which I didnt test). This leads to an important point. It is important to test performance on the platforms which you are targeting, as some optimizations can have a different impact depending on where the content is running.

Next, I set the averageColor and averageColors methods as final, which allows them too be looked up at compile time (as opposed to runtime), this led to small improvement in performance, but again, not really anything significant.

At this point, I was getting a very slight performance improvement, but not really anything that mattered (basically, small enough to be insignificant),

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1224    24.48
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Next, I moved on to the averageColor method, where I expected (and hoped) to have better results, as this is where the bulk of the work occurs.

First I converter some of the Numbers to ints and uints in places where Numbers were not needed. This led to a small improvement.

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1190    23.80
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Next, I changed the bitmapData.getPixel call to use bitmapData.getVector. Doing this then allowed me to loop through the pixels using a single loop, instead of a nested double loop, and also eliminated a getPixel call for each pixel. I used a for each loop to loop through the pixel color values.

This provided another slight improvement (although not quite as much as I expected). We are now making some small gains.

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1137    22.74
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Next, I decided to try a for loop, instead of a for each loop.

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                               282     5.64
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Wow! As you can see, that makes a huge difference.

Finally, I explicitly cast i to an int when pulling the value from the Vector. This gave a small improvement, but again, nothing significant:

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                               268     5.36
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

I tried a couple of more optimizations in the method, around converting division operations to multiplication operation, and replacing Math.round calls but in this case it didnt make any difference.

I also looked at caching some constants used in some of the bitwise operations, changing

red += pixel >> 16 & 0xFF;
green += pixel >> 8 & 0xFF;

to

private var s16:Number = 16 & 0xFF;
private var s8:Number = 8 & 0xFF;

red += pixel >> s16;
green += pixel >> s8;

First, that optimization actually produces the wrong result (I had my operator precedence backwards). Second, it was actually slower:

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                               349     6.98
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

There are two lessons from this. First, make sure your optimizations produce the same results (ideally by creating and using unit tests). Second, bitwise operations are really, really fast. In this case, they are even faster than doing a variable lookup.

So, after going through the code, and applying a number of different optimizations, I was able to improve performance from an average of 25.28 ms, to 5.36 ms, an improvement of about 470%.

Here is the final code:

/*
	Code adapted from:
	http://blog.soulwire.co.uk/flash/actionscript-3/colourutils-bitmapdata-extract-colour-palette/
*/

package
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.geom.Rectangle;
	import flash.geom.Point;

	import com.gskinner.utils.PerformanceTest;

	public class PixelSort extends Sprite
	{

		[Embed(source="../graphics/image.jpg")]
		public var TestImage:Class;

		public function PixelSort()
		{
			addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
		}

		private var d:BitmapData;
		private function onAddedToStage(evet:Event):void
		{
			removeEventListener(Event.ADDED_TO_STAGE, onAddedToStage);

			var b:Bitmap = new TestImage();

			d = b.bitmapData;

			var perfTest:PerformanceTest = PerformanceTest.getInstance();
			perfTest.out = trace;
			perfTest.testFunction(run, 50, "averagecolors", "averagecolors");
		}

		private function run():void
		{
			var out:Vector.<uint> = averagecolors(d, 16);
		}		

		public final function averageColour( source:BitmapData ):uint
		{
			var red:Number = 0;
			var green:Number = 0;
			var blue:Number = 0;

			var count:int = 0;
			var pixel:uint;

			var pixels:Vector.<uint> = source.getVector(new Rectangle(0,0, source.width, source.height));
			var len:int = pixels.length;

			for(var i:int = 0; i < len; i++)
			{
				pixel = pixels[int(i)];

				red += pixel >> 16 & 0xFF;
				green += pixel >> 8 & 0xFF;
				blue += pixel & 0xFF;

				count++;
			}

			red /= count;
			green /= count;
			blue /= count;

			return red << 16 | green << 8 | blue;
		}		

		public final function averagecolors( source:BitmapData, colors:int ):Vector.<uint>
		{

			var averages:Vector.<uint> = new Vector.<uint>(colors, false);
			var columns:int = Math.round( Math.sqrt( colors ) );

			var row:int = 0;
			var col:int = 0;

			var x:int = 0;
			var y:int = 0;

			var w:int = Math.round( source.width / columns );
			var h:int = Math.round( source.height / columns );

			var p:Point = new Point();
			var rect:Rectangle = new Rectangle(0,0,0,0);
			var box:BitmapData = new BitmapData( w, h, false );

			for (var i:int = 0; i < colors; i++)
			{
				rect.x = x;
				rect.y = y;
				rect.width = w;
				rect.height = h;

				box.copyPixels( source, rect, p );

				averages[i] =  averageColour( box );

				col = i % columns;

				x = w * col;
				y = h * row;

				if ( col == columns - 1 )
				{
					row++;
				}
			}
			box.dispose();
			return averages;
		}
	}
}

Lessons learned

Profile content to isolate bottlenecks : I skipped that step in this case since my code consisted of only two methods, but even in that case, the most significant improvement came from a single optimization. Profile so you know where to focus your efforts.

Test and profile all optimizations : Make sure to test performance after each optimization, as optimizations do not always have the desired effect.

Test on target devices and platforms : Optimizations can have a different impact on where they are run. This includes browser, platform and device, as well as player type (debug vs release). For example, when testing directly from Flash Authoring, results where significantly slower than when testing in the browser.

Test the results of the optimizations : Make sure that your optimizations do not break your code or content. The best way to do this is by using unit tests and running them after each optimization.

There is still some potential for optimization. In particular, since the code is essentially looping over all of the pixels of a bitmap and then doing some math operations on their values, this could be a good candidate for porting to PixelBender.

If you have any additional optimizations, questions or suggestions, post them in the comments.

Also, make sure to check out soulwire’s blog, as he is doing some very cool stuff with ActionScript 3 and Flash.

You should NOT care about using Flash to build applications for the iPhone.

Hear me out on this. One of the major advantages of using Flash has always been that you can create your content, and then be confident that it will run consistently across different platforms and browsers. However, in the past, if you wanted to deploy to mobile platforms or devices, you would have to target a different player (most likely based on Flash Lite), which lagged behind the capabilities of the desktop player. However, the fragmentation between desktop and mobile players is about to change.

I think the biggest news out of Max last week was not the Flash applications for iPhone announcements, but rather the unveiling of Flash Player 10.1. Not only will Flash Player 10.1 run across desktop operating systems and browsers, but it will also be available on the newest generation of smart phones. This includes Palm Pre, as well as Android and RIM based devices. Furthermore, the iPhone work, as well as Adobe AIR 2.0 are both also based on Flash Player 10.1.

Thus, not only will you be able to create content and target multiple browsers and operating systems, but you will also be able to target mobile devices, as well as desktops.

Now, it is important to remember that devices, such as the Palm Pre and iPhone have significantly slower processors and less memory, as well as smaller screens than desktop machines. However, if you design and develop with these limitations in mind, then you will be able to leverage you content anywhere that Flash Player 10.1 is available.

Furthermore, if you are leveraging functionality that is only available on a subset of devices, then of course, your content can only leverage that functionality on devices where it is supported. This is the same as on the desktop when using APIs to access the user’s microphone and webcam. If the target platform supports the functionality then you can use the APIs to access that functionality. (The Flash Player includes APIs to check at runtime if specific functionality is supported on any particular target platform).

The important thing is that the Flash Player exposes the APIs across platforms in a consistent manner. So, for example, if you want to use multitouch functionality in Flash Player 10.1, then you will use the same APIs regardless of whether your content is running on the desktop, in a browser, on the iPhone, the Palm Pre, etc…

For the past couple of months, I have been working on a gamed called “Pew Pew”. I originally developed it by targeting the browser, but knowing that I wanted to deploy it to the iPhone, payed attention to performance, and sized the content, and designed the user interactions appropriately. Once the iPhone work was at a point internally that I could deploy content to it, I was able to run my content on the device with no changes at all. Now, I did have to do some additional code optimizations to bring the frame-rate up (something which benefitted the game on the desktop as well), but once I did these, the SWF for my game was able to run on both in the browser on my desktop and as a standalone iPhone application. Indeed, the team working on Flash Player 10.1 for Android asked if I could send them the SWF, and it ran on that device as well with no modifications. This was possible because Flash Player 10.1 allowed me to target the capabilities that my game needed, as opposed to targeting a particular device.

So, to summarize, when developing content targeted at Flash Player 10.1, you should think in terms of the capabilities of the platform, and not get hung up on a particular device or browser.

Creating applications for the iPhone is great. But creating content for the iPhone, and having the option to deploy it on an Android, RIM or Palm Pre device, in a browser on Mac, Windows, Linux and Solaris, and being able to deploy to the Mac, Windows and Linux desktops via Adobe AIR 2.0 is even better.

So, what exactly did we announce?

The next version of Flash Authoring will enable developers to create stand-alone iPhone applications using Flash technologies (including ActionScript 3). These applications are just like any other iPhone application and can be distributed via the Apple iTunes Application store. Indeed, there are already a number of applications created with Flash on the store today.

One thing I want to stress is that this is for standalone applications, and is not the Flash Player for mobile Safari (which is something we continue to work on). The end result is a native iPhone application, and not a SWF that runs in the browser. We compile the SWF to a native application using LLVM. There is no requirement for the Flash Player / Adobe AIR Runtime to be installed on the device or included in the application. The end result is a native iPhone application.

Currently, this project is in private beta, and we plan to release a public beta of Flash CS5 with support for building iPhone applications before the end of this year. We are not accepting any new people for the private beta, but you can sign up to be notified when the public beta is available.

We have posted a developer FAQ on labs, which addresses a lot of the questions we expect you will have (we will continue to update this as necessary). The FAQ also includes some information that will be helpful if you want to start working on some content in anticipation of the public beta.

One thing that I really want to stress though, is that developing for the iPhone is mobile / device development. The iPhone has a significantly slower processor and less memory than what can be found in a typical desktop computer. As such, existing content may need to be optimized for performance, and / or user interactions (given the smaller screen and different UI metaphors). So, design and develop content with these limitations and differences in mind. Fortunately, we have done some things in the compiler, including enabling support for hardware accelerated rendering, to help with performance. Expect more information on this, and other optimization strategies once the public beta is available.

I am sure there are a lot of questions. As I mentioned above, we have created a developer FAQ that should address a lot of the most common questions. We have also created a forum for discussion of the announcements and technologies. Please feel free to also post any questions in the comments here.

Here are some additional resources:

• Flash Applications for iPhone on Labs
• Developing for the Apple iPhone using Flash
• Developer FAQ
• iPhone forum

Finally, if you are attending Max, we have a number of sessions which will cover building iPhone applications using Flash. I will make another post with information on those shortly (my session will be a general Q & A session on building iPhone applications with Flash).

This was built using the new Microphone Access APIs coming in the next version of Adobe AIR (code named “Athena”). Some more info here.

Lots of info on Athena and other new technologies at Adobe Max 2009.

Pixel Mesh graphics created by eboy.

I have posted the slides for the session, which you can grab from here.

You can find most of the libraries and code I discussed on the as3corelib library page (look in the com.adobe.air package).

Marc Hibbins has notes on the session here.

Well, yesterday, FITC posted all of the video sessions from FITC Toronto, and I spent some time watching Lee Brimelow’s presentation on working with ByteArrays. It is a really great session, that provides a clear and solid foundation and understanding of working with ByteArrays and bits and bytes.

Anyways, after watching Lee’s session, it all finally clicked for me, and I spent some time last night putting together a simple parser that would dynamically load and display a 24Bit BMP image file within Flash.

I wanted to post the code below, along with complete comments, in order to provide a simple, real world example for anyone else interested in learning how to work with lower level file formats.

The code requires Adobe AIR (so I can load the BMP directly). In order to convert to the Flash Player in the browser, just replace the File loading with FileReference.browse.

package
{
	import flash.filesystem.File;
	import flash.filesystem.FileStream;
	import flash.filesystem.FileMode;

	import flash.display.Sprite;
	import flash.display.BitmapData;
	import flash.display.Bitmap;
	import flash.utils.Endian;

	import flash.geom.Rectangle;

	[SWF(width='550', height='400', backgroundColor='#FFFFFF', frameRate='12')]
	public class BMPViewer extends Sprite
	{
		private static const MAGIC_NUMBER:String = "BM";
		private static const BMP_DATA_OFFSET_POSITION:int = 0xA;
		private static const WIDTH_POSITION:int = 0x12;
		private static const HEIGHT_POSITION:int = 0x16;

		public function BMPViewer()
		{
			loadBMP();
			super();
		}

		/*
			Loads and reads a 24 Bit bitmap file.
			
			Based on BMP info from:
			http://en.wikipedia.org/wiki/BMP%5Ffile%5Fformat
		*/
		private function loadBMP():void
		{
			//Load BMP. This requires AIR.
			//Use FileReference.browse for
			//Flash Player
			var bmpFile:File = new File("app:/image.bmp");
			var fs:FileStream = new FileStream();

			//BMP files are Little Endian, which means their
			//least significant byte is first (right to left)
			fs.endian = Endian.LITTLE_ENDIAN;

			//open the file in READ mode
			fs.open(bmpFile, FileMode.READ);

			//check the first two bytes to make sure
			//it is a valid BMP file
			if(fs.readUTFBytes(2) != MAGIC_NUMBER)
			{
				trace("FAIL : NOT A BMP FILE");

				//not a BMP file, close steam
				//and exit
				fs.close();
				return;
			}

			//note, we could also grab the length from the 
			//header and make sure the file was the correct
			//length

			//change the cursors position to the point
			//in the header that contains the value / offset
			//of where the actual bitmap data begins
			//read in the 4 Bytes that contain the value
			fs.position = BMP_DATA_OFFSET_POSITION;
			var dataPosition:int = fs.readInt();

			//set cursor position to where the BMP
			//width is stored
			fs.position = WIDTH_POSITION;

			//read in the 4 Bytes that contain the width
			var bmpWidth:int = fs.readInt();

			//read in the 4 Bytes that contain the height
			var bmpHeight:int = fs.readInt();

			//set cursor to where the BMP pixel data begins
			fs.position = dataPosition;

			var row:int = 0;
			var column:int = 0;

			//every row length in a BMP file must bee a multiple
			//of 4 (see the spec). So, we need to determine how much
			//padding we need to add at the end of each line. 
			var padding:int = (bmpWidth % 4);

			//create a fixed length Vector to store the pixel
			//values as we read them.
			var pixels:Vector.<uint> = new Vector.<uint>(bmpWidth * bmpHeight, true);

			//loop through data (rows and columns)
			//note that data stored in BMP is backwards to Flash and is
			//stored from bottom row up, not top row down.
			//So we have to loop backwards
			var counter:int = 0;
			for(var i:int = bmpHeight; i > 0; i--)
			{
				for(var k:int = 0; k < bmpWidth; k++)
				{

					var position:int = ((i - 1) * bmpWidth) + k;
					/*
						This is the original code that I had which works fine
						but is not as effecient as what I have now.
						
						Basically, Pixels are stored within 3 sucessive Bytes
						in a BMP file, with one Byte each for Blue, Green and
						Red values (in that order).
						
						So, this reads the Bytes for each pixel, one at a time
						and then combines them into a single value which is
						the combined RGB pixel value.
						
						I left the code as I think it make it a little easier to
						understand what is going on, as well as how some of these
						calls can be optimized.
					*/

					/*
					var blue:int = fs.readUnsignedByte();
					var green:int = fs.readUnsignedByte();
					var red:int = fs.readUnsignedByte();
					
					pixels[position] = (red << 16 ^ green << 8 ^ blue);
					*/

					/*
						Here is the final code which is more efficient, as it only
						needs to make 2 read calls in order to get the values.
						
						Thanks to Thibault Imbert (bytearray.org) for pointing out
						and helping me understand the optimization.
					*/

					//bytes in file are in Blue, Green, Red order
					//int is 32 bits (8 bytes). So, we store the first two bytes of the pixel
					// (which contain the Red value), and
					//then shift everything over 1 byte (8bits) to make room for
					//the green and blue values (remember the file is little endian), which we
					// then write into the int in the right position
					//The final value has the colors in the correct order (Red, Green, Blue)

					var pixelValue:uint = fs.readUnsignedByte() | fs.readUnsignedShort() << 8;
					pixels[position] = pixelValue;
				}

				//we are at the end of the row, so now we have to move the cursor
				//forward so it ends on a multiple of 4
				if(padding)
				{
					fs.position += padding;
				}
			}

			//done reading file, close stream.
			fs.close();

			//create a Rectangle with width / height of Bitmap
			var rect:Rectangle = new Rectangle(0, 0, bmpWidth, bmpHeight);

			//create the BitmapData object to hold hold the BMP data.
			//we do a red fill here so it is easier to see if we have any errors
			//in our code
			var bmpData:BitmapData = new BitmapData(bmpWidth, bmpHeight, false, 0xFF0000);

			//copy the BMP pixel data into the BitmapData
			bmpData.setVector(rect, pixels);

			//create a new Bitmap instance using the BitmapData
			var bitmap:Bitmap = new Bitmap(bmpData);
			bitmap.x = 10;
			bitmap.y = 10;

			//add Bitmap to the display list
			addChild(bitmap);
		}
	}
}

You can download the example from here.

Thanks to Lee for his presentation, and Thibault Imbert who helped me understand some of the details around endianes, as well as made some suggestions for optimizations.

If you are interested in learning more, I strong suggest watching Lee’s FITC Presentation.