Software Engineering Explained (click for full size)

An old picture that is passed around by Software Engineers, but is worth repeating.

One of the biggest reasons to go to Actionscript 3.0 is a massive performance boost you gain from older versions of Flash.  Michael James Williams sent me this link to a forum post to prove the point:

Over 5000 Arrows at 30 fps

Mike Grundvig posted on his blog how he got this to work and after reading it over twice, it is very “old school” in how it is accomplished.

The way Flash does programmatic animation is pretty simple.  You take a MovieClip instance on the screen and you simply adjust the x,y values to get it to move.  Flash takes care of the redrawing of the screen for you with no flicker. What Mike Grundvig did was do all the drawing himself.  Instead of using Flash to draw the final output on the screen, he takes all the calculations on the back-end, draws onto a BitmapData object and swaps out the resulting BitmapData with the Bitmap currently being displayed.  In other words, he is doing a kind of low-level “double buffering” using Flash Bitmaps.

When I was a kid programming in BASIC in the Apple II+, I would wonder how computer games made smooth animations.  My problem was when I created a picture and I wanted to “flip” to the next frame of the animation, I had to clear the screen and draw the next frame.  The clearing of the screen caused a moment of blackness before the next frame was rendered.  What I didn’t understand was how to “double buffer” which is something much lower level than I could have achieved in BASIC.  I had to understand assembly language to accomplish that.

Effectively what “double buffering” does is skip clearing out the screen.  Instead of working on 1 screen, you are working on 2 screens.  First you draw the screen.  And instead of clearing it off for the next screen, you do all your drawing logic on the second screen while the first screen is being displayed.  Once drawing is completed, you simply flip from the first screen to the second screen like a flip-book.  That removes the flicker effect of having to draw, erase, and draw again.

Modern graphical engines like Flash take care of this logic for you and are incredibly efficient.  Thus, instead of having to figure out how to draw when you move your MovieClip 10 pixels to the right on the next frame, Flash does all the drawing for you.  But it comes at an expense of CPU cycles to figure out all that drawing logic for you.  You can see the effects of this drainage in Space ROX when I started adding particle effects and Asteroids.

Space ROX V 0.5

Now compare the performance of only a couple hundred particles in my Space ROX demo to the thousands of arrow particles shown in Mike Grundvig’s demo here.

Sometimes it pays to go back to the basics.

THE iPhone

One of the gaming platforms I have been considering (with numerous proddings from indie game developer Jeremy Alessi) has been to start working on iPhone games.

Currently, I have steeled myself into trying my hand once again on another Flash game and to build a series of free Flash games first.  All things considered, Flash game programming is low-risk with low-barriers to entry.  It also is functioning as a crucible to refine my meager game development skills.  So it will be a little while before I get started on developing for the iPhone.

I have to admit, I personally want to get an iPhone, but I am on Verizon Wireless.  So I did a little research to find out when the AT&T exclusivity will be lifted for the iPhone.

2010?

This made me wonder how many people out there are like me who won’t switch to iPhone solely on the basis that they want to keep on their current phone plans.  Too many of my friends are also on Verizon, and it will not be a cheap transition to justify getting an iPhone.

But once the exclusivity is over, there will be yet another surge of iPhone purchases again.  I will probably be one of them.  But what does that mean for iPhone game developers?

It’ll be the second wave.

So I’d better hurry.  Game #2 underway!