Idaho Airships, Inc.

BitmapData Objects (Instantiations of the BitmapData Class or custom Classes that extend it) are what we as aerial and technical shooters use to fundamentally control our bitmap images in Flash. Even moreso than some of the advanced Display List, logical and syntactic mechanics of ActionScript, photographers who play Flash need to know BitmapData Methods and Properties intimately.

Perfectly situated in the flash.display Package.

Just for the sake of clarity, the BitmapDataChannel Class extends the Object Class and is used in very rare applications involving Channel (Red, Green, or Blue) operations.

The Bitmap Class provides the functionality to add bitmaps to the Display List (causing them to be rendered on the Stage). It extends the DisplayObject Class and can wrap only .jpg, .png, or .gif bitmaps. BitmapData Objects are attached to Bitmap Objects using the Bitmap Object’s bitmapData Property.

It is the BitmapData class that…well…deals elementally with the “data” in a bitmap, allowing the practitioner access to and control of the very pixels of a bitmap. That level of control will shock you (I keep saying that Flash is “deeper” than Photoshop…).

As with most of my posts, the basics are left to your own study. There are some Methods and Properties of the BitmapData Class that are of peculiar interest to working with photographs (making them “dance”) in Flash that we’ll deal with in subsequent post.

BitmapData Objects are limited to 2880 pixels in width and height, which can prevent some extreme spatial manipulations (there are some clever workarounds). BitmapData Objects offer four data channels: Red, Green, Blue, and Alpha (transparency).

Here’s our demonstration image: An aerial of the Huntsman Cancer Center on the University of Utah campus in Salt Lake City, Utah.

I’ve imported a .png of this image into my Library ensuring that “Export for ActionScript” and “Export in first frame” are both checked in Linkage Properties. Flash will graciously generate a Class definition for me, but I made my own custom name for the Class and changed the first letter to upper case.

Easy enough-now we have an embedded .png. Note that when we imported the .png into our Document Library Flash defaulted its Base Class to BitMapData.

Our next step is to construct an Instance of that Class.

It’s important to note that we Instantiated the BmpDataDemo Class that Flash constructed for us when we Imported our .png bitmap into the Libray. We did not Instantiate the BitmapData Class- it wouldn’t have any relationship to our .png if we did. Think of the embedded .png as the “bitmap data” you are dealing with-nothing more than an Array of meta- and pixel datum.

In order to add the bmpDataDemoInstance Instance of our BmpDataDemo Class (make sure you can follow that…) to the Stage, we’ll add it to an Instance of the Bitmap Class as the bitmapData Property of that Instance.

For clarification, let me restate the strategy:

1. I embedded (added to the production, in simple terms) the .png by importing it into the Document’s Library. When we did that, Flash constructed a BmpDataDemo Class from the .png Object (I customized the default naming).
2. I then Instantiated that BmpDataDemo Class as the very appropriately titled bmpDataDemoInstance. I specified the width and height parameters of the Instance (I didn’t need to be specific about that, but an explanation would clutter this post).
3. I constructed a new Bitmap Object, bmpDemoInstance. Remember that the BmpDataDemo Class extended the BitmapData Class, which extends the Object Class. In that genealogy there is no DisplayObject, so as yet we have no standard way to get our .png on the Display List.

If we add our Bitmap Class Instance, bmpDemoInstance, to a DisplayObjectContainer on the Stage, it will be rendered by the Flash Player and appear on our Stage.

Stage, Stage, Stage…

So…what to use for a DisplayObjectContainer?

Well…I suppose there’s always the Stage!

We end up with…

That’s our .png displayed in the Flash Player!

Wouldn’t it have been easier to simply import the image into the Library and work with it in the IDE? In short, yes…if you are working with a very small and simple production, the IDE probably is the best tool (particularly if you don’t want to get involved with ActionScript). However, the IDE does not offer the degree of control and interactivity that the API/ActionScript does, and to make our images “sing and dance” we’re going to need that control and interactivity.

There is also an issue of working with large numbers of images. I don’t know where the “Break Even Point” is with respect to batch processing assets, but ActionScript does have a variety of tools for automating the construction of you application, the least of which are not the Array Class and Conditionals. While it may seem senseless at this point to involve yourself in lines of code to do what could be done in a single Drag & Drop operation, the downstream capabilities are the real goal-not simply getting an asset to display.

If you think about this as a very mechanical process with well defined steps and modular assets, it makes very good sense. Really, our present tactic is to simply acquaint with the logic of AS.

L