During the Global Game Jam, someone leaning over my shoulder remarked on how quickly I was able to dump audio into my game. I’ve gotten quite a few requests for my audio handling library, so I thought I’d make it publicly available here.

I’m no audio expert, and it’s very simple, straight-forward, and to the point. I’m sure it’ll work fine for basic needs, but if I made any huge mistakes or anything… Let me know! I’m still learning too.

RadialSound works seamlessly with any AS3 build, including AIR builds for iOS and Android, but I’m mostly saying that because mentioning “iOS” in my posts increases my web traffic by quite a bit. :3

The File

Instead of quoting all the source I’ll just link to the class I’m currently using, here. I named the file “RadialSound,” to give it a unique-but-short name, and also I’m a big grown up with my own company (Radial Games).

Personally, all of my utility and commonly-used references are in their own simple, flat, one-level folder. I then use FlashDevelop to import that folder via the Project > Properties > ClassPaths window. This allows me to share all of my common code easily across projects, without having to do all that “com.andymoore.crap.”

You don’t have to get all fancy, though; to use this file, just drop it into your project’s root source directory. That works too.

Setup

RadialSound uses a static instance to work across your entire application, but first you’ll need to initialize it. This can be done anywhere in your code, probably near the beginning/first boot of your application:

new RadialSound();

Then you just have to tell RadialSound what audio bits you want to have access to. It’ll accept URLs to audio files (good for streaming in long Mp3s), generic classes for embedded audio, or specific classes from a compiled source (such as SWC libraries of assets). We do this via the “storeAudio” interface, which wants both the class and a label to identify it later:

// Stream an Mp3 in from a web server

RadialSound.storeAudio("track1", "http://test.com/music.mp3");

 

// Standard audio file embedding:

[Embed(source = "fireGuns.wav")]

private var fireGuns:Class;

// And recording that in RadialSound:

RadialSound.storeAudio("fire", fireGuns);

I’ve always been conscious of SWF file size and of bandwidth consumed; you don’t want everyone that loads your SWF file to have to [at least start to] download six tracks of music before they can see the main menu.  What if the majority of your players never make it to track 5? Why waste all that bandwidth? And why annoy players with large .SWF file sizes, too?

You might as well host as much of your audio seperately as you can, and load it on-demand. If you have a particularly popular game, storing your music tracks on cloud-hosted servers (like Amazon S3) might be a good idea too.

To help work with these solutions, I’ve added some extra functionality to the storeAudio interface. By default, it will simply store the URL of your externally-hosted music, but not actually start to stream it into your application until it is actually requested for playback. This can result in a half-second (or worse?) delay in playback, though. You can override this behaviour and force-load assets immediately, if you wish – useful if the exact timing of the sound is important (at least for the first playback):

// Final bitflag determines streaming time

RadialSound.storeAudio("track1", "http://test.com/music.mp3", true);

 

There’s a bit more functionality in there, but I’ll leave it for you to discover.

PlayBack

Now that we’ve told RadialSound what exists, playing them back is simple:

RadialSound.playMusic("track1");

RadialSound.playSound("fire");

I’ve separated music from sounds for a couple of reasons: music will loop indefinitely by default, and will immediately change tracks when you feed it new input. Audio on the other hand will allow 10 (number tweakable) sounds to be playing at any given time – the oldest sound getting bumped for any new requests.

There is also behaviour in the class to mute/unmute all sound, and even a quick and simple way to pass it an art asset and have the class build the mute button for you. Explore! The file isn’t all that big, and is pretty self-evident. :)

All in all, it’s anything you could want from a simple flash audio player.

Again, download link RIGHT HERE to RadialSound.as. Let me know if you improve upon it!

Shawn Blais taught me all I needed to know about mobile optimizations of my AS3 code. His blog only has a dozen or two articles, but they are chock-full of interesting information (and even sales figures!). The most useful stuff for me, at this point, is the graphics pipeline optimizations.

The thing that ties the following three steps together is one unifying theory: use bitmaps for everything. You can start with MovieClips and vector Sprites, and you can even stick with Flash’s DisplayList to keep things organized. But the actual image data? Bitmaps! Always bitmaps.

Step One: Use the GPU rendering mode

When designing a mobile application, you’ll have an “application.xml” (or similarly named) file that contains all sorts of nice settings. One of those is going to tell the mobile device whether to render using the CPU or the GPU. Most defaults (including the FlashDevelop template file) will point you to CPU, and that may be fine for flash’s standard vector art. Switching to bitmaps and the GPU setting will give us much better performance.

Open up application.xml and make sure this exists:

<initialWindow>

<renderMode>gpu</renderMode>

</initialWindow>

(source article is same as step 3)

Step Two: Lower the Stage Rendering Quality

AS3′s stage-rendering quality setting determines how vector art (probably your “Sprite” and “MovieClip” classes) is rendered. The thing is, even with a low setting, the stage still respects your bitmaps “smoothing” flag and draws it without any discernible difference. No need to spare the CPU cycles on something we aren’t using!

stage.quality = LOW;

If you have vector art you are loading and converting during runtime (see step 3), AS3 even lets you change the stage quality on the fly! Just use this:

stage.quality = HIGH;

convertMySprite(); // Or whatever your function is

stage.quality = LOW;

(source article)

Step Three: Use Bitmaps, and Cache them

This is probably the best performance-enhancing-drug my mobile apps have used so far, but it only gets the big performance gains if you use it in conjunction with Step 1 (GPU render mode).

The basic idea is to take all of your image data, and cache the bitmap data only once - dynamically – to a dictionary reference.  In GPU render mode, this stores the data as a texture in GPU memory on the mobile device. As long as all duplicate images are pulled from the original data, no new memory is used and creation of new graphics is lightning fast.

This works particularly well for common images used frequently – say, badguys, bullets, and common tiles. But I use it for everything!

Shawn’s original article laid out some source code and a longer explanation if you want to get into details and performance charts. His code does all of the conversions automatically for you, and the discucssion in the comments of his article improved upon it. I added a few tweaks myself, and it is now the only class I use for any type of image data. Imported .PNG file? Sprite or MovieClip in a .SWC? Class reference to an object you custom made? Doesn’t matter! All automated, all quick, all easy to use. Best of all: the code is really short, simple, and easy to read in about a minute. 

It’s a bit too long to paste here, so here’s a link to the class I use right now. Feel free to use it, just let me know if you improve on it :) Copy and paste it to the root of any project and you should be able to start using it right away.

(source article)

Bonus Step: Convert MovieClips on the fly

I haven’t tried this step out yet, but it’s an extension of the class I offered up in Step 3: automatically convert each frame from a MovieClip to cached bitmap data (and store that stuff in the GPU). If I had animations in my most recent games, I would be all over this too!

The Drawbacks

The biggest drawback I’ve found with the GPU-rendering mode is that you lose your runtime access to all filters and blendmodes. If you want to put a nice glow filter on a flame graphic, it’s easy to pre-bake that. But dynamically adding things – like adding a stroke to a font – are pretty hard to workaround (using system fonts, as opposed to spritesheet based font rendering). Hit me up if you have trouble with these, I’ve found some solutions (but not all).

A secondary detriment is that a complex DisplayList will slow down your app a bit more than usual. Try to avoid nesting that goes too deep. But you were doing that already, right? ;)

A compounded drawback here is that GPU-rendering isn’t available on your desktop (without Stage3D routines). That means when you do a test-run of your mobile app on your desktop, you will still see your filters and blendmodes, which can lead to some confusion, particularly if you’re porting a complex app written for desktop use.

The Gains?

The most complex scenes I’ve created with these methods run beautifully on my two-year-old Nexus One. I ran an hours-long performance test on my iPad – constantly drawing new moving objects to the screen (and never removing them). Though things (understandably) dropped to about 3FPS after quite a while – memory usage was nominal and the app never came close to crashing.

Most importantly, and this is a pretty big thing: this performance boost is BETTER than what you get from blitting on a mobile device. That means following those 3 basic steps will give you better performance than Flixel and FlashPunk’s default rendering engines.

In many cases, it’s possible for your mobile devices to outperform your desktop thanks to the direct GPU access. Hopefully this will change with Stage3D? Until then, blitting engines (like Flixel and FlashPunk) are probably your best bet for desktop and browser performance.

For all sorts of performance charts and figures, stress tests and numbers, check out Shawn’s posts (linked in the respective steps above). He sees up to a 4000% speed boost.

I’ve gotten a lot of EMails over the last few days demanding to know how I can make mobile games on a PC.  Some ask about Android, most ask about iOS, and everyone is all jaw-agape that AS3 code runs on these devices in some sort of native format (as opposed to in a browser instance).

Then they get all wobbly in the knees when they figure I’ve done it using completely free software.

There are plenty of (IMHO: Over-complicated) tutorials out there, and my knee-jerk reaction is to just … well, LMGTFY. After all, I didn’t divine this knowledge myself; it came with a  bunch of research, and thankfully following the path of other people.

I think I can simplify most of the tutorials though. Check it out.

Step 1: Boot up your PC.

These steps are for Windows operators only. The software listed here doesn’t play well in Apple environments, but then again, Apple users don’t have a lot of the iOS-related problems I do in the first place.

Step 2: Install FlashDevelop.

When I say “install FlashDevelop” I mean for you to install the latest version (4.0.1 RTM at the time of this writing). This is important: the next few steps don’t make any sense if you go even 1 version older. Also, don’t mess around with the default install folder, and don’t mess around with what sub-components are selected in the installer.

FlashDevelop is a development IDE, similar to Flash CS or FlashBuilder, except this one is free. After it installs, it also goes ahead and installs the Flex SDK (free flash compiler) and the Air SDK (the magic bit that makes it work on phones) automatically for you, and then links it all up internally – saving you like 4 dozen more steps.

Step 3: Start a new project in FlashDevelop.

This one’s easy. Open up FD, select “NEW PROJECT” from the “Projects”  menu, and select “AIR Mobile AS3 App” from the list of templates. This is the magical step that will auto-generate for you a bunch of instructions, batch files, certificate directories, and everything else you’ll need to get going.

You don’t need to even bother writing a quick “Hello World” application, as this template should compile immediately for you. Just hit up “Project > Project Properties” and give the app a bright pink background, then hit F5 and watch it run on your PC.

Yup, at this point, only at Step 3, you’ve already got your mobile-device-simulator installed (a cheap AIR projection version anyway), and you can start developing your application.

Step 4: Follow the included instructions.

The best part about FlashDevelop’s mobile project template is that it includes two text files in your project directory:

• AIR_Android_readme.txt
• AIR_IOS_readme.txt

They’re both around 6-steps long, and in painstaking detail (with web links, references, and cited blogs) tell you exactly how to get your app working on your mobile device.

After following those instructions, you’re DONE! That’s it! You are now making games that compile and run on the precious iPads of the world.

Now, those extra text-file steps can be easy (if you’ve setup certificates and things before, or have your phone drivers installed), or they can be new and intimidating. So I’ll outline some of those steps here. I’ll start with Android to give you a baseline of what the experience could be like:

Step 5: Install your Android USB Drivers.

There’s a link included right in the readme file to a website that just asks “What kind of phone do you have?” and points you to the appropriate download location. Easy as pie.

Don’t forget to turn on “Debug mode” on your android phone at this point (Settings > Applications > Development menu).

Obviously you only need to do this once.

Step 6: Generate an Android Certificate.

FlashDevelop automatically made a “generateCertificate.bat” file in your project folder. Run it. Yes, it’s that easy. And yes, this only has to be done once as well.

Step 7: Run the game on your Android Device.

Plug your Android phone into your (rear) USB ports, then edit “run.bat” in your project folder. There’ll be a little commented-out section that says:

goto desktop
::goto android
::goto ios

Just comment out the desktop line, un-comment the android line, hit F5, and BAM.

You’ll see your game fire up on your Android device.

I am serious, it is REALLY that easy.

Step 8-ish? iOS Steps?

iOS setup is a teensy bit more work; it requires the installation of Open-SSL (or an equivalent if you don’t already have one installed) for certificate generation. And it requires you to pay $99 to Apple if you haven’t already, and requires you use their development portal to generate keyfiles and things called “mobile provisions.”

You see, Apple is terrified you will take a compiled application, and put the .IPA file up for sale on your own website – circumventing their internal app-store. To get around this, they require that all your beta/in-progress software specifically list each device you are intending on testing it on. The only way around this is to sell the app through the app-store.

A “provisioning certificate” is an encrypted file that contains all the unique device IDs, and your unique game ID, all in one place. When you compile you’ll need this certificate.

But, you only have to do all that setup once, and not necessarily per-project. And again, those steps are clearly detailed in the included readme file. Take it step-by-step and you won’t mess anything up.

The final step here could be you installing iTunes, and trying to install your app there and transferring it to your iDevice. I highly recommend signing up for TestFlight instead; it’s totally free, and it removes a dozen headaches and makes this whole step way easier, and allows you to easily distribute the builds to your partners/beta testers. I don’t even have iTunes installed on my development laptop.

Selling your Game

For Android, there’s not really any extra steps here; just upload your finished product to the marketplace. Done!

For iOS, there is one unfortunate final step. Apple decided to remove their webpage-based upload-to-app-store feature several months ago; you do need (at this time) access to a Mac simply to upload your .IPA file to the developer portal. But that’s all it is: uploading a file. If you have any friends that own a Mac, you can just beg/plead them to do it for you; or maybe by the time you are reading this, us PC developers will have finished writing another work-around.

Frustrating, I know, and I hope this won’t be a problem for much longer.

To sum up,

It takes 3 very easy steps to get started developing mobile apps.

It takes 3 additional (very easy) steps to get starting pushing it to Android devices, or 5 additional (annoying) steps to get it pushing out to iOS devices.

And one final step to sell your application in the marketplace.