Mar 182011
 

Getting assets (such as images and sound files) into your AS3 project can be simple, but I ran into a few problems (and nice solutions!) that might help others out too. I thought I’d jot it down into a blog post!

How I used to do it

I use FlashDevelop, and I try to avoid using the Flash IDE for development. I found it incredibly handy, though, that I could copy any asset – even vector art – with a simple drag-and-drop into Flash, and export the whole bundle as an .SWC file.

FlashDevelop is awesome handling SWC files; a simple pair of clicks gives you full access not only to the assets, but any sub-classes and properties the assets may have (as imbued by Flash itself). It’s quite awesome, and it’s how I’ve done everything to-date.

The Problem

There are a few downsides to Flash’s SWC asset library:

  1. Porting to other platforms or languages (that don’t support Flash files) is a pain in the butt; without SWC support you have to re-invent your asset importing routines for each platform.
  2. Even when sticking with Flash, importing assets into Flash that you’ve already separated out into individual files can be annoying and tedious (as opposed to developing all your assets within Flash or Illustrator)
  3. You need to own a copy of the Flash IDE (the Professional version, too, if you want to make commercial projects)

The first item on that list is the one that bugged me the most. No other development environment has a standardized equivalent to the SWC Library; converting your game to any other platform or language suddenly gains an extra hurdle, and requires exporting of assets and all sorts of hoop-jumping.  I know this first hand; there was some problems creating the mobile editions of Steambirds.

When I look at various Flash blitting/game engines, such as Flixel and FlashPunk, and they tend to support sprite sheets, image file imports, and other such “industry standard” ways of doing things. Converting from these engines to – let’s say, iPhone – will be a whole lot easier.

There’s just one little thing standing in the way of me following in their path…

I hate SpriteSheets

SpriteSheets were invented by old console programmers that couldn’t manage their assets with the hardware they had. Instead of making large images, they’d break everything down into sprites – dump them all into a single crammed-in file, and re-construct environments piece-by-piece. This is what gives Super Mario Bros. that square look, and why so many games seemed to be built on a grid.

SpriteSheets nearly require you to make all of your assets the same size, and even if you don’t: Any time you save managing dozens of tiny files will be made up in creating a lookup table (or a map) to your spritesheet.

Alternatives?

Well, the standard way is to “simply” use three lines of code to “Embed” each graphic file – at compile time – to your Flash application. I’d love to do this, but I have over 200 files to import!  That’s a lot of typing!

Some helpful Twitterites suggested I might want to look into streaming the files off of a server – but that brings up bandwidth and offline-compatability concerns (but is otherwise a great idea).

Whatever am I to do?!

@ChevyRay to the Rescue

Chevy, the best thing to happen to GDC 2011, took it upon himself to whip up an AIR application that automatically generates all my Embed tags for me, and stores them into a centralized art asset file!

Download his quick-n-dirty tool here: chevyray.com/stuff/AssetBatcher.zip

It did exactly what I wanted it to, simplified a lot of work, and has made my future projects even more cross-compatible with other platforms (and easily portable to other languages).

Thanks Chevy!! <3

  7 Responses to “Embedding Assets in AS3”

Comments (7)
  1. Nowadays, we use “atlas textures” to minimize context changes in the rendering pipeline. When you hit the graphics hardware acceleration layer, this can make a profound difference in performance. But for software based blitters, it doesn’t matter much.

  2. Oh my god this is perfect! Thanks for pointing it out, and thanks to Chevy for creating such a great tool.

  3. Chevy you rock! This is totally handy as I’ve definitely been in this exact same situation many times before. I used to do it with a special .bat file and a macro in my notepad++ text editor.

    One thing: spritesheets are actually still the industry standard today due to the fact that is makes for faster rendering on 3d hardware: you don’t have to change textures to render multiple 3d objects and this has a very significant effect upon framerate. The technique isn’t going to go away any time soon. A second reason why many sprites in one image is better than many smaller images is when you download them from a server. Everyone knows that downloading 100 1k png files is waaay slower than downloading one 100k png file.

    Also, the sprites in a spritesheet don’t need to be square, or the same size: your lookup table can have special coordinates for each sprite, so you can mix big and small in one sheet no problemo. Many bitmap fonts are done this way to save space by not fording a “i” to use as many pixels as a “w”.

    Various utilities such as TexturePacker do this for you, by stuffing as many sprites into any given space without regard for square-ness and without forceing any particular set of dimensions for each sprite. So it can handle big 800×3000 sprites with 2×2 pixel buttlets in one spritesheet and outputs the coords as an array in code.

    Thanks for the handy utility!

  4. LOL my favourite typo of the year: “buttlets” vs “bullets”. =D

  5. Just downloaded it to check it out, awesome tool. It would be amazing if there was some customization to it to alter what the class name would be, such as all upper case, camel case, adding your own bit to the beginning such as “GRAPHIC” + classname, “AUDIO” + class name, etc, but what’s here is fantastic as is.

  6. Just wanted to expand a little on what Robert Morgan and Breakdance McFunkypants said about textures.

    3d hardware requires POW2 texture sizes. When you load a image asset that is less than the POW2 requirement, a texture surface is created that is rounded up to the next power-of-two.

    E.g. For a 96×137 (width x height), the next pow2 texture size that accommodates the texture is 128×256. (96 * 137) / (128 * 256) = 40%. That is, the image only occupies 40% of the texture and 60% is wasted.

    Those numbers come from a real-life scenario of a card game being ported to the iOS. Each card was 96×137 and there were 61 cards. By packing all of the cards onto a single sprite sheet, they reduced their memory foot print by half!

    So please don’t hate on sprite sheets.

  7. Like you I was long time fan of SWC’s, although to use the AS3 Starling framework swc’s become redundant. Embeding everything seemed like a nice way to bypass the additional setup time of spritesheets, However there are memory issues in iOS apps when using this approach, where all assets instantly take up memory the moment they are embedded. See this post for more information. http://forum.starling-framework.org/topic/problem-with-embeding-many-bitmaps

    As a result there is a requirement of a Loader class to be attached to assets to manage memory more efficiently.

Sorry, the comment form is closed at this time.