When it comes to displaying graphics, the most common question a program must ask is “Where is it?” It may seem like a straightforward question, but it has a lot of complex nuances. Take for instance the image below of the ship in Space ROX.

Space ROX's Local Coordinates

Now, the rotation point of the entire graphic is at the center of the ship. Right below the ship is the rear thrusters firing. When the ship is accelerating and I need to draw a particle effect, I need to find out where the tip of the rear thrusters are as the origin of the particle. When I ask ActionScript 3.0, what is the x,y coordinate of the RearThruster, it simply says it is at 0,190. But this is local coordinates – it doesn’t matter which way the ship is rotated or how much it has been scaled.

Space ROX Rotated and Scaled

What Actionscript 3.0 offers is a function called “localToGlobal” which can tell me where a local point in this movie clip is in relation to the screen’s coordinates.

This is great, but it has one major flaw in terms of game programming.  The “localToGlobal” function only tells you the coordinate of the object in relation to the screen – not in relation to the world.  If the camera and background never move like in the first versions of Asteroids, then this is sufficient information that we need.  But once the camera starts moving around a world, then we need to convert Actionscript’s “global” coordinates to the “gameworld” coordinate plane to ensure that if the camera moves, the particles and effects, correctly shift along with the camera.

What is so painful about this is that my original approach to solving the local-to-screen-to-world coordinate system is that I was trying to figure it out using what little I remember of Trigonometry.  It was a relief to see that Adobe went through the trouble of creating a build-in and optimized version of what I was attempting to write.