Anime USA Mascot for 2008 - Unpublished

I’ve only mentioned it my profile that I am an “aspiring artist” but I just realized that I haven’t actually posted any of my art on my blog.  To the left is an unpublished piece I proposed for Anime USA 2008, a Japanese Animation convention held near Washington, DC.

The theme for that year’s convention was “kami”, the spirits or gods of Japanese Mythology.  My piece was not selected (and thus unpublished), but in all fairness, it could not hold a candle to some of the amazing digital painters who did the art for the convention.

I’ve long tried to do digital painting, but I can only do cell-shaded artwork.  The reason for this is that I am color-blind and so when it comes to the subtle shades of painting, I cannot see them.  But cell-shading is very high-contrast colors and I can use the assistance of the eye-dropper tool to pick out colors I know to be correct.

The piece was sketched, inked and colored in less than 8 hours because it was a rush concept piece I did for the convention.  The inking and coloring was actually done in Adobe Flash CS3.

I realize that I can do all the art as well as programming for any Flash game I would develop, but I’ve found that I can make very little headway if I start working that way.  When I start programming, it is hard for me to disengage from the code, and start drawing the assets I need.  The reverse is also true.  When I am drawing I just want to draw without the time pressure of getting back to programming.

Thus, I am reteaming with the artist of Space ROX, Jonathan Stuart, to see how much further we can get on the project and attempt to release our final product by the end of summer.

As much as my ego wants to do everything for the project, my experience as a programmer as well as my sense of the project scope dictates to me that the work needs to be divided.  Specialization of labor will allow us to produce 4x-8x more than if I continued as a one-man team.

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.

I just discovered the “Bitmap” and “BitmapData” classes in Actionscript 3.0 from this blog tutorial on FlepStudio.

Here is an example of what his tutorial and sourcecode looks like:

Actionscript 3.0 - Bitmap and BitmapData Tutorial

This class could have saved a ton of performance and speed in Strike Eagle.  In Strike Eagle, the moving background is a series of movieclips placed side-by-side and continually scaled which is a huge performance hit in the system.  It would have performed so much faster if I was simply blitting onto a bitmap.

Also, all the particle effects in Space ROX could have used the bitmap treatment saving tons of processing power and reducing the total number of movieclips.