It doesn’t have to be hard work, however. What we need to do is take a moment to consider a strategy that will work for us. This tutorial will focus on the code rather than an explanation of the math. Understanding the math relies on an understanding of Trigonometry, in particular sine and cosine functions. If this interests you you could start with Using trigonometric functions in 2d games.
The code samples are in Java because it was Java that I implemented it in a game. Also, because there appears to be very few Java examples on the Web but already a few C++ do exist although I haven’t seen any that talk through the stages of adding it to an actual game.

Apart from the class syntax and the member variable access specifiers during declaration (public, private, whatever) there would be virtually no changes between the Java or C++ code. There will obviously be a difference between some of the method/function names and the classes/libraries you will need to import/#include.

Planning for irregular polygon collision detection

What we want to know is when a point from another object(we will focus on the points of the triangle shaped ship) goes inside the asteroid. It is not enough to just detect an intersection because this is ambiguous with rotating irregular polygons.

Although we will not be detecting any asteroid on asteroid collisions in this tutorial, as you will see when our collision detection nears completion, achieving asteroid on asteroid collision detection would not present much of an extra challenge. It would, however, put an extra strain on the device’s CPU. In addition, once you get this system working, it will be trivial to implement bullet (single vertex) collision with an asteroid.

Colliding with an asteroid

We need to find out if any single vertex from the ship crosses into the space contained by the vertices of the asteroid. An additional problem is that the asteroid is not only a moving target but also a rotating one. We will not only have to rotate and translate all the vertices of the objects but the asteroids as well. We don’t want to do this every frame.

Being more specific, we need to calculate any vertex of the ship crossing the line made between each pair of vertices on the asteroid. The first problem, as already mentioned is, that detecting the intersection of a point is ambiguous with a rotating irregular polygon.

Fortunately at this point we can fall back on a clever and simple algorithm, devised and refined by mathematicians far greater than myself.

We will use the Crossing Number algorithm. Here is how it works.

The Crossing Number algorithm

We compute the line made by a pair of vertices and use conventional trigonometry to see if a particular vertex from the object being tested crossed that line. If it did we increment a variable from 0 to 1. Next, we test the same point against each and every line made by each vertex pair from an asteroid, incrementing our variable each time it does. If after testing the vertex against every line, using the crossing number algorithm our variable is odd, we have a hit. If it is even, no collision has occurred.

Of course, if no collision has occurred we must proceed to test each and every vertex from the object being tested against each and every line formed out of the vertex pairs on the asteroid. Here is a visual representation of the crossing number algorithm in action.

Notice in the previous image that all the cases where the vertex is inside the asteroid, the value is odd.

With complex calculations going on we will definitely want to do a simple first-phase test to see if it is likely there has been a collision, before doing the complex tests.

The steps and overview of asteroid collision detection

The radius overlap test is quite appropriate when testing a single vertex like a bullet, a spinning triangle like a ship or indeed a rotating asteroid. With this in mind, here is an overview of the whole process we will use for testing for collisions between asteroids:

1. Has the radius of the ship overlapped with the radius of an asteroid?
2. If yes has the first vertex of the object crossed the first line of the asteroid
3. if yes

   crossingNumber ++

4. Repeat step 2 with each line on the object
5. If

   crossingNumber

   is odd return true to calling code because a collision has occurred.
6. If

   crossingNumber

   is even no collision has occurred(yet) repeat steps 2, 3 and 4 with the next vertex of the object being tested.
7. If all vertices have been tested and we have reached here then no collision has occurred

Game programming patterns are beyond the scope of this tutorial so I want to present an object-oriented solution that is simple to grasp and easily adapted. We will set up a collision detection class called

CD

detect()

Doing the calculations outside of the objects themselves means we will need a whole bunch of data about the objects we will be testing, made accessible to our new

CD

Coding a collision detection solution for irregular polygons in C++ or Java

The first class we will call

CollisionPackage

CollisionPackage

When the time comes to rotate all the points to their real world location, our collision package will need to know which way the object is facing. For this we have a float called

facingAngle

We will need a copy of the un-rotated model space vertices. We will not go to the trouble of updating these every frame and will do so only after the first phase of collision detection shows a collision is likely/possible. We will also hold a pre-computed value for the length of the array that holds these vertices. It can potentially save time in the collision detection process.

Therefore, we will also need the world coordinates of the object. This is a single point in the centre of the object. This we will update every frame. Each object will have a pre-computed

radius

detect()

PointF

Vector2f

We will also have a couple of

PointF

currentPoint

currentPoint2

The CollisionPackage class

Create a new class, call it CollisionPackage and implement the members we have just discussed.

/*
	All objects which can collide have a collision package.
	Asteroids, ship, bullets. The structure seems like slight
	overkill for bullets but it keeps the code generic,
	and the use of vertexListLength means there isn't any
	actual speed overhead. Also if we wanted line, triangle or
	even spinning bullets the code wouldn't need to change.
*/

public class CollisionPackage {

    /*
		All the members are public to avoid multiple calls
		to getters and setters.

		The facing angle allows us to calculate the
		current world coordinates of each vertex using
		the model-space coordinates in vertexList.
	*/
    public float facingAngle;

    // The model-space coordinates
    public PointF[] vertexList;

    /*
		The number of vertices in vertexList
		is kept in this next int because it is pre-calculated
		and we can use it in our loops instead of
		continually calling vertexList.length.
	*/
    public int vertexListLength;

    // Where is the centre of the object?
    public PointF worldLocation;

    /*
		This next float will be used to detect if the circle shaped
		hitboxes collide. It represents the furthest point
		from the centre of any given object.
		Each object will set this slightly differently.
		The ship will use height/2 an asteroid will use
		whatever the max length of a line can be.
		This tutorial doesn't cover randomly generating
		the asteroid vertices. For this tutorial, 25
		is assumed. As long as the real length isn't greater
		the value will work for you to.
	*/
    public float radius;

    // A couple of points to store results and avoid creating new
    // objects during intensive collision detection
    public PointF currentPoint = new PointF();
    public PointF currentPoint2 = new PointF();

Next, in the same class, we have a simple constructor that will receive all the necessary data from each object at the end of each object’s constructor. Implement the

CollisionPackage

public CollisionPackage(
	PointF[] vertexList,
	PointF worldLocation,
	float radius,
	float facingAngle){
	vertexListLength = vertexList.length;

   this.vertexList = new PointF[vertexListLength];

	// Make a copy of the array
	for (int i = 0; i < vertexListLength; i++) {
		this.vertexList[i] = new PointF();
		this.vertexList[i].x = vertexList[i].x;
		this.vertexList[i].y = vertexList[i].y;
	}

   this.worldLocation = new PointF();
   this.worldLocation = worldLocation;
   this.radius = radius;
   this.facingAngle = facingAngle;

}// End constructor

}// End class

That’s all the data we need to do our advanced collision detection.

Adding collision packages to the game objects

Add a new member of the type

CollisionPackage

PointF

points

CollisionPackage

points

worldLocation

// Inside Ship, Asteroid, Whatever class
CollisionPackage cp;

// Next, a 2d representation using PointF of
// the vertices. Used to build shipVertices
// and to pass to the CollisionPackage constructor
PointF[] points;
PonitF worldLocation;
float radius;
float facingAngle;

/*
	Your code to initialize the points array,
	location and angle of your ship goes here.
	This will vary depending upon how your game is implemented
	Initialize the above variables to represent your ship/object
	...
	...
	...
*/

It is possible that a vertex from the asteroid might sneak inside the ship. Remember that we will only be testing for vertices from the ship entering the asteroid. This next image shows the problem.

We could completely solve this problem by testing all the asteroids vertices against all of the ship’s lines as well as what we are planning to do (testing all the ship’s vertices against all the asteroids lines). This would slow the game down.

For this reason, it might also be worth adding three extra model space coordinates to the ship. Your drawing code does not need to know about these. They are positioned in the middle of each of the three lines which make the ship. We do this to make it harder for a vertex of an asteroid to drift inside the ship without a vertex of the ship being inside the asteroid. Just adding a few extra points to the ship does produce near-perfect detection as shown next.

Now our object has been initialized we can initialize the collision package.

Creating a CollisionPackage for the ship

Here is how the code might look in the constructor of the class that represents a ship. Be sure to read the comments too.

// Initialize the collision package
// The code assumes you have
// initialized points, worldLocation, radius and facingAngle

cp = new CollisionPackage(
	points,
	worldLocation,
	radius,
	facingAngle);

Creating the CollisionPackage for the asteroid

As stated, we will also need a collision package in the class that represents an asteroid. Use the exact same steps above. Obviously, the way that you decide the model space coordinates and location in the world is specific to your implementation. As long as you have an initialized

CollisionPackage

cp

Synchronise the collision package each frame

The code in the update section of your game objects (ship/asteroid/whatever) would look like this. Notice we do not do anything with the array of vertices.

// Update the collision package
cp.facingAngle = facingAngle;
cp.worldLocation = WorldLocation;

Now we can code the actual collision detection.

The CD (Collision Detection) class

What we will do now is implement the first phase of collision detection. As we have discussed, the algorithms we will use are computationally expensive and we only want to use them when there is a realistic chance of a collision. For this reason, we will check the ship against every asteroid using the radius overlapping method. You could go further than this tutorial and implement neighbour checking before this as well.

These first checks will decide whether we then move on to do the more accurate and computationally expensive checks. We will implement these second phase checks a bit later, which will use more advanced algorithms and put the data in our collision packages to full use.

To get started create a new class and call it

CD

PointF

private static PointF rotatedPoint = new PointF();

Now for the method.

Implementing radius overlapping for asteroids and ship

Let’s add our method to the

CD

The code works by making a virtual triangle with a missing side and then using Pythagoras’ theorem to calculate the missing side, which is the distance between the centre points of the two objects. Then if the combined radii of the two objects are greater than the distance between the two object centres we have an overlap.

Add the

detect()

return true

public static boolean detect(
	CollisionPackage cp1,
	CollisionPackage cp2) {

	boolean collided = false;

	// Check circle collision between the two objects

	// Get the distance of the two objects from
	// the centre of the circles on the x axis
	float distanceX = (cp1.worldLocation.x)
		- (cp2.worldLocation.x);

	// Get the distance of the two objects from
	// the centre of the circles on the y axis
	float distanceY = (cp1.worldLocation.y)
		- (cp2.worldLocation.y);

	// Calculate the distance between the center of each circle
	double distance = Math.sqrt(
		distanceX * distanceX + distanceY * distanceY);

	// Finally, see if the two circles overlap
	// If they do it is worth doing the more intensive
	// and accurate check.
	if (distance < cp1.radius + cp2.radius) {

		// todo  Eventually we will add the
		// more accurate code here
		// todo and delete the line below.
		collided = true;
	}

	return collided;
}

Now we can test for the ship hitting an asteroid, although only with radius overlapping method.

Your code in the update part of the main game loop to check an array full of asteroid objects against an object called ship, might look something like this next code.

// Check collisions between asteroids and ship
// Loop through each asteroid in turn

for (int asteroidNum = 0;
	asteroidNum < numAsteroids;
	asteroidNum++) {

	/*
		In a real game you might have a way to
		check whether a specific asteroid is
		currently active before testing
		No point doing anything if asteroid blew up last frame
	*/

	// Perform the collision checks by
	// passing in the collision packages
	if (CD.detect(ship.cp, asteroids[asteroidNum].cp)) {

		// hit!
		// What happens here is specific to your game
	}

}

At this point, you could play your game and our rudimentary collision detection will work. But fly too close to an asteroid and you will lose a life without actually needing to touch it. We want to be able to skim the surface of an asteroid and only get a hit when a point actually crosses into the exact space of another object.

Precise collision detection with asteroids

Once we have rotated and translated the asteroid’s vertices we will need to handle them in pairs of vertices that each forms a line. It is these lines that we will test against each and every vertex from the spaceship. This test will enable us to use our crossing number algorithm which we have discussed.
We need to do all of this within the body of the

if (distance < cp1.radius + cp2.radius) { ...}

where we previously just returned true.

There is quite allot of code so we will split it into chunks so we can see what is going on at each stage. Also, the code indentation will not always be consistent from block to block. This is so the format is in the most readable way possible for a web page. The next few blocks of code are the entire contents of the aforementioned if block that needs replacing.

Before we jump into the

for

if (distance < cp1.radius + cp2.radius) {

	// todo  Eventually we will add the
	// more accurate code here
	// todo and delete the line below.
	// collided = true;

	double radianAngle1 = ((cp1.facingAngle / 180) * Math.PI);
	double cosAngle1 = Math.cos(radianAngle1);
	double sinAngle1 = Math.sin(radianAngle1);

	double radianAngle2 = ((cp2.facingAngle / 180) * Math.PI);
	double cosAngle2 = Math.cos(radianAngle2);
	double sinAngle2 = Math.sin(radianAngle2);

	int numCrosses = 0; // The number of times we cross a side

	float worldUnrotatedX;
	float worldUnrotatedY;

Now we loop through all the vertices from

cp2

cp1

CD.detect()

In the next block of code, we translate then rotate the object being tested against an asteroid.

for (int i = 0; i < cp1.vertexListLength; i++) {

	worldUnrotatedX = cp1.worldLocation.x + cp1.vertexList[i].x;
	worldUnrotatedY = cp1.worldLocation.y + cp1.vertexList[i].y;

	// Now rotate the newly updated point, stored in currentPoint
	// around the centre point of the object (worldLocation)
	cp1.currentPoint.x = cp1.worldLocation.x +
		(int) ((worldUnrotatedX - cp1.worldLocation.x)
		* cosAngle1 - (worldUnrotatedY - cp1.worldLocation.y) *
		sinAngle1);

	cp1.currentPoint.y = cp1.worldLocation.y +
		(int) ((worldUnrotatedX - cp1.worldLocation.x)
		* sinAngle1 + (worldUnrotatedY - cp1.worldLocation.y) *
		cosAngle1);

	// cp1.currentPoint now hold the x/y
	// world coordinates of the first point to test

Now, using a pair of vertices at a time, from the asteroid, we translate and rotate both to their final world-space coordinates, ready for the next block of code where we will use the vertex locations calculated in the previous block and this block.

/*
	Use two vertices at a time to represent the line we are testing
	We don't test the last vertex because we are testing pairs
	and the last vertex of cp2 is the padded extra vertex.
	It will form part of the last side when we test vertexList[5]
*/

for (int j = 0; j < cp2.vertexListLength - 1; j++) {

	// Now we get the rotated coordinates of
	// BOTH the current 2 points being
	// used to form a side from cp2 (the asteroid)
	// First we need to rotate the model-space
	// coordinate we are testing
	// to its current world position
	// First update the regular un-rotated model space coordinates
	// relative to the current world location (centre of object)

	worldUnrotatedX = cp2.worldLocation.x + cp2.vertexList[j].x;
	worldUnrotatedY = cp2.worldLocation.y + cp2.vertexList[j].y;

	// Now rotate the newly updated point, stored in worldUnrotatedX/y
	// around the centre point of the object (worldLocation)

	cp2.currentPoint.x = cp2.worldLocation.x +
		(int) ((worldUnrotatedX - cp2.worldLocation.x)
		* cosAngle2 - (worldUnrotatedY - cp2.worldLocation.y) *
		sinAngle2);

	cp2.currentPoint.y = cp2.worldLocation.y +
		(int) ((worldUnrotatedX - cp2.worldLocation.x)
		* sinAngle2 + (worldUnrotatedY - cp2.worldLocation.y) *
		cosAngle2);

	// cp2.currentPoint now hold the x/y world coordinates
	// of the first point that
	// will represent a line from the asteroid

	// Now we can do exactly the same for the
	// second vertex and store it in
	// currentPoint2. We will then have a point and a line (two
	// vertices)we can use the
	// crossing number algorithm on.

	worldUnrotatedX = cp2.worldLocation.x
		+ cp2.vertexList[i + 1].x;

	worldUnrotatedY = cp2.worldLocation.y
		+ cp2.vertexList[i + 1].y;

	// Now rotate the newly updated point, stored in worldUnrotatedX/Y
	// around the centre point of the object (worldLocation)
	cp2.currentPoint2.x = cp2.worldLocation.x +
		(int) ((worldUnrotatedX - cp2.worldLocation.x)
		* cosAngle2 - (worldUnrotatedY - cp2.worldLocation.y)
		* sinAngle2);

	cp2.currentPoint2.y = cp2.worldLocation.y +
		(int) ((worldUnrotatedX - cp2.worldLocation.x)
		* sinAngle2 + (worldUnrotatedY - cp2.worldLocation.y)
		* cosAngle2);

Here we detect if the current vertex being tested crosses the line formed by the current vertex pair of the asteroid. If it does we increment

numCrosses

// And now we can test the rotated point from cp1 against the
// rotated points which form a side from cp2

if (((cp2.currentPoint.y > cp1.currentPoint.y)
	!= cp2.currentPoint2.y > cp1.currentPoint.y))
	&&(cp1.currentPoint.x <
	(cp2.currentPoint2.x - cp2.currentPoint2.x)
	*(cp1.currentPoint.y - cp2.currentPoint.y)
	/ (cp2.currentPoint2.y 	- cp2.currentPoint.y)
	+ cp2.currentPoint.x)){

	numCrosses++;
} // end if
} // end inner for loop
} // end outer for loop

We could have made a separate method to rotate angles as we do this so often. It is not as straightforward as it might seem, however. If we put the rotation code in a method we would either have to put the initial sine and cosine calculations in it which would make it slow or pre-compute them before the method call and the

for

Also if you consider that we need more than one value for both sine and cosine of an angle, the method needs to ‘know’ which to use, which isn’t rocket science but it starts to get even less compact than we might have initially imagined. So I opted for avoiding the method call altogether, even if the code is a little sprawling.

So if you want to tidy things up, go ahead. I just thought it was worth discussing why I did things this way.

Finally, we use the modulus operator to determine if

numCrosses

true

false

// So do we have a collision?
if (numCrosses % 2 == 0) {
	// even number of crosses(outside asteroid)
   collided = false;
} else {
	// odd number of crosses(inside asteroid)
   	collided = true;
}

}// end if

You can now fly your ship right up to the asteroids and only get hit when it really looks like you should.

You can see the simple Asteroids game I adapted this code from by downloading the GameCodeSchool app from GooglePlay.

Suppose we have 10 objects that each need to be checked against each other, then we need to perform 10 squared (100) collision checks. If we do neighbour checking first, we can significantly reduce this number. In the very hypothetical situation in the diagram, we would only need to do an absolute maximum of 11 collision checks, instead of 100, for our 10 objects, if we first check to see if objects share the same sector.

Implementing this in code can be as simple as having a sector member variable for each game object, then looping through the list of objects and just checking when they are in the same sector.

Whichever method(s) of collision detection your game uses it is almost always worth doing the neighbor checking of some sort. Sometimes, if your collision detection method is quite intensive, it can be worth performing a less intensive(and probably less precise) collision detection method and when that less intensive method detects a collision, perform more intensive version.

For example in the Crossing number algorithm tutorial we use rectangle intersection as a preliminary check.

Here is some pseudo code to show how we can implement this method. The code assumes that the

ship

enemy

centerX

centerY

radius

distanceX

distanceY

Math.sqrt

double

The code below doesn’t mention the types as they will vary depending upon your platform and requirements.

// Get the distance of the two objects from
// the edges of the circles on the x axis

distanceX = (ship.centerX + ship.radius) -
	(enemy.centerX + enemy.radius;

// Get the distance of the two objects from
// the edges of the circles on the y axis
distanceY = (ship.centerY + ship.radius) -
	(enemy.centerY + enemy.radius;

// Calculate the distance between the center of each circle
// Math.sqrt is from Java. All modern languages have an equivalent
distance = Math.sqrt(distanceX * distanceX + distanceY * distanceY);

// Finally see if the two circles overlap
if (distance < ship.radius + enemy.radius) {
	// bump
}

The key to the whole thing is the way we initialize

distance

Math.sqrt(distanceX * distanceX + distanceY * distanceY);

If the previous line of code looks a little confusing, it is simply using Pythagoras’ theorem to get the length of the hypotenuse of a triangle which is equal in length to a straight line drawn between the centers of the two circles. In the last line of our solution, we test if distance is greater than the ship.radius + enemy.radius, then we can be certain that we must have a collision. That is because if the center points of two circles are closer than the combined length of their radii, therefore they must be overlapping.

Where the hitboxes intersect, we have a collision. As we can see from the title image, this is far from perfect. However, in some situations, it is sufficient. To implement this method, all we need to do is test for the intersection using the x and y coordinates of both objects.

This next pseudo code (C++/Java-like) shows the use of a hypothetical

getHitBox

if(ship.getHitbox().right > enemy.getHitbox().left
	&& ship.getHitbox().left < enemy.getHitbox().right )
{
	// Ship is intersecting on x axis 

	// But they could be at different heights
	if(ship.getHitbox().top < enemy.getHitbox().bottom  		&& ship.getHitbox().bottom > enemy.getHitbox().top )
	{
		// Ship is intersecting enemy on y axis as well
		// Hit detected - take action
	}
}

In the previous code the first

if

Although the rectangles intersect horizontally it is still possible that they are miles apart vertically. The second

if

When both of the

if

The one thing I haven’t explained is this mystical

getHitbox

getHitbox

• SFML has a

  FloatRect

  class and you can use code like

  myFloatRect.x

  and

  myFloatRect.y

  etc. In fact, SFML even has an

  intersects

  method which handles everything for you.
• The Android API has a

  Rect

  class that works similarly to SFML

  FloatRect

  . The

  Rect

  class has a

  contains

  method that also does all the work for you.

Sometimes, however you need to add a bit more functionality to your rectangles/hitboxes so it is worth understanding the simple math that underlies detecting a collision between two rectangles. Then it is worth writing your own code, as above. For example you might want to know whether the collision happened on the left, right, top or bottom. With your own custom

hitbox

If your game objects cannot be represented by rectangles then be sure to take a look at the radius overlap method and the crossing number algorithm. Furthermore, if doing these checks for every object, against every other object, on every frame, sounds like it will badly effect the frame rate then take a look at the Neighbour checking tutorial.

Rotating a point around a central point is actually really simple. Here is the algorithm.

rotated point x = original x * cosine (angle in radians to change by) – original y  * sine (angle in radians to change by)
rotated point y = original x * sine (angle in radians to change by) + original y * cosine (angle in radians to change by)

Notice the subtle but important differences in finding the rotated y coordinate compared to finding the rotated x coordinate.

However, implementing this algorithm in a game takes a bit more discussion. First, let’s look at some really simple angles and coordinates where we don’t really need a fancy algorithm, to prove that this works.

Assume that we have a point at -10, -10 and we rotate it 180 degrees around the point 0,0. We don’t need the algorithm to know that the rotated point will end up at 10,10 as shown in the next diagram.

Doing the math

Let’s break up the algorithm and run the numbers through it a step at a time. If all is well we should come up with the rotated coordinates 10,10.

Starting with finding the rotated  x. Here is a reminder of how we find x.

rotated point x = original x * cosine (angle in radians to change by) – original y  * sine (angle in radians to change by)

X Step 1: original x * cosine (angle to change by)

-10 * cosine of radian equivalent of 180 =

-10 * cosine of pi / 180 * 180 =

-10 * cosine of 3.1415926535897932384626433832795 =

-10 * -1 =

= 10

X Step 2: original y  * sine (angle in radians to change by)

-10 * sine of radian equivalent of 180 =

-10 * sine of pi / 180 * 180 =

-10 * sine of 3.1415926535897932384626433832795 =

– 10 * 0 =

= 0

X Step 3: part 1 – part 2

10 – 0 =

10

So x = 10. Yay!

Now for y. Here is a reminder of how we find y.
rotated point y = original x * sine (angle in radians to change by) + original y * cosine (angle in radians to change by)

Y Part 1: original x * sine (angle in radians to change by)

-10 * sine of radian equivalent of 180 =

-10 * sine of pi / 180 * 180 =

-10 * sine of 3.1415926535897932384626433832795 =

– 10 * 0 =

= 0

Y Part 2: original y * cosine (angle in radians to change by)

-10 * cosine of radian equivalent of 180 =

-10 * cosine of pi / 180 * 180 =

-10 * cosine of 3.1415926535897932384626433832795 =

-10 * -1 =

= 10

Y Part 3: part 1 + part 2

0 + 10 =

10

So y = 10. Yay!

So as we can see the results are as expected. But we need to do more to put this into action in a 2d game.

Object space and world space

The problem is that this algorithm will only work when the centre of the rotation is zero. This is known as the origin. This is why we used the example that we did. It is not to say that there aren’t some cool uses for doing rotations around points other than 0,0 but that is for another article.

All of a sudden our algorithm might seem a little bit useless. However, it is quite simple to accommodate this requirement. We just need to treat each of the objects in our game as having there own coordinate system known as object space yet still existing in the larger game world known as world space.

The simple trick to managing these two different coordinate systems is to track a centre point of the object in world space coordinates as well as the three points that make up the actual vertices of the object.

So let’s say that in the previous image the centre point of the object is in the exact centre of the screen and the resolution of the device is 1920 x 1080. The centre of the object has the coordinates 960, 540.  Also, We can therefore, draw lines between the three vertices as follows:

point a at centre x, centre y + 150 = 960, 690

point b at centre x – 75, centre y – 150 = 885, 390

point c at centre x + 75, centre y – 150 = 1035, 390

Simply join up the dots with three lines and we have our cool triangle spaceship. The problem is that if we try and rotate any of those points, perhaps a (960, 690) we will get results that are totally unusable for rotating our spaceship. In fact, the point would disappear entirely from the screen. Try it with the algorithm we have recently stepped through if you like. However if we simply subtract the centre point from each of the others we will then have a zero based, object space coordinate range identical to the coordinates above and our rotation algorithm will work just fine.

So the solution is as follows. To rotate the spaceship each frame:

1. subtract centre x from point a x
2. subtract centre y from point a y
3. rotate point a
4. add centre x to point a x
5. add centre y to point a y
6. repeat from step 1 for points b and c as well
7. draw the spaceship at the new coordinates

Let’s go ahead and try this out for real.