Category: Flash

  • Changing the Modal Color

    When you create popups in Flash or Flex, you have the option of making them modal. This means that no other content below the window can be clicked on or interacted with. This forces the user to deal with the popup, usually a Window containing an important form, such as a Login window or an Alert that is asking a question.

    You do this by setting the 3rd parameter of PopUpManager.createPopUp to true. By default, Flash and Flex make this modal window invisible. It’s basically this big shield the size of your application that prevents mouse clicks from going through. Some other magic happens behind the scenes to prevent keyboard commands from slipping through.

    While you can skin this invisible shield via editing the symbol PopUpManager uses to create it, called “Modal”. If you just want to set the color to something other than white, I haven’t gotten styles to work with it. You can set the alpha of this shield; the common value is 50%:

    setStyle(“modalTransparency”, 50);

    For the color, you need to get a specific reference to it. There is probably a cleaner way, but this works in both Flash and Flex 1.5:

    import mx.managers.PopUpManager;
    import mx.containers.Window;
    
    private function initApp():Void
    {
            setStyle("modalTransparency", 50);
            var ref = PopUpManager.createPopUp(this, Window, true);
            ref.setSize(320, 240);
            var c:Color = new Color(ref.modalWindow);
            c.setRGB(0x660000);
    }
    

    All popups are created with a reference attached (a.k.a. decorated) to them in the form of giving them the property of modalWindow. This might be pre-defined in UIObject or something allowing strict typing to work. Regardless, now you have a color choice other than white!

  • Diesel & Battlefield: ActionScript 3 Blitting Engine for Tile-Based Games

    Diesel is a blitting engine for Flash Player 8.5 using ActionScript 3. Uses 1 bitmap to paint to vs. using many DisplayObjects in an effort to utilize less CPU & RAM.

    Skip to Introduction if you want to know more about Diesel, or read on for background as to why I’m posting this.

    Contents

    Preface

    I was originally using this project as a part 2 & 3 followup to my blitting post, but realized it is a ton of work. Even getting simple benchmarks down on alpha software is pointless because many memory bugs are fixed in later versions, rendering your previous benchmarks worthless. For example, I’ve found a bug with flash.display.Loader where, if you issue a ton of loads, say over 1900, each load allocates almost a meg of memory. The problem is, even if you delete the loader as well as what it loads, the memory isn’t freed. This is known and will apparently be fixed in a later build.

    Not to mention I’m still learning ActionScript 3, so my style of coding has changed the more I learn, making it hard to keep 2 different approaches to a problem in sync: using Sprites vs. blitting to 1 bitmap.

    I will say this with confidence; blitting is far more scaleable than using a multitude of Sprites. While the memory usage for blitting is far below what the Sprites use, the processing isn’t what I’d hope it’d be. Additionally, I’d forgotten just how much RAM bitmaps can take. So, even if you make a 2880×2880 blank, transparent bitmap in RAM, it still takes about 44megs.

    I still believe, however, that blitting is the future of Flash games, and all I need to do is optimize the Diesel engine a bit more, and she’ll be a more attractive alternative to utilizing Sprites for game development.

    My original goal in posting was to show my older version of Battlefield, a simple tile-based map engine based on Sprites, and one based on Diesel. A milestone I had reached as getting the TileMap, a base class, to using blitting only, and scrolling via double-buffering (copying pixels from a larger bitmap, not-shown off-screen). While this made the map scroll really fast, when I started adding Sprites, it still kept a good refresh rate, but started using way more processor than I had experienced in earlier tests on a smaller scale using Flash Player 8.

    Frustrated, I realized I had to re-write even all of the sub-classes in Battlefield that rendered sprites, as well as the main walking character. I did so at the cost of not updating the older Sprite one with which to do benchmarking at a later date. Don’t care, though, because again, I feel blitting is worth spending more time on perfecting and optimizing.

    So, without further adu, I present a really early build of Diesel, a blitting engine, and Battlefield a simple tile-based engine example that uses Diesel.

    TOP

    Introduction

    With the addition of Bitmap classes in Flash Player 8, developers now have the ability to utilize blitting and double-buffering techniques to create resource efficient gaming engines in the Flash Player. Diesel is a set of ActionScript 3 classes that provide a conveinent display engine to take advantage of these new player features.

    TOP

    Why should I care?

    Diesel uses 1 bitmap to draw to vs. hundreds of MovieClips. This results in a more scaleable engine, allowing for more moving sprites, lower usage of RAM & Processor, and better refresh rates.

    TOP

    What’s wrong with MovieClips for games?

    While MovieClip’s are conveinant to code & design with, they are not efficient when dealing with a multitude of bitmaps for games. They also do not scale well when you need to create many of them, and have them all move on the screen at the same time. Finally, large bitmaps in Flash traditionally have not scrolled very fast when used as tile-based game backgrounds. You either have to use 1 large bitmap that is pre-rendered, or you can use tiles in the traditional sense, but neither is an optimal solution for games.

    Big bitmaps are not an ideal solution for a couple reasons. First off, it’s not dynamic; you have to create this before hand. While you can load it in dynamically, you have to use MovieClips atop it to generate any effects. Secondly, even if you mask a certain area of the screen, the rest of the bitmap is still drawn the screen, taking up a lot of processor & ram and sacrificing a good refresh rate (smoothness of the animation).

    For tile based games, you have 2 solutions. Either draw all of your tiles as multiple MovieClips, and have all of them created in one parent MovieClip. When moving your map, you simply move the main MovieClip that houses them. While this makes coding easy, it suffers from resource usage, namely reduced refresh rate, and it gets worse the more tiles you create. This is even before you start putting gaming sprites on the screen.

    Your other solution is to create the tiles on the fly based on the direction the character in the game moves. While this is a lot more scalable than the above, allowing you to create bigger maps, you suffer from redraw speed when creating the new tiles. The creation & destroying operations that you use on the tiles takes up a lot of processor, reducing the continual smoothness of your animations.

    TOP

    How is Diesel better?

    It uses a technique called double-buffering. By using 1 bitmap, you solve a bunch of issues MovieClips have traditionally caused. First, you have 1 bitmap, not hundreds. Each sprite in your game is represented as a data object, but it’s bitmap data is copied to the main big bitmap. All sprites are copied to this main big bitmap. This big bitmap is actually not shown, but is off-screen and not in the Display List. A portion (or all of it) is copied to an on-screen bitmap that is repainted when something moves or changes.

    This uses significantly less RAM because each sprite in your game is actually just a data object vs. a Sprite or MovieClip. You store basic information like x and y position as well as width and height as BitmapSprites. They are then added to the BitmapDisplayObject, much like you add MovieClips to the Display List. BitmapDisplayObject is just a flash.display.Bitmap that renders all of the BitmapSprites added to it’s list of things to draw.

    Additionally, the entire bitmap does not have to be drawn. For example, many tile-based games consist of a large map, but only a small portion is shown. For this reason, only a small portion of the map can be shown, and thus drawn, not the whole thing. So, when repainting, only those portions of the screen that need to be redrawn are, not the whole thing, nor things not shown.

    TOP

    Why not use the Display List in Flash Player 8.5?

    In my tests, Diesel uses less RAM, and uses less processor vs. using Sprites and the Display List.

    TOP

    How do I use it?

    Simply import the classes into your project. I’ve done my best to match the syntax like the ActionScript 3 flash.display.DisplayObject syntax.

    For example in ActionScript 3, if you want to create a sprite and show it, you do something like:

    import flash.display.Sprite;
    var my_sprite:Sprite = new Sprite();
    addChild(my_sprite);

    Diesel’s code works on the same concept of seperating the object from the actual drawing. However, instead of adding your BitmapSprite, the Sprite equivalent, to the normal Display List, you instead create a BitmapSpriteDisplayObject, and add your BitmapSprites to it. The BitmapSpriteDisplayObject class is just a flash.display.Bitmap with optimized code to handle drawing BitmapSprites.

    An example of creating a BitmapSprite, and showing it, just like you would create a Sprite to show it, is:

    import com.jxl.diesel.view.core.BitmapSpriteDisplayObject;
    import com.jxl.diesel.view.core.BitmapSprite;
    // create your BitmapSpriteDisplayObject
    var bsdo:BitmapSpriteDisplayObject = new BitmapSpriteDisplayObject();
    // add it to the Display List so it's shown
    addChild(bsdo);

    // now, create your BitmapSprite
    var my_bSprite:BitmapSprite = new BitmapSprite();
    // and add him to the BitmapSpriteDisplayObject
    bsdo.addBitmapSprite(my_bSprite);

    You can add and remove as many BitmapSprites as you want. Additionally, you can create multiple BitmapSpriteDisplayObjects.

    TOP

    Conclusion

    I am definately interested in contributions, suggestions, and/or criticisms. If you’re seriously interested in helping improve the engine so it performs like Andre Michelle wrote it, and/or taking Battlefield to another level, drop me a line in the comments, and I’ll hit you up with Subversion access.

    TOP

    Examples

    Example of Diesel & Battlefield drawing sprites on a walkable map. Click once on the tiles to give focus, and then use arrow keys to move.

    Example of Diesel loading tiles at runtime, extracting the bitmap data from a bunch of PNG’s, and drawing them to the map.

    TOP

    Source Code

    Diesel & Battlefield Source Code

    • SVN
      username: public
      password: public
    • SVN
    • ZIP (beta1) Get latest build from SVN

    Creative Commons License
    This work is licensed under a Creative Commons Attribution 2.5 License.

    TOP

  • Dynamic Icons in a ComboBox

    Wrote this example for a gent on the Flashcoders list. Didn’t want an orphan page on my site, so linking to it from here. Shows how to use a cellrenderer in a ComboBox to show an icon. I should of only changed in the icon in the setValue function if it changed, like so:

    if(lastIcon != item.icon)
    {
       lastIcon = item.icon;
       image_ldr.load(item.icon);
    }

    That would of prevented the flicker you see when you roll over the items. The more I code in Flash, the more I love Flex. Flash is still faster though, no doubt.

    Icon in a ComboBox using a cellrenderer

  • Machines Enter the Cellular Mundane Push

    Old tech, new, more personal application. Pre-recorded messages have been the norm for call help. If you call just about anywhere for help, excluding your local power company in a small, southern, American town, you’ll get a pre-recorded message, usually navigatable via the touch-tone phone, and more recently, decently intelligent voice recognition. The latter helps the hands free vs. the frustration free in regards to suffering the indignity of not being able to talk to a human via the phone unless using the equivalent of Control + Alt + Delete (0, 0, 0, 0, 0, 0… ah, operator).

    I don’t answer my home phone anymore. We only have it for internet, because BellSouth, the phone company, requires a land-line for DSL (linemen union’s got ’em by the balls), and cable is too expensive compared to satellite. Her majesty digs the long distance every so often, but even that is rarely used with her Cingular rollover minutes on her cell phone. Naturally, if I don’t pay a bill on time, I’m f00ked because I’d never answer the phone to hear bill collectors.

    To me, land-lines have reached the relevance of newsgroups(aka USENET); saturated by unsoliciated services, thus rendering them useless.

    One such frustration was telemarketing done via machines. It wasn’t just the call being a pre-recorded message interupting my Flash debug sessions, so much so as the recording’s inability to start up quickly.

    Now, they’ve found a useful application; reminding me that my credit card that I use to auto-pay my Cingular cell phone bill every month is about to expire, and I should call Cingular to preemptively setup a new card so my service remains uninterupted.

    Sorry mom, but the etiquette you instilled into me is for naught for the thank you will fall on non-existent ears.

    *ring* *ring*

    :: goes to answer phone ::

    “Thissssss is Jesse.”

    “Hello (Mr. Anderson). This is a courtesy call from Cingular Wireless regarding your account.”

    “Hey… your mom’s a choad! Choad choad… CHAoAOAOAOAOOD!!!”

    :: the voice continues, unabated ::
    “Your current credit card on file used to auto-pay your acount…”

    “Dude, I’m wearing women’s clothing right now, and I must say, for a guy, I look quite attractive. Screeeeee-umptous!”

    :: the voice continues, unabated ::
    “… is about to expire. To ensure your continued service…”

    “Boo-LAAAA, BOO-LAA, BOOOOO-LAAAAAHHHH!!!!”

    :: the voice continues, unabated ::
    “… please call use at xxx-xxx-xxxx as soon as possible to setup a new credit card. Than…”

    :: click, I end the call ::

    In the movie Terminator, guerilla fighters fought a desperate battle against the dominating machines. Their dying breathes were fought vying for re-control of our world, and our right to live.

    In the real world, I realize the machines are arising in a different, more subtle way, a way in which we won’t even notice. Frustrated that I’ll not be able to wear ripped up clothing, hauling around homeade bombs, all in a desperate battle to reclaim our home planet… I spitefully make obnoxious comments to a machine recording on my cell phone, a device created to help faciliate communication amongst humans, sickenly mocked under the guise of effecient, helpful service. It’s so humiliating… the least they could do is code in fuzzy logic to have the voice get irritated for getting interupted in a consolatory effort make me receive some satisfaction in knowing my world full of human dominance is slowly, but surely slipping from our control, willfully.

    Bank of America’s current pre-recorded guy actually takes a Pet Detective vs. Captain Kirk approach if you interupt him, “Iiiiiiiiiiiiaaaahhh’m sorry, I… didn’t-quite-understaaand what you were asking.”

    While the title of this entry does not do justice to the full implications contained herein, to me, this is yet another piece of evidence giving credit to the science fiction writer, Simon Ings, quoted at the bottom of the following article. I originally found this article, Turing’s Cathedral, via the O’Reilly Radar. I’m still reading one of Ray Kurzweil’s books, The Age of Spiritual Machines, which only exacerbates the fear of what this quote implies. I see it happening every day.

    When our machines overtook us, too complex and efficient for us to control, they did it so fast and so smoothly and so usefully, only a fool or a prophet would have dared complain.

    I can only hope my alias, “Jester”, has a deeper meaning here.