Software, Fitness, and Gaming – Jesse Warden

Blog

  • Event Bubbling in Flex 1.5 & ActionScript 3

    Biggest problem I had in Flash was using a bucket brigade technique to notify one of my high level View controllers from a deeply nested View. Basically, if a form elment, nested in a form container with other views, that is in turn nested in a View controller; he has to go through the View he’s hosted in to get the event out to those who may care. In turn, the main View controller couldn’t subscribe to the event unless the hosting container forwarded it along… which is what I would do in Flash.

    The nested would dispatch his event:

    private function doSomething():Void
{
   dispatchEvent({type: "someEvent", target: this});
}

    Then, the View hosting it would have to suscribe to the event, and forward it up the chain:

    nestedView.addEventListener("someEvent", Delegate.create(this, doSomething));

private function doSomething(event_obj:Object):Void
{
   dispatchEvent(event_obj);
}

    Pain in the ass, and suddenly Views know too much about eachother; a parent shouldn't have to do a child's handiwork.

    Peter Hall had made an ARP extension that allowed bubbling events.

    Apparently, Flex 1.5 already does that. I have a View nested 2 deep in some complicated Flex components, and all the main View controller has to do is subscribe to the View it hosts, and as long as no one intercepts it, the event will "bubble up" the Views to anyone who cares.

    This is accomplished by adding the bubbling property to true on the event object:

    private function doSomething():Void
{
  dispatchEvent({type: "someEvent", bubbles: true, target: this});
}

    Now, with Flex, you still have to define the event in the MetaData tag, much like you define Inspectable properties that component developers can use as getter/setters. So, that is one draw-back; you still have to define the event in whatever View uses it via composition. Bleh.

    I'm not really sure if AS3 requires the metadata, though. Since EventDispatcher is built into Flash Player 8.5, and the 3 phases of capture, target, and bubbling are built into the core of Sprites and MovieClips, I'm sure you probably don't have to define the event; you can just have faith in knowing that if you mark the event is bubbling, it'll flow up!

    :: goes to try a test ::

    :: 20 minutes later ::

    Well, that almost worked. Apparently, events that bubble cause Firefox to crash, haha! Anyway, I probably just found a bug in the alpha software, go figure, but if this is how easy it is to bubble events, awesome.

    Flex 2 Bubble Event Source Files

    *** Update 1.23.2006: Good write up on Event Bubbling with a great class by Bokel.

  • F.E.A.R.

    F.E.A.R. is a first person shooter game, which I bought for the PC. A friend recommended it for multiplayer play, which I haven’t tried yet, but the single player part is pretty cool.

    It’s a combination of movies like the The Ring, The Grudge, Resident Evil 2, games like Max Payne, Half-Life’s Opposing Force, FarCry, and DOOM. At least, all elements from the above are what I saw. To narrow it down, you have the ominous, evil psychic presence of a girl like in the Ring, the ghostly apparations like the Grudge, and the secret government experiements like Resident Evil 2.

    It has the slow motion gun fights of Max Payne, the 1-man-army feel of Opposing Force & FarCry, and “scared you shitless” of DOOM. I think the engine looked a lot like DOOM, too, although, I had to play the game at very low settings; first game to ever do this to my comp; time to buy a new one!

    I started the game Friday night, and beat it last night. I ONLY played the game at night; although the game didn’t really utilize surround sound to it’s fullest, the audio work was an 7 out of 10 regardless, it made the hair stand straight up on the back of neck, and gave me mad goose bumps many a time.

    The flow wasn’t as smooth as it was in DOOM; I just felt the pacing of some of the encounters was a little slower, but it had a weird way of compensating. Like, you’d go through 3 offices with no powerups, no ammo, and no enemeies; my guess is, the level designer did this to have you lower your guard and become complacent. It worked a little bit. DOOM however, barely ever allowed you to get too comfortable.

    The in game timing, too, was a little weird. Like, it was a lot like the TV series 24, where in game time doesn’t really pass that fast. Pretty much a second in the game is a second in the real-world. So, even though the game took me 4 days to complete playing at nights, only a full 8 hours in game passed.

    One thing that this game did well were the animations and timing. Like, just as the camera automatically pans for you to start climbing down a latter, you’d catch a glimpse of some apparation… crazy, uncomfortable stuff, but impecable timing.

    Overall, I’d call this a .9 game. There were a few things that didn’t push this game to the next level, like Doom would. It’s really hard to pinpoint; whether it’s the hodge podge of existing gaming & movie metaphors, the slower pace, the little character interaction, the well scripted character interactions that were too few and far between, while quite funny & believable in some instances.

    Bottom line, the game’s depth didn’t really get pushed as much as I’d like. For example, you never go “back to headquarters” to regroup. You never re-asses the situation; your commanding officier is clearly a manager, and you the doer. Everything is planned, and the introductory mission statements feel cold, and un-applicable to your current situation; you know what you to do, you don’t need text to tell you, although, you need SOMETHING to do during a level loading animation.

    This game is fun, scary, the graphics are hot and I enjoyed it.

  • Blitting & Double Buffering for Tile Based Games in Flash & Flex: Part 1 of 3

    Why should you care? 96% to 6% CPU usage, that’s why.

    Flash Player 8 opened up a lot of boilerplate code via the new Bitmap drawing classes in ActionScript. Usually confined to the nether regions of Director via Lingo, one had to utilize the standard vector drawing tools in Flash. With the combination of runtime drawing with the sprite like nature of MovieClips, Flash enabled pretty powerful tile-based & other gaming engines to be created that were very flexible, and eased a lot of the coding pain that was harder in other graphical engines.

    Painful meaning, you had to write a lot more code to get the same result.

    Performance Bottlenecks – Many Objects

    The one issue, however, is performance. The Flash Player has a few performance bottlenecks, 3 of which tile-based games suffer from. The first is object overhead. Because of the way Flash Player 8 handles prototypes of classes, each Object class has a series of slots for functions and properties, 1 of which is for the proto and prototype properties. These allow the class to know what methods and properties he inherits from his base class as well as who his base class is. Walking up this chain of prototype objects to the main parent (Object) is how inheritance works when you call methods on an extended class; if it doesn’t find it on the immediate prototype, it walks up the chain until it does.

    There is significant overhead in creating objects, memory wise. Keeping track of all of the objects slot information, etc. results in a extreme downgrade in performance the more objects you create in Flash, specifically MovieClips. The more MovieClips you create, the slower things get, both in code response time and render time.

    Vector Drawings – less detail, high CPU cost

    A common response is to simply draw everything dynamically. Why create a tile class object directly (extending MovieClip) or indirectly (extending Object, use MovieClip instance via Composition in class’ constructor), when you can just draw the tiles via the runtime drawing tools into 1 movieclip, and handle mouse interactions via hitTest? Since most tilebased games are event-based, using the keyboard as the primary means of interactivity, the only real hardcore math you are doing is keeping track of where the characters are on the screen, the sprites, and determining if they are allowed to move to another tile.

    Utilizing meta-tiles, like Grant Skinner & Brandon Hall have spoken about before, you can significantly reduce collision detection if you need it for a smaller area of objects and tiles, thus lowering the amount of code needed to run for collision detection.

    This, however, leads to the 2nd issue. The drawing operations, while fast, are vector only. Most tile-based games utilize bitmaps. Drawing bitmaps would require pixel-precision to duplicate in vector, and vector images are extremely CPU intensive. Another option is to merely just attach bitmap tiles as MovieClips, but then you are back to the same problem of too many MovieClips. Even if they are in no way associated with a class (beyond MovieClip by default), you still incur the overhead.

    Bigger vector images do not scroll well either. Even if you don’t utilize strokes (since strokes are rendered differently fills, fills being more efficient when compared to strokes), you will notice the larger and/or more complex you make your vector drawing, the lower your framerate gets. The bigger and/or more complicated the drawing, the less responsive your scrolling maps and code gets.

    Bigger Drawing Area, Less Performance

    Finally, both of the above are contigent upon size of the drawing area. How big is your map, and how much are you displaying. Unfortunately the 2 play extremely little in performance. For example, if you’re drawing is 600×600, and you utilze a mask to only show 200×200, performance isn’t significantly improved, even if the stage itself is 200×200. The reason for this is even MovieClips with their visibility set to false, non-shown, or off-screen are still rendered. While the combination of visibility to false and putting them helps, it doesn’t gain you very much.

    Bigger images render slower, as do many small images taking up the same size area. A larger stage size renders slower than a smaller one. Both of the above have an extreme curve; I don’t have the trig for it, but basically significant performance gains can be gleaned from smaller drawing areas and smaller stage sizes.

    This doesn’t necessarely bode well for Flash Lite 1.1/2 either. While utilizing vector drawing tools sounds attractive for a runtime that only gives you 1 meg or less of RAM to play with, you must understand the phones CPU’s are not extremely powerful.

    Blitting

    Solving the 3 problems above can be solved via blitting & double buffering in combination with cacheAsBitmap and scrollRect.

    Defined succintly, blitting is taking 1 or more bitmaps, and combining them into 1 bitmap. So, if you remember the arcade game Pac-Man, imagine the game itself as 1 big bitmap and each element; the maze walls, the dots, the ghosts, the score text, and Pac-Man himself, as individual bitmaps, or pixels. Each is painted onto the same background, in order: walls, dots, Pac-Man, ghosts, and score. To the end viewer they appear is different elements because every frame some of the elements appear to move. In reality, it is just redrawn every frame, and only those areas that have changed.

    This is important for Flash Player because of a few reasons. First, Bitmaps take far less CPU to render. While Flash Player since day 1 has been a vector-to-pixel renderer, you now have true bitmap objects that are just that; a series of pixles with different colors on the screen. Drawing & displaying these on todays machines takes very little system resources. In all fairness, bitmaps take more RAM to display vs. CPU.

    Secondly, to create a scenario like the above, you are still just drawing and displaying 1 bitmap for what would of been a large number of sprites in Flash Player 7 or below. While sprites (Flash Player’s MovieClip) offer an easier way to animate and code, they are not efficient, ecspecially for an exteremely small runtime web player that utilizes no hardware acceleration, excluding some for newer Macs.

    Double Buffering

    You can accomplish blitting in Flash by using the new Bitmap classes. You can accomplish blitting for games by using something called Double Buffering.

    Defined succinctly in a Flash Player context, double buffering is a technique used display a bitmap on screen that contains a plethora of other bitmaps. One bitmap is drawn in RAM, with additional bitmaps blitted, (copied) onto it. Then, you copy the finished bitmap from RAM and display it on screen as one bitmap.

    This is done in screen drawing in other applications to prevent redraw issues, such as seeing the drawing as its being drawn. However, because of Flash’s single-threaded nature, this is mainly done to simplify coding and still getting the performance increase of only displaying 1 bitmap to the screen.

    Conclusion

    Thus, a developer has the opportunity to create some really compelling tile-based games in Flash Player now that the performance bottlenecks can be overcome via blitting and double-buffering.

    Part 2 will show how you utilize blitting and double-buffering in ActionScript 2 in Flash Player 8, and ActionScript 3 in Flash Player 8.5. Additionally, I’ll show you used to do things, and how you can get your CPU usage while scrolling the map to go from 96% to 6%.

  • Yahoo! Maps: Flex/Flash/AJAX – Good on Their Word

    Finally, Yahoo! has made good on their ability to showcase the Flash Platform. They built Yahoo! Maps using Macromedia Flex. If anyone remembers, part of the Yahoo! Toolbar episode was in addition to Macromedia receiving funding for hosting the Yahoo! Toolbar installation on the Flash Player installation page at Macromedia, this symbolized a deeper relationship. It was said publicly that Yahoo! was doing some amazing things with Flash, and would help push the Flash Platform.

    Was about to call bs, but thankfully am eating my words.

    Yahoo! has released a beta of their mapping services, much like Google Maps, but at least as far as I can see, more interesting to developers. You can utilize Flex, Flash, and/or AJAX/JavaScript to utilize them. Options rock. Frankly, I’ll never touch the latter 2 unless a gun is pointed to my head since the Flex one works so darn well, and is fun to play with.

    Before the FUD gets out of control, you can embed Yahoo! Maps into your own page using Flash Player 7, NOT SHOCKWAVE. Many people associate Shockwave with Director’s Shockwave web player, and Yahoo! Maps is in no way associated with it, so ignore it since it is written a few times on the developer site.

    I’ve included an example MXML file you can use to quickly get up to speed on how to use it. Here are some helpful links.

    Finally, although that Techcrunch article above needs to be checked again by the editor, two quotes in it, to me, really hit home:

    First, the usability improvement over Google Maps:

    And as you edit the map by moving, adding things, etc., the URL in the browser bar self updates so that it can be copied and pasted at any time. This is something that really bugs me about Google Maps – the need to click a link to get a permanent URL. Yahoo’s solved that with some cool javascript coding.

    And Second, a stab at the tub cleaner:

    Because Yahoo Maps is built on Flash, the “back button” on the browser still works (a problem with AJAX applications).