Archive for the 'Code Snippet' Category


HTML5 Game Dev. Removing elements from the screen. Finding the fastest method.

Using removeChild to clear off a few in-game elements I noticed a bit of lag when testing on some devices so thought I’d better have a look at what the fastest removal methods are.

The three methods I selected to test were removeChild, display=”none” and a simple hide the element offscreen. Again, testing has been carried out at

My first test was on Chrome 16 and the results were pretty conclusive. display=”none” was very slow, and hide the element was by far the fastest – over 4 times faster than display=”none”.

So, conclusive proof – I should just hide my elements off the screen.

Err, no. I next tested Firefox 9.0.1. Ah, here removeChild was 2.5 times faster than both display=”none” and hiding the elements.

IE7.0 then. display=”none” and the hiding elements method were nearly 3 times faster than removeChild.

What about devices?
With Android 2.2 (Galaxy Tab 1) display=”none” was the fastest method, but only marginally so over the other two.

Safari on iPad #1 (4.2.1) flips the results on their head again with removeChild() being nearly 3 times quicker than the other two.

So how do we interpret this data? A chief decision to make would be what the target devices are. Then choose the quickest method. If we wanted a more generic approach then a series of conditionals would allow for all three methods to be present, using the most relevant one for the current browser.

For the prototypes I am working on, number one target is the iPad. A lot of my focus has been on trying to avoid using the Canvas element (entirely due to horrible performance on Android with it).

Element removal.

The (very simple) code used is here (for simplicity’s sake I use the inverse method as well to bring the element back onto the stage for subsequent removal):

var testDIV = document.createElement(‘div’);
testDIV.innerHTML = “Hello World”;

function displayIsNone()

function removeChild()

function moveVideo()

Try the tests yourself here:


HTML5 Game Dev. DOM Manipulation. It’s costly, so minimise its use.

Typically when manipulating display objects in Flash, applying positional data is a trivial task so you wouldn’t think twice about applying the data on every game loop. It doesn’t matter that the object hasn’t moved on that frame. The overhead would be minimal, you can just reapply without penalty – in fact to engage with any conditional to test for the need to apply could be more costly in the long run.

With DOM manipulation, any update seems to be fairly processor expensive. Very non-trivial. Here it is essential that updates should be applied ONLY when absolutely necessary.

I ran a test script at which demonstrated the issue. I set up a Div with some simple text content. Then manipulate it on every iteration. I move the x-position by 0.2, then round off the position before applying. To optimise I only apply the dom manipulation when the actual object has changed position. The results are stark. A massive performance boost.

Optimise your DOM manipulations. It pays.

The code used is simple, and as follows. Create a div, populate then manipulate:

var targetDIV = document.createElement(“div”);
targetDIV.innerHTML = “test data”;
var posX =0, prevPosX=0;

function unoptimisedManipulation()
var roundX = Math.round(posX);

if(posX>500) {posX=0;}”px”;

prevPosX = roundX;

function optimisedManipulation()
var roundX = Math.round(posX);
if(posX>500) {posX=0;}”px”;

prevPosX = roundX;

The results aren’t indicating that DOM manipulation should be avoided – Android devices really struggle with Canvas so DOM is preferable – it just takes a bit of effort to make the DOM production ready.

Try running the tests yourself at :


HTML5 Game Dev. Flipping a DIV – Horizontally Inverting content with Javascript and CSS

As I prepare for my talk at FITC Amsterdam (Feb 2012) I’m building a web game in both Flash & HTML5.

I’m aiming my HTML5 build at the mobile web (but will try to reach as many desktop browsers as possible) – so it will need to run optimally across Android & iOS.

I’ve discovered a few issues so far that for the purpose of record and reference I’ll post here in game lab.

First up. I have a player character that I’m animating via a spritesheet. I need the character to be able to face left and right.

I made the assumption that I could drop the sheet into a div (as background image) and then apply a scaleX transition to the div when I need to face left, and remove the transition when I need to turn right.

I’m applying the horizontal flip by adding a CSS classname to the div.

The CSS:

-moz-transform: scaleX(-1);
-webkit-transform: scaleX(-1);
-o-transform: scaleX(-1);
transform: scaleX(-1);
filter: FlipH; /*for IE*/
-ms-filter: “FlipH”;

Then when I need my character to face left I add the class name to the character div:

function faceLeft() {characterDIV.className = “flip-horizontal”;}
function faceRight() {characterDIV.className = “”;}

So, is this good? Works fantastically on the desktop browsers and really well on Android.

BUT, on iOS (iPad in my tests) there is a BIG lag when the webkit transform is applied.

I mean big – in my game there can be up to a second long hang. Totally unacceptable for any game usage (unless as a one shot on initialisation).

The answer? Unfortunately I couldn’t come up with a technical solution. I had to resort to putting the reverse animation on the spritesheet. This gives me the performance I want – but at the expense of more weight to the game.

If my game has many characters then I am essentially doubling my asset weight for those characters. Boo.


Introduction to Mercator Projections, Latitude and Longitude

Or how to place a map coordinate into 3D space. This post is a brief walk through of the basics from my 2010 presentation “Where in the world? Intercontinental Ballistic Flash”.

Belgian, Flemish geographer and cartographer Gerardus Mercator, in 1569 presented a cylindrical map projection. The Mercator Projection quickly became the standard map used for nautical purposes. It’s advantages were that the scale is linear in any direction around a point, meaning all angles were preserved (conformal).

Geographer and cartographer Gerardus Mercator

Gerardus Mercator

Around the equator feature shapes are accurately portrayed but as the poles are approached there is a size and shape distortion. The scale increases as the pole is neared, eventually becoming infinite when the pole is reached.

If you imagine the world as a beach ball. The Mercator Projection is the equivalent of cutting open the ball at each pole and stretching the skin to form a cylinder. Now slice down the cylinder and you have the map.

The first Mercator projected map. 1569.

All map projections distort the shape or size of the Earth’s (or for that matter any other planet’s) surface. The Mercator Projection exaggerates areas far from the equator. Greenland seems as large as Africa, but is in fact 1/14 of the size, Antartica appears to be the largest continent but is in fact only 5th in terms of area.

Despite the obvious distortions, the Mercator Projection makes a great interactive map. Thanks to the conformality it can be zoomed nearly seamlessly.

So here we have a system that converts a 3D scene, the real world, onto a 2D plane, the map. This system can just as easily convert the 2D back to 3D. It is a coordinate system that requires two positional parameters and one constant: the planet radius.

The positional parameters are latitude and longitude. As developers we are used to standard coordinates x and y. Across then up. Horizontal then vertical. With latitude and longitude we have to think differently. Latitude is vertical and longitude is across. Up then across. Latitudes run from pole to pole, while longitudes run around the planet.

There are 180 degrees of latitude from the South Pole to the North pole, and 360 degrees around the planet. Imagine yourself sat at the centre of the Earth with a laser pointer. Point at the Equator then you are at 0 degrees latitude, at the South Pole -90 degrees and at the North Pole 90 degrees. Now point at the Equator again you can turn 180 degrees around the equator to the right (-180 degrees longitude) and to the left (180 degrees longitude).

With these any point on the surface of the planet can be recorded or indeed any position on a map.

So we have a system for calculating a position on the surface of a sphere, a 3D coordinate, but how do we convert latitude, longitude and the planet’s radius into a 3D x,y,z coordinate?

public static function convertLatLonTo3DPos(lat:Number, lon:Number, radius:Number):Vector3D
var v3d:Vector3D = new Vector3D();

//Convert Lat Lon Degrees to Radians
var latRadians:Number = lat * TO_RADIANS;
var lonRadians:Number = lon * TO_RADIANS;

v3d.x = radius * Math.cos(lonRadians) * Math.sin(latRadians);
v3d.z = radius * Math.sin(lonRadians) * Math.sin(latRadians);
v3d.y = -radius * Math.cos(latRadians);

return v3d

Here the latitude and longitude are converted into radians ( TO_RADIANS:Number = Math.PI / 180 ). Then the trigonomic functions are applied to the planet radius to return a vector3D x,y and z.


AS3 Magnifying Glass Class :: Pixelbender Lense Refraction

The AS3 Magnifying Glass is a lense refraction class employing PixelBender. The class is an encapsulated method that takes a source image, a position and radius and returns a refracted result in sprite form.

I needed to represent a spy glass in my current project, and was looking for a very efficient method to achieve this. PixelBender seemed the obvious route and I’m pretty impressed by the speeds I am getting. I have max-ed out the frame rate and am still getting full (120) fps.

The MagnifyingGlass effect is the resultant class. The class embeds a pixelbender filter that spherizes it’s input and returns this as a sprite.

When using the class, the source image should be sent to the MagnifyingGlass full size, and be displayed to the user at a reduced size. This helps to preserve the integrity of the refracted image.


//refraction: 0=Lots, 1 =None
//radius: The radius of the magnifying glass
//position_point: The position of the magnifying glass on the source image
//source_pic: BitmapData of the source picture
magnifying_glass = new MagnifyingGlass(refraction,radius, posn_point, source_pic)


AS3 Magnifying Glass Class

The AS3 MagnifyingGlass Class

I have set up a quick demo that shows the class at work on 3 different images. Press any key to change the image.

Image#1: Have a look around a bit of England & Wales. Enjoy.
Image#2: Hundreds of cartoon characters. See if you can find Quagmire! – Gigity.
Image#3: There is a sheep in there somewhere.

NOTE: The PixelBender filter used here is based on Joa Ebert’s Spherize Filter originally built in Hydra – the forerunner of PixelBender.

NOTE: This requires Flash Player 10 and above.

Demo: Magnifying Glass Class Demo


AS3 Flamer Class :: Setting things on fire

The Flamer Class is a quick and easy method to set things on fire. Throw some fuel (any display object) at the class and make it burn.

While working on another project I needed to make some lightweight flames. I looked around, tried a bit of perlin noise, some convolution filters – then some PixelBender filtering – I wasn’t really happy with the results.

I found the excellent Saqoosha’s Fire on Wonderfl.
This demo had nearly the flicker and colour mapping that I was looking for. Rendering the perlin noise on each frame was causing a bit too much processor overhead for my purposes.
Instead of rendering two perlin octaves and moving the layers against each other, I took two separate single octave perlin noise bitmaps and rotated one against the other while blending.
This gives a nice effect and is very lightweight. With the Saqoosha method I was clocking at a steady 26fps, with my lightweight method I could get 90fps.

To get the flame hues I set up a gradient box, threw some colours at it, loaded those colours into an array which I then pushed to a palette map.

So how to use the Flamer class:

import swingpants.effect.Flamer

var flamer:Flamer=new Flamer(display_object)

addEventListener(Event.ENTER_FRAME, enterFrameHandler)
function enterFrameHandler(event:Event):void

Your object will now be on fire. Feel naughty?

You can set the render width and height and also set the direction of the flames by setting a point vector.

var flamer:Flamer=new Flamer(display_object,render_width, render_height, flame_direction_point)

//The colour of the flames can be set with one of the presets (There are 4 at the moment – ORANGE_FLAME, BLUE_FLAME, YELLOW_FLAME, GREEN_FLAME – but I will be adding more)

//Direction can be set on the fly:

Here is a demo of a pure code use of the Flamer: The Flaming Vortex. You can click on the flash to initiate an explosion, and pressing space will change the colour. Have a play:

Flaming Sun

Flamer Class. The flaming vortex demo

This next demo is an example of throwing a movieclip/sprite at the Flamer class. Don’t laugh, I quite literally spent 10 minutes putting the anims together then threw them at the Flamer. Click on Flash to change colour and object.

Flaming Car

Flamer Class Demo. Help, my car is on fire

Lots of fun can be had by throwing different animations at the Flamer. Control some with your mouse/keys. Become a twisted fire starter.

The Flamer class could do with a few more features, but is a pretty good start. The speed is pretty good, I’m happy to receive any improvement recommendations.

I have packed the Flamer class and demos up in a zip if you want to have a play:
DOWNLOAD: Flamer Class and Demos

DEMO #1: Flaming Vortex
DEMO #2: Burning Movieclips


Away3DLite: Translating 3D Coordinates to 2D Screen Position

I have been playing with the awesome Away3DLite. Playing with 1000s of polygons is very liberating, but still doesn’t mean we can slack off with the optimisation. It is important to take any opportunity to lessen the number of calculations performed per frame by the player.

To this end, I was just putting together a 2D layer above my 3D scene when I found that the camera.screen function (available in the standard Away3D library) that projects 3D coordinates(x,y,z) to 2D screen positions (x,y) wasn’t present.

In Away3DLite we have to calculate this ourselves. The salient information can be gained through a model or container’s viewMatrix3D property. To get an accurate screen position the the x,y,and z positions are drawn from viewMatrix3D. Each of x and y are divided by the z value and any screen offsets are applied.

Here is the method as a function:

public function calc2DCoords(screen_element:*):Point

var posn:Vector3D = screen_element.viewMatrix3D.position
var screenX:Number = posn.x / posn.z;
var screenY:Number = posn.y / posn.z;

return new Point(screenX+screenW_offset,screenY+screeH_offset)

Pass through a screen element (a model, primitive or object container) and the 2D result will be returned. The screenW_offset and screenH_offset are required if the ‘view’ has been centred on the stage.

I have put together a demo here to demonstrate the function. I load a couple of models into the scene and let a 2D info panel follow each around the screen.

Got to keep a close eye on those tubbies

Demo: Translating 3D Coordinates to 2D Screen Position
Source: ZIP


Reasons to be Creative 2012

FITC Amsterdam 2012

Flash on the Beach 2011

Flash on the Beach 2010

Flash on the Beach 2009

Swingpants at FOTB2009

Twitter Updates


Get every new post delivered to your Inbox.