The site is built on a CakePHP application and actually uses Wordpress for the blog section of the site. It doesn’t use Wordpress for any of the front end, but in the back end the standard Wordpress Dashboard is used to manage, edit, and write blog posts that are then displayed in the front end blog section.

The site also utilizes my meta description and title components, that allow the application to manage those parts of the page independently of the page content. Basically it just ties a URL to a title or a description, matches them up when pages are requested, and if it finds a matching record it outputs it in the proper place. Otherwise it will output a sensible default text.

I did enjoy working with CakePHP again as it’s been some time. But all the things I liked about it still apply. It’s still lightening fast from prototype to finished site, and design modifications couldn’t be any simpler. All in all, good project, and I think the end result looks and works very well.

I’m just using the standard ImageMagick tools convert and montage to split and join the images, as well as some bash-fu to sort files properly. I am using Cygwin to get bash tools on my Windows machine.

The first command is used to split up the main image. The only constraints here are that the resulting tiles must be square, and that they don’t exceed the width limit for Flash BitmapData objects. So here we simply are cropping the image into square tiles.

convert full.png -crop 32x32 tiles.png

 
This will spit out a bunch of images in the current folder named tiles-%d.png where %d is the 0 based index of the tile. This also assumes that the width and height of the full.png image are divisible by 32 without remainder.

The next command we need is to stitch the images back together. For this we will use the handy montage tool to tile the images into one big sheet. We just pass it a sorted list of names and tell it to make 1 row with as many columns as it needs (the x1 parameter). Sorting is not entirely necessary but using the default bash globbed format will result in tiles that should be at the end of the image randomly at the beginning (try it before this step by noting the output of `ls tiles*.png`).

files=$(ls tiles*.png | sort -t '-' -n -k 2 | tr '\n' ' ')
montage $files -tile x1 -geometry 32x32+0+0 sheet.png

 
If all went well we should see, inside the current directory, an image with all of our separate tile sprites in a single row in order from the original image from left to right and top to bottom.

This technique is also useful for converting “liberated” sprite sheets that have more than one row, into single row sprite sheets that flixel can handle out of the box.

The class I developed is a simple override of the base FlxSprite class with some modifications to its collision detection system. It takes advantage of the fact that each sprite has its own set of BitmapData in its own coordinate space, which the framework uses to blit to the main screen BitmapData. BitmapData objects in Flash provide us with a native implementation (in the Player AFAIK) of per pixel collision detection, using the hitTest method.

The hitTest method takes 5 parameters, but we only really care about the first 4. The first parameter we pass it defines where the calling BitmapData object is in screen space, i.e. the sprite’s (x,y) coordinates. We then pass it a threshold alpha value, 0 being transparent and 255 being opaque. If you want semi-transparent regions of your sprite to collide then set this to something lower than 255 (0xFF is the hexadecimal representation of decimal 255). The third parameter is the colliding sprite’s BitmapData object. And the fourth is the colliding sprite’s (x,y) coordinates in screen space.

I have abstracted this into the class’s structure, so the overridden functions handle everything. You can use another alpha threshold by setting the sprite’s alphaThreshold value to something valid, as explained above. You can also disable this pixel perfect collision detection method per technique by either setting doPerfectCollide or doPerfectOverlap to false. Because there are two methods Flixel uses to detect collisions, the class implements enhanced versions of both, and allows you to disable either independently.

Note that, in order for the collision detection to be pixel perfect, either a) both colliding objects must subclass PPlxSprite or b) the sprite calling overlaps or collide must sublcass PPlxSprite and the colliding sprite must have a single frame. This is due to fact that the original FlxSprite class does not expose the _framePixels BitmapData object which is needed to collide the objects with the frame that is currently displayed. When a FlxSprite is collided with a PPlxSprite and the perfect collision is enabled, the exposed _pixels BitmapData is used, which contains the entire sprite sheet, so collisions are detected against all frames, not just the frame displayed. However, changing existing sprite’s to use this class is easy enough so as not to cause problems.

Note also that we only call the hitTest method when we know there is already a bounding box collision, so as not to waste CPU cycles. The native hitTest method is fast but probably not fast enough to call every frame, which would be wasteful in any case.

Below is the PPlxSprite class which override the collision methods to provide pixel perfect collisions.

import flash.display.BitmapData;
import flash.geom.Point;

import org.flixel.FlxCore;
import org.flixel.FlxSprite;

public class PPlxSprite extends FlxSprite {

    public var alphaThreshold:uint = 0xFF;
    public var doPerfectOverlap:Boolean = true;
    public var doPerfectCollide:Boolean = true;

    protected var _corePos:Point = new Point();
    protected var _thisPos:Point = new Point();

    public function PPlxSprite(X:int=0, Y:int=0, SimpleGraphic:Class=null) {
        super(X, Y, SimpleGraphic);
    }

    public function get framePixels():BitmapData { return this._framePixels; }

    override public function overlaps(Core:FlxCore):Boolean {
        var doesOverlap:Boolean = super.overlaps(Core);
        if (doesOverlap && this.doPerfectOverlap && Core is FlxSprite) {
            doesOverlap = this.perfectCollision(FlxSprite(Core));
        }
        return doesOverlap;
    }

    public function perfectCollision(Sprite:FlxSprite):Boolean {
        this._corePos = Sprite.getScreenXY(this._corePos);
        this._thisPos = this.getScreenXY(this._thisPos);

        var corePixels:BitmapData;
        if (Sprite is PPlxSprite) {
            corePixels = PPlxSprite(Sprite).framePixels;
        } else {
            // i guess other standard FlxSprites are boned if they are animted
            corePixels = Sprite.pixels;
        }

        return this._framePixels.hitTest(this._thisPos, this.alphaThreshold, corePixels, this._corePos);
    }

    override public function hitWall(Contact:FlxCore=null):Boolean { return this.hitSomething(Contact); }
    override public function hitFloor(Contact:FlxCore=null):Boolean { return this.hitSomething(Contact); }
    override public function hitCeiling(Contact:FlxCore=null):Boolean { return this.hitSomething(Contact); }

    public function hitSomething(Contact:FlxCore):Boolean {
        var didHit:Boolean = true;
        if (this.doPerfectCollide && Contact is FlxSprite) {
            didHit = this.perfectCollision(FlxSprite(Contact));
        }

        return didHit;
    }
}

 
Here I have overriden the core FlxSprite methods that are responsible for collision detection, those methods being overlaps and the hit family of methods. Overlaps gets called when you explicitly issue a sprite.overlaps(otherSprite); This is a simple override that adds functionality to the super overlaps method, namely, calling the pixel perfect detection method and returning its results.

The hit family of methods are called after calling the collide family of methods, including collideArray and the like. The collide methods, when they have detecting a bounding box collision, call the hit family of methods, depending on the location of the collision, which return a boolean. If the called hit method implemented by the sprite returns false, the collide method aborts and reports that it didn’t collide after all. This is the behavior on which the above hit methods rely, and return false when it detects that while a bounding box collision may have occurred, the pixels in either sprite have not collided.

A short usage class follows.

public class SomeSprite extends PPlxSprite {

    // Embed sprite image.

    public function SomeSprite(X:Number, Y:Number):void {
        super(X, Y);
        // Load sprite image, and other sprite stuff
    }

    override public function hitWall(Contact:FlxCore):Boolean {
        if (super.hitWall(Contact)) {
            this.hurt(1);
            return true;
        }
        return false;
    }
}

 
Here, all we do is simply extend the PPlxSprite class from above, and do what we normally do for sprites. We also decide to do something special when a character hits a wall, namely, get hut. To do this we override the hitWall method, call the super hitWall (which would be the PPlxSprite hitWall) method, and depending on its return value, we either get hurt or do nothing. We don’t need to do anything special for calling the overlaps method, as this will simply call PPlxSprite overlaps method.

So, hopefully this is helpful for someone looking to do this, or at least someone can find the ideas listed here useful. Let me know if you used it and if you find any bugs, improvements, or have any other suggestions.

As a category, top down and platformer games in general usually have some type of movement modification obstacles. These obstacles allow the player to pass through them, so they don’t stop the player from moving, but they somehow alter the player’s course by speeding up, slowing down, or sending the player in a different direction. In my case, these obstacles are oil slicks and water puddles, which speed up and slow down the player in whatever direction they are traveling. Here I will cover how I solved speeding up and slowing down the player when he crosses over such an obstacle.

Below is a skeleton of my main player class:

 package sprites {
	import org.flixel.FlxG;
	import org.flixel.FlxSprite;

	public class Player extends FlxSprite {

		[Embed(source="player.png")] private var Img:Class;

		protected var _runSpeed:Number = 100;

		public var velocityFactor:Number = 1;

		public function Girl(X:int=0, Y:int=0) {
			super(Img, X, Y, true, false, 58, 58);

			drag.x = this._runSpeed * 8;
			drag.y = this._runSpeed * 8;

			maxVelocity.x = this._runSpeed;
			maxVelocity.y = this._runSpeed;

			...
		}

		override public function update():void {
			// MOVEMENT
			acceleration.x = acceleration.y = 0;
			this.maxVelocity.x = this._runSpeed * this.velocityFactor;
			this.maxVelocity.y = this._runSpeed * this.velocityFactor;
			if (FlxG.keys.UP) {
				acceleration.y -= drag.y;
			}
			// And similarly for all 4 key directions
			...

			super.update();
		}
	}
}

Using this player class, we can see that by modifying the velocityFactor instance variable, we can effectively control how fast the player can move around the screen. By setting velocityFactor equal to a value less than one, we decrease the player speed, and by setting it equal to a value greater than one we increase the player speed. So what we need now is a way to modify this value externally in response to player interaction with the world, namely, the player stepping onto a puddle or an oil slick. We also need sprites that define how they should change the player movement when they are stepped over.

Below is a skeleton of one of my obstacle classes:

package sprites.obstacles {
	import org.flixel.FlxG;
	import org.flixel.FlxSprite;

	public class SpawnerObstacle extends FlxSprite {

		public function get playerVelocityFactor():Number { return 2; }

		[Embed(source="spawner.png")] private var SpawnerImg:Class;

		public function SpawnerObstacle(X:int=0, Y:int=0) {
			super(SpawnerImg, X, Y, true, false, 24, 24);

			this.fixed = true;
		}

	}
}

Here is just a simple implementation of a FlxSprite class where we define that this sprite, when stepped over, speeds up the player by a factor of 2.

Below are the relevant parts of the update() method in my main PlayState class.

this._player.velocityFactor = 1;
for each (sprite in this._obstacles) {
	if (this._player.overlaps(sprite)) {
		trace('modifying player velocity');
		this._player.velocityFactor = obstacle.playerVelocityFactor;
		break;
	}
}

Here we loop over the obstacle sprites in the _obstacles array. This array would be created whenever you initialize the obstacles for the game. The obstacles themselves, in this case, are instances like the above SpawnerObstacle class, which have a playerVelocityFactor getter attached. In the beginning, we make sure that we set the player’s velocityFactor to 1 so that the player moves at the default speed in the case that they are not on top of an obstacle sprite. We also break out of the loop when we collide with a single obstacle sprite to avoid any extra complexity. We could make it so that we average the velocity factors when multiple obstacle sprites are encountered, but I don’t have this use case so it would be unnecessary.

When all these parts are in place and working in conjunction, we have a game that satisfies our original goal. When the player collides with one of our obstacles sprites, he is either sped up or slowed down, depending on the velocity factor defined by the colliding sprite. If I get any less lazy (highly unlikely) I’ll post an example swf with source code.

Please take a moment to vote for Barbie to become a Computer Engineer. Future generations of computer engineers would really appreciate it if we could influence some girls to take up the profession.

So indeed, I did vote, and so should you….or else! From the Barbie site:

Computer engineers have lots of different specialties. They can do anything from building computers to making video games!

It’s true folks. Why would any young girl not want a computer engineer Barbie? It’s fun for the whole family! I certainly wish my toys could program an analog synthesizer.

Vote!

var bd:BitmapData = new BitmapData(w, h, true);

 
The third boolean argument to the function is a transparency flag, and here it is set to true. However, when creating a Bitmap object from this BitmapData object and adding it to the display list, it clearly has a white background instead of being transparent.
 
To remedy this, the solution is to pass along to the function a 32bit color value where the alpha value is zero. The following code illustrates this solution:

var bd:BitmapData = new BitmapData(w, h, true, 0x00000000);

 
This will create a totally transparent BitmapData object on which you can draw whatever you desire. In practice I use this to determine the alpha values of a given pixel in a given display object. The following function implements this technique:

public static function getAlphaAt(d:DisplayObject, x:Number, y:Number):Number {
	// Even though we set transparent to true, we still need to use a transparent color.
	// This is easily done by setting alpha to 0; the RGB octects after that don't matter.
	var bd:BitmapData = new BitmapData(d.width, d.height, true, 0x00000000);
	bd.draw(d);
	return (bd.getPixel32(x, y) >> 24 & 0xFF)/255;
}

public function scaleImageToMaxDimension(img:Image, maxWidth:Number, maxHeight:Number):void {
	var scaleH:Number=1, scaleV:Number=1;
	if (img.content.height > maxHeight) {
		scaleV = maxHeight / img.content.height;
	}
	if (img.content.width > maxWidth) {
		scaleH = maxWidth / img.width;
	}
	img.scaleX = img.scaleY = Math.min(scaleH, scaleV);
}

 
Flex doesn’t do a terribly good job of resizing images, however, but it works for images that just need to be tweaked to fit. If you have control over your images and your display size, it is always best to resize them as needed to save space/bandwidth and preserve quality. This approach works best when you have little or no control over either.

In application this code would be used after the image has finished loading. So for example I might do something like the following:

import flash.events.Event;
import mx.controls.Image;

public class Test {
	public var image:Image;

	// pretend scale function is here

	public function Test {
		image = new Image();
		image.addEventListener(Event.COMPLETE, imageComplete, false, 0, true);
		image.load('http://www.google.com/intl/en_ALL/images/logo.gif')
	}

	private function imageComplete(event:Event):void {
		scaleImageToMaxDimension(image, 100, 100);
	}
}

Saw this joke at this year’s Ohio Linux Fest during the closing talk, A Surfeit of Sophistication which was quite a good talk.

But, the vector class does interest me somewhat. It promises faster iteration over a strongly typed collection. Doesn’t seem to add any other handy features however, like Flex’s robust ArrayCollection methods including removeItem. But alas. As for it being faster, I have heard talk around the internets of the vector class only being significantly faster with simple types, but I’m way too lazy to any informal benchmarks of my own, so I’ll just read someone else’s results.

One specific question I had that I didn’t see answered anywhere, however, was the type of objects you could stick in a vector once the template class had been set. It was my suspicion that you could put any subclass of the template class in the vector, just like C++ templated vetors, but I hadn’t read it confirmed anywhere, so I fired up my shiny new Flash CS4 and gave it a try. And indeed, my suspicion was correct. The following simple code below validates my hypothesis.

var test:Vector.<Sprite> = new Vector.<Sprite>();
test.push(new Sprite(), new MovieClip());

// should output something like "[object Sprite],[object MovieClip]"
trace(test);

At any rate, the solution comes from Danny Burbol’s blog, which apparently came from a Experts Exchange thread (damn people charging for information). I modified the solution a bit to fit my needs, but not by a whole lot. Sometimes I only need to copy the instance and I can reconstitute the MovieClip from there but other times I will need to get the whole shebang. It’s pretty handy in general. So my version follows (as a bonus I include my handy-dandy clearAllChildren function):

package com.bmm.utils {
  import flash.display.DisplayObject;
  import flash.display.DisplayObjectContainer;
  import flash.geom.Rectangle;

  /**
   * ...
   * @author BenS
   */
  public class UIUtils {

    public static function clearAllChildren(c:DisplayObjectContainer):void {
      if (c == null || c.numChildren == 0) return;

      var i:int = 0, n:int = c.numChildren;
      for (i = 0; i < n; i++) {
        c.removeChildAt(0);
      }
    }

    public static function simpleDisplayObjectClone(source:DisplayObject):DisplayObject {
      var cc:Class = Object(source).constructor;
      return new cc();
    }

    public static function displayObjectClone(source:DisplayObject):DisplayObject {
      var copy:DisplayObject = UIUtils.simpleDisplayObjectClone(source);

      copy.transform = source.transform;
      copy.filters = source.filters;
      copy.cacheAsBitmap = source.cacheAsBitmap;
      copy.opaqueBackground = source.opaqueBackground;
      if (source.scale9Grid) {
        var r:Rectangle = source.scale9Grid;
        copy.scale9Grid = r;
      }

      return copy;
    }
  }
}