In my previous two articles I discussed collision detection and response between rigid bodies. In order to do proper collision response between rotating objects, we needed to calculate the moment of inertia about their center of mass. Here I'm going to describe how to get the moment of inertia for an arbitrary triangle, and then I'll show a triangulation algorithm to apply this to any polygon.

Right Triangles

The first step is going to be calculating the moment of inertia for a right triangle, since we can get a simple closed formula. Let's define the right triangle as having a width w and a height h, rotating about the origin with a uniformly distributed mass of density ρ. We know the area is equal to wh/2 so we can calculate the density if we only have the mass.

There is a great YouTube video that walks you through calculating the moment of inertia for a similar triangle, so you can watch that for a more in-depth derivation. In brief, for our right triangle we have:

$$I = \int r^2 dm = \int \int (x^2 + y^2) \rho dx dy = \rho\int_{0}^{w} dx \int_{0}^{\frac{hx}{w}} (x^2 + y^2) dy$$ $$= \rho\int_{0}^{w} dx [(yx^2 + \frac{y^3}{3})]_{0}^{\frac{hx}{w}} = \rho\int_{0}^{w} dx (\frac{hx^3}{w} + \frac{h^3x^3}{3w^3})$$ $$= \rho [\frac{hx^4}{4w} + \frac{h^3x^4}{12w^3}]_{0}^{w} = \rho(\frac{hw^3}{4} + \frac{h^3w}{12})$$

Since we are going to be rotating our triangles about their center of mass (or centroid, since the mass is uniformly distributed) we need to use the parallel axis theorem to calculate moment of inertia at the center of mass. For a triangle we can simply average the coordinates of all three points to get the centroid, and then to get the moment of inertia about the center of mass we'd do:

$$I = I_{cm} + md^2$$ $$I_{cm} = I - md^2$$

Since we're not using coordinate points yet we won't continue along this line, but we'll use it in the next section to get the moment of inertia for any triangle.

Every other triangle is just two right triangles in a trench coat

The way we will get the moment of inertia for any triangle is to split it up into two right triangles, which is very simple. Let our triangle be formed from three arbitrary points p₁, p₂, and p₃. In this case we'll take the edge between p₁ and p₂ as the base, so it has length w. We can get the height by defining two vectors, v₁ = p₂ - p₁ and v₂ = p₃ - p₁, then getting the area of the triangle by getting their cross product and dividing by two. Since A = wh/2 we can get the height:

$$A = \frac{|\vec{v_1} \times \vec{v_2}|}{2} = \frac{wh}{2}$$ $$h = \frac{2A}{w} = \frac{|\vec{v_1} \times \vec{v_2}|}{h}$$

The situation so far with all known quantities is pictured below.

As you can see the triangle is split into two right triangles already by the dotted line representing the height. If we could find the point which we'll call p₄ we could split the width w into parts w₁ and w₂ from which we could calculate the moments of inertia for the right triangle parts. We can use vector projection to project v₂ onto v₁, then add to p₁ to get the coordinates for this point p₄.

$$\vec{p_4} = \vec{p_1} + proj_{\vec{v_2}}\vec{v_1} = \vec{p_1} + \frac{\vec{v_2} \cdot \vec{v_1}}{\|\vec{v_1}\|^2}\vec{v_1} = \vec{p_1} + \frac{\vec{v_2} \cdot \vec{v_1}}{w^2}\vec{v_1}$$

We can then consider the distance between p₁ and p₄ to be w₁, and the distance between p₄ and p₂ to be w₂. We'll consider the two right triangles to be rotating around point p₃ so that we can use the equation we previously derived for moment of inertia of a right triangle.

The moment of inertia for the whole triangle rotating about p₃ is the sum of the moments of inertia of the two right triangle halves rotating about p₃. Using the density ρ we get the following for the whole triangle:

$$I = I_1 + I_2 = \rho(\frac{hw_1^3}{4} + \frac{h^3w_1}{12}) + \rho(\frac{hw_2^3}{4} + \frac{h^3w_2}{12})$$

Then of course we can use the parallel axis theorem described in the previous section to get the moment of inertia about the center of mass. But there's one glaring problem with our formula and definition of p₄. I've conveniently made the triangle in the illustrations with the longest side between p₁ and p₂, so we always have p₄ actually on the triangle. But consider other triangle shapes:

For the above, with the formula we have so far, we're going to be considering mass to exist in the empty space in triangle p₂-p₄-p₃ twice! One thing we could do is simply rotate the labeling of the points until the longest side is between points p₁ and p₂. However, another solution is to check the "handedness" of each triangle and either add or subtract the moment of inertia from the total.

In the above example we will end up calculating the moment of inertia for the empty space once for a "right-handed" triangle and once for a "left-handed" triangle. These will cancel each other out if we check for handedness and we'll be left with only the moment of inertia for the original triangle. Notice that the points for right triangle p₁-p₃-p₄ are clockwise, while the points for right triangle p₂-p₄-p₃ are counterclockwise. In the example with no empty space, you can check that both sets of three points are clockwise.

You can check this "handedness" by checking if the cross product of two vectors along the edge of the triangle is positive or negative. You can choose whatever convention you want for which sign causes you to add or subtract from the total moment of inertia. Just remember to take the absolute value once you have the moment of inertia for the whole shape before plugging into any physics equations! And be careful about the ordering of points - order is important when calculating cross products. For the above example we have:

$$(\vec{p_4} - \vec{p_1}) \times (\vec{p_3} - \vec{p_1}) > 0$$ $$(\vec{p_3} - \vec{p_2}) \times (\vec{p_4} - \vec{p_2}) < 0$$

So the total moment of inertia I for the triangle rotating about point p₃ is:

$$I = |I_1 + (-I_2)|$$

We can then get the centroid for the original triangle and get the moment of inertia about the center of mass with the parallel axis theorem, or do whatever else we have in mind for the moment of inertia.

From Triangles to Polygons

Now that we can calculate the moment of inertia for an arbitrary triangle, we can do the same for a polygon - by splitting it up into triangles. This part actually ends up being pretty simple, provided your polygon is not self-intersecting. If any two edges of the polygon intersect with each other, you'll need to fix that before applying this triangulation algorithm.

Let our polygon be composed of n points p₁, p₂, ... p_n. We can simply let p₁ be an anchor point and sum the moments of inertia for triangles with points p₁, p_i, p_i+1 for i from 2 to n - 1. I'll illustrate this below with a few examples.

Polygon A is convex, and you can see it easily splits into triangles that are all positive space. You could just get the moment of inertia for each of the triangles, use the parallel axis theorem to change the axis to the center of mass of the polygon, then sum the results.

Polygon B however is concave, and it splits into one triangle of negative space and one triangle that is a combination of both positive and negative space. You can use the cross product as the same handedness test that we did for the triangle pieces in the last section to tell if the triangle should contribute positively or negatively to the polygon's moment of inertia. For B you end up subtracting the negative space's contribution to the moment of inertia, then adding it back, leading to a zero net contribution from the negative space.

Here's some JavaScript code of the algorithm for computing moment of inertia of a polygon with the origin as the center of mass:

function sub(p1, p2) {
  return {x: p1.x - p2.x, y: p1.y - p2.y};
}
function add(p1, p2) {
  return {x: p1.x + p2.x, y: p1.y + p2.y};
}
function mul(p, f) {
  return {x: p.x * f, y: p.y * f};
}
function dot(p1, p2) {
  return p1.x * p2.x + p1.y * p2.y;
}
function cross(p1, p2) {
  return p1.x * p2.y - p2.x * p1.y;
}
function dist(p1, p2) {
  p2 = p2 || {x: 0, y: 0};
  const x = p1.x - p2.x, y = p1.y - p2.y;
  return Math.sqrt(x * x + y * y);
}
function calcMomentOfInertia(points, density) {
  let momentOfInertia = 0;
  for (let i = 1; i < points.length - 1; i++) {
    const p1 = points[0], p2 = points[i], p3 = points[i + 1];
    
    const w = dist(p1, p2);
    const w1 = Math.abs(dot(sub(p1, p2), sub(p3, p2)) / w);
    const w2 = Math.abs(w - w1);
    
    const signedTriArea = cross(sub(p3, p1), sub(p2, p1)) / 2;
    const h = 2 * Math.abs(signedTriArea) / w;
    
    const p4 = add(p2, mul(sub(p1, p2), w1 / w));
    
    const cm1 = {
      x: (p2.x + p3.x + p4.x) / 3,
      y: (p2.y + p3.y + p4.y) / 3,
    };
    const cm2 = {
      x: (p1.x + p3.x + p4.x) / 3,
      y: (p1.y + p3.y + p4.y) / 3,
    };
    
    const I1 = density * w1 * h * ((h * h / 4) + (w1 * w1 / 12));
    const I2 = density * w2 * h * ((h * h / 4) + (w2 * w2 / 12));
    const m1 = 0.5 * w1 * h * density;
    const m2 = 0.5 * w2 * h * density;

    const I1cm = I1 - (m1 * Math.pow(dist(cm1, p3), 2));
    const I2cm = I2 - (m2 * Math.pow(dist(cm2, p3), 2));
    
    const momentOfInertiaPart1 = I1cm + (m1 * Math.pow(dist(cm1), 2));
    const momentOfInertiaPart2 = I2cm + (m2 * Math.pow(dist(cm2), 2));
    if (cross(sub(p1, p3), sub(p4, p3)) > 0) {
      momentOfInertia += momentOfInertiaPart1;
    } else {
      momentOfInertia -= momentOfInertiaPart1;
    }
    if (cross(sub(p4, p3), sub(p2, p3)) > 0) {
      momentOfInertia += momentOfInertiaPart2;
    } else {
      momentOfInertia -= momentOfInertiaPart2;
    }
  }
  return Math.abs(momentOfInertia);
}

Getting Density from Mass

If you started with just the mass of your object and you don't know the density, you can calculate the area using the same triangulation formula before doing any moment of inertia calculations. The following JavaScript code will get you the area, then you can divide the mass by this area to get the density.

function sub(p1, p2) {
  return {x: p1.x - p2.x, y: p1.y - p2.y;};
}
function cross(p1, p2) {
  return p1.x * p2.y - p2.x * p1.y;
}
function calcArea(points) {
  let area = 0;
  for (let i = 1; i < points.length - 1; i++) {
    const v1 = sub(points[i+1], points[0]);
    const v2 = sub(points[i], points[0]);
    area += cross(v1, v2) / 2;
  }
  return Math.abs(area);
}

This is a followup to my previous article regarding collision detection between arbitrary polygons. Today I'll be explaining how to update the linear and angular velocity of these polygons in response to that collision. I'm going to go about this with perfectly elastic collision in mind, so both momentum and kinetic energy will be conserved. At the end I'll show how to tweak the formula slightly to change the elasticity with a coefficient of restitution.

There is a great paper here which describes the same collision detection/response algorithm in 3D, and I've used the same notation in case anyone reads both. I found this after getting stuck figuring out how to calculate the magnitude of the impulse exchanged, so thanks to the authors for making that available.

1D Collision Response

First I'm going to briefly go over 1D elastic collision response. We have a mass m₁ moving at a velocity v colliding with another mass m₂. The velocities of m₁, m₂ after collision will be u₁, u₂ respectively. We have two unknowns (u₁, u₂) so we can just combine the conservation equations for momentum and kinetic energy to solve for u₁ and u₂.
$$m_1 v = m_1 u_1 + m_2 u_2$$ $$\frac{1}{2} m_1 v^2 = \frac{1}{2} m_1 u_{1}^2 + \frac{1}{2} m_2 u_{2}^2$$

We end up getting the following values for u₁ and u₂:

$$u_1 = v - \frac{2 m_2 v}{m_1 + m_2}$$ $$u_2 = \frac{2 m_1 v}{m_1 + m_2}$$

This is a nice result, and it's tempting to try the same method with 2D collision response. But a problem arises because we have 4 equations for conserved quantities: linear momentum on the x-axis, linear momentum on the y-axis, angular momentum, and kinetic energy. But we have 6 unknowns: x-axis velocity, y-axis velocity, and angular velocity for each of two objects post-collision. So we'll have to try a different approach.

Impulse and Momentum

Suppose we have polygons A and B with masses m_A, m_B, moments of inertia I_A, I_B, linear velocity vectors v_A, v_B, angular velocities ω_A, ω_B, and vectors from the centers of mass to the point of collision r_A, r_B. Let a vertex of A be colliding with an edge of B and let vector n_B be a unit normal from the colliding edge of B. This is illustrated below.

All of these are known values. We get the normal and the point of collision from the previous article on collision detection. I've written another article describing an algorithm for calculating the moment of inertia for an arbitrary polygon, but you can approximate with a simpler formula like for a thin disc depending on what your objects are shaped like.

The key insight from this diagram is that since we're not considering friction, the entire impulse will be applied along n_B. This impulse vector, which we'll call J, has units of momentum. An impulse J is applied to A at the point r_A, and an equal and opposite impulse -J is applied to B at the point r_B. This is related to Newton's second law of motion. We also know how to apply this impulse to compute all the unknowns we need after collision, as shown below. I've used - and + superscripts to denote quantities before and after collision respectively.

$$\vec{J} = j\vec{n_B}$$ $$\vec{v_{A}^{+}} = \vec{v_{A}^{-}} + \frac{1}{m_A} \vec{J} = \vec{v_{A}^{-}} + \frac{j}{m_A} \vec{n_B}$$ $$\vec{v_{B}^{+}} = \vec{v_{B}^{-}} - \frac{1}{m_B} \vec{J} = \vec{v_{B}^{-}} - \frac{j}{m_B} \vec{n_B}$$ $$\omega_{A}^{+} = \omega_{A}^{-} + \frac{\vec{r_A} \times \vec{J}}{I_A} = \omega_{A}^{-} + \frac{j}{I_A} \vec{r_A} \times \vec{n_B}$$ $$\omega_{B}^{+} = \omega_{B}^{-} - \frac{\vec{r_B} \times \vec{J}}{I_B} = \omega_{B}^{-} - \frac{j}{I_B} \vec{r_B} \times \vec{n_B}$$

Conservation of Energy

If we could only solve for the impulse's magnitude j, we would be able to calculate all the post-collision quantities we need for response! Since we are adding and subtracting the same momentum vector from the system, linear momentum will be conserved no matter what the value of j is. But since this is an elastic collision and we are also conserving kinetic energy, we can use the conservation of kinetic energy to get an equation where j is the only unknown.

$$m_A \|\vec{v_{A}^{-}}\|^2 + I_A {\omega_{A}^{-}}^2 + m_B \|\vec{v_{B}^{-}}\|^2 + I_B {\omega_{B}^{-}}^2 =$$ $$m_A \|\vec{v_{A}^{+}}\|^2 + I_A {\omega_{A}^{+}}^2 + m_B \|\vec{v_{B}^{+}}\|^2 + \frac{1}{2} I_B {\omega_{B}^{+}}^2$$

I've just multipled by 2 on both sides to get rid of some clutter. I haven't expanded any of the post-collision quantities due to the amount of symbols; let's expand and then simplify the first term on the right hand side.

$$m_A \|\vec{v_{A}^{+}}\|^2 = m_A \|\vec{v_{A}^{-}} + \frac{j}{m_A} \vec{n_B}\|^2$$ $$= m_A ((v_{Ax}^{-} + \frac{j}{m_A}n_{Bx})^2 + (v_{Ay}^{-} + \frac{j}{m_A}n_{By})^2)$$ $$= m_A ({v_{Ax}^{-}}^2 + {v_{Ay}^{-}}^2) + m_A (\frac{2j}{m_A} v_{Ax}^{-} n_{Bx} + \frac{2j}{m_A} v_{Ay}^{-} n_{By}) + m_A (\frac{j^2}{m_{A}^2}n_{Bx}^2 + \frac{j^2}{m_{A}^2}n_{By}^2)$$ $$= m_A \|\vec{v_A^{-}}\|^2 + 2j(v_{Ax}^{-} n_{Bx} + v_{Ay}^{-} n_{By}) + \frac{j^2}{m_A} \|\vec{n_B}\|^2$$ $$= m_A \|\vec{v_A^{-}}\|^2 + 2j(\vec{v_A^{-}} \cdot \vec{n_B}) + \frac{j^2}{m_A}$$

We end up with a quadratic equation of j, but notice the first term of the result - it's exactly matched by a term on the left hand side of the conservation of energy equation, so it will cancel out. This ends up happening for all four terms, so the left hand side cancels to zero and we just have the terms with j remaining. When we plug in the other post-collision quantities we get:

$$m_B \|\vec{v_{B}^{+}}\|^2 = m_B \|\vec{v_B^{-}}\|^2 - 2j(\vec{v_B^{-}} \cdot \vec{n_B}) + \frac{j^2}{m_B}$$ $$I_A {\omega_{A}^{+}}^2 = I_A {\omega_{A}^{-}}^2 + 2j\omega_{A}^{-}(\vec{r_A} \times \vec{n_B}) + \frac{j^2}{I_A} (\vec{r_A} \times \vec{n_B})^2$$ $$I_B {\omega_{B}^{+}}^2 = I_B {\omega_{B}^{-}}^2 - 2j\omega_{B}^{-}(\vec{r_A} \times \vec{n_B}) + \frac{j^2}{I_A} (\vec{r_B} \times \vec{n_B})^2$$

Plugging these into the conservation of energy equation and cancelling out all the left hand terms, we get the following:

$$0 = 2j(\vec{v_A^{-}} \cdot \vec{n_B}) + \frac{j^2}{m_A} + 2j\omega_{A}^{-}(\vec{r_A} \times \vec{n_B}) + \frac{j^2}{I_A} (\vec{r_A} \times \vec{n_B})^2$$ $$- 2j(\vec{v_B^{-}} \cdot \vec{n_B}) + \frac{j^2}{m_B} - 2j\omega_{B}^{-}(\vec{r_A} \times \vec{n_B}) + \frac{j^2}{I_A} (\vec{r_B} \times \vec{n_B})^2$$

Since we're not interested in the trivial solution j = 0, we can factor out a j and do some grouping to turn this into a linear function of j (albeit one with quite a few terms).

$$-2(\vec{v_A^{-}} \cdot \vec{n_B} - \vec{v_B^{-}} \cdot \vec{n_B} + \omega_{A}^{-}(\vec{r_A} \times \vec{n_B}) - \omega_{B}^{-}(\vec{r_A} \times \vec{n_B}))$$ $$= j(\frac{1}{m_A} + \frac{1}{m_B} + \frac{(\vec{r_A} \times \vec{n_B})^2}{I_A} + \frac{(\vec{r_B} \times \vec{n_B})^2}{I_B})$$

With this equation we can solve for the only unknown, j, and plug this into our four equations for post-collision linear/angular velocities to solve for those and update our game objects.

Coefficient of Restitution

It turns out you can change the elasticity of the collision by varying the coefficient of restitution C from 0 (inelastic) to 1 (elastic). You can swap out the -2 coefficient in the above equation with -(1 - C) as described in this paper under section 4.1.

$$(-1 - C)(\vec{v_A^{-}} \cdot \vec{n_B} - \vec{v_B^{-}} \cdot \vec{n_B} + \omega_{A}^{-}(\vec{r_A} \times \vec{n_B}) - \omega_{B}^{-}(\vec{r_A} \times \vec{n_B}))$$ $$= j(\frac{1}{m_A} + \frac{1}{m_B} + \frac{(\vec{r_A} \times \vec{n_B})^2}{I_A} + \frac{(\vec{r_B} \times \vec{n_B})^2}{I_B})$$

Demo

This demo brings together both collision detection and response. It creates some arbitrary polygons with randomized velocities, sizes, etc and lets them interact for a bit before replacing them with a new set of objects. You can use the slider to change the coefficient of restitution from 0 to 1. There is a heavy rectangular object that is not drawn but bounds the other objects so that they stay interacting longer instead of flying off the screen.

Coefficient of Restitution:

Limitations

This method works well for two rigid bodies colliding by themselves, but it has some limitations. For one, it doesn't apply any friction forces, which you generally do want for more realism. It also handles objects touching each other at rest rather poorly. More importantly there can still be objects clipping through one another, because when a lighter object is sandwiched between two heavy objects it doesn't transfer force from one heavy object to another, and is often squeezed through one of the heavier objects.

Some problems with objects clipping through one another can be solved by not applying the impulse force unless j > 0. Others require a more complex approach of considering more than two objects at a time.

These problems and others have to be solved by more robust physics engines, but I hope this was a useful introduction to physics of rigid bodies in 2D.

Today I'm going to describe a method for detecting collisions between arbitrary polygons in 2D. This is part one of a two-part series, in the next post I will show how to make use of this collision detection info to do collision response.

Many collision detection methods simply test for intersection between the two polygons - but what if they are moving at high speed? What if you have a point mass that is supposed to collide with a line? In some cases testing for intersection alone will result in objects clipping through other objects - and simple intersection tests won't tell you the time of collision, the point at which collision occurred, or the normal to the surface of collision, all of which are important for proper collision response. This method will allow us to calculate all three.

Let's start by describing a parametric equation of a line passing through p₁ = (x₁, y₁) and p₂ = (x₂, y₂):

$$\vec{p} = \vec{p}_{1} + t (\vec{p}_{2} - \vec{p}_{1})$$

Or in component form:

$$x = x_{1} + t (x_{2} - x_{1})$$ $$y = y_{1} + t (y_{2} - y_{1})$$

"Parametric" in this case means that the points along the line are described by a single parameter t. When t = 0 we're at p₁ and when t = 1 we're at p₂. Any t in [0, 1] is found on the segment described by the two points, any t outside of these values is not found on the segment. Another useful property of this form is that we can describe vertical lines equally well, whereas if we were using y = mx + b we would have to special case situations with vertical lines.

When a collision occurs, it's between a point on polygon A and a line segment on polygon B, or vice versa. So if we can do collision between a moving point and a moving line, then we can easily extrapolate to collision between two moving polygons.

Consider the situation where point p₁ moves to point p₂ as time t₁ goes from 0 to 1. Line segment l₁, l₂ moves to become l₃, l₄ during the same frame.

So we have p₁ going to p₂, l₁ going to l₃, and l₂ going to l₄ as t₁ goes from 0 to 1. To make notation a bit simpler I'll introduce intermediate points a and b that correspond to l₁ going to l₃ and l₂ going to l₄ respectively.

$$\vec{p} = \vec{p}_{1} + t_{1} (\vec{p}_{2} - \vec{p}_{1})$$ $$\vec{a} = \vec{l}_{1} + t_{1} (\vec{l}_{3} - \vec{l}_{1})$$ $$\vec{b} = \vec{l}_{2} + t_{1} (\vec{l}_{4} - \vec{l}_{2})$$

We have another parameter t₂ describing the line from intermediate point a to b, which may or may not intersect with the line going from p₁ to p₂.

$$\vec{p} = \vec{p}_{1} + t_{1} (\vec{p}_{2} - \vec{p}_{1}) = \vec{a} + t_{2} (\vec{b} - \vec{a})$$ $$= (\vec{l}_{1} + t_{1} (\vec{l}_{3} - \vec{l}_{1})) + t_{2} ((\vec{l}_{1} + t_{1} (\vec{l}_{3} - \vec{l}_{1})) - (\vec{l}_{2} + t_{1} (\vec{l}_{4} - \vec{l}_{2})))$$

We need to solve for the two unknowns t₁ and t₂, and luckily we have two equations once we break up the above into x and y components. There are quite a few symbols but I solved for t₂ in the equation with y-components, then subbed out t₂ in the equations with the x-components and isolated t₁. As a result we get a quadratic equation of the form at₁² + bt₁ + c = 0 where a, b, and c are the following:

$$a = (y_{l3} + y_{l2} - y_{l1} - y_{l4})(x_{p2} + x_{l2} - x_{p1} - x_{l4}) -$$ $$(y_{p2} + y_{l2} - y_{p1} - y_{l4})(x_{l3} + x_{l2} - x_{l1} - x_{l4})$$

$$b = (y_{l1} - y_{l2})(x_{p2} + x_{l2} - x_{p1} - x_{l4}) +$$ $$(x_{p1} - x_{l2})(y_{l3} + y_{l2} - y_{l1} - y_{l4}) -$$ $$(y_{p1} - y_{l2})(x_{l3} + x_{l2} - x_{l1} - x_{l4}) -$$ $$(x_{l1} - x_{l2})(y_{p2} + y_{l2} - y_{p1} - y_{l4})$$

$$c = (y_{l1} - y_{l2})(x_{p1} - x_{l2}) -$$ $$(y_{p1} - y_{l2})(x_{l1} - x_{l2})$$

$$t_{1} = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$$

If we solve the quadratic equation for t₁ we will get 0, 1, or 2 solutions. We only care about the smallest solution that is between 0 and 1 inclusive such that t₂ is also between 0 and 1 inclusive. If there is no such solution for t₁, we are done, because there was no collision in the time frame we're considering.

So for each solution between 0 and 1 for t₁, we have to go back and solve for t₂ to confirm that t₂ is also between 0 and 1 - that is, we have to confirm that the collision between the point and the line actually occurred on the segment and not elsewhere on the line.

$$t_{2} = \frac{(\vec{p}_{1} + t_{1} (\vec{p}_{2} - \vec{p}_{1})) - (\vec{l}_{1} + t_{1} (\vec{l}_{3} - \vec{l}_{1}))}{(\vec{l}_{1} + t_{1} (\vec{l}_{3} - \vec{l}_{1})) - (\vec{l}_{2} + t_{1} (\vec{l}_{4} - \vec{l}_{2}))}$$

For simplicity I have shown this as a vector equation, but you need to use either all x or all y components to solve for t₂ - and before attempting to solve you will need to check that the denominator is not zero. The denominator will be nonzero for either x or y components as long as the line segment's length was nonzero at the time of collision. And if the line segment did have zero length, we will say that once again this is evidence of no collision and stop the process here.

So now we know collision occurred between the moving point and the moving line segment at time t₁, and we can solve for the point of collision with the original parametric equation of a line:

$$\vec{p} = \vec{p}_{1} + t_{1} (\vec{p}_{2} - \vec{p}_{1})$$

To extrapolate this to finding the first collision between polygons A and B, we can just run this algorithm for each point in A and each line segment in B, and vice versa. Keeping track of the time of collision we can find the earliest collision, the point at which collision occurred, and the normal of the line segment where we collided which will be used to apply an impulse force. We can rewind time by 1 - t₁ multiplied by the real time between frames in order to prevent intersection between the polygons, and from there we can calculate an impulse force and do collision response.

Demo

You can drag around the start/end points for the point-line collision detection while this demo animates from t₁ from 0 to 1 and uses the above equations to check for collisions.

Drawbacks

Depending on how many objects you have and how frequently they collide, this method for detecting collisions may be too computationally expensive. If we have n points on polygon A and m points on polygon B we will end up having O(nm) quadratic equations to solve, in addition to all the other computation that goes into checking point-line collision. A basic intersection test would also be O(nm) but the constant factor for this method I would expect to be much higher.

Beyond computational complexity, using this method I have approximated rotation of the polygons as straight-line movement of individual points. If your polygon rotates completely once per frame but has no translational velocity, there would be no perceived movement from p₁ to p₂! So this only works if the objects aren't rapidly rotating. If they are, you would need to use more complex parametric equations to represent movement of the points and line segments, which I have not done here.

Some original game art for my latest project, a survival platformer called Nightcrawlers. More to come!

I was curious about how easy this would be to do, so the other day I took the leap and wrote a simple gravity simulator with the Earth and Sun. I googled for "planet table" and used the data from NASA's public planetary fact sheet. I used the average distance from the Sun and average orbital velocity to set initial conditions for the Earth. After applying the law of gravity, I got a nice circular orbit. The masses, distances, and velocities I used are all accurate, but the diameters are much larger than in the actual solar system. With the diameters at the proper scale, the sun would be a tiny spec and the earth would be invisible.

But once I simulated two bodies, it was too easy to resist adding more. So I took the data for Mercury, Venus, and Mars, and added them to the simulation. Each body is compared to every other body when computing accelerations due to gravity, but the Sun's mass is so much greater that it overshadows the planets' gravity no matter how close together they seem.

The orbits are still all circular however, while in real life they are elliptical. I might have been accurately simulating some solar system, but it was not ours. So I looked online again and found a NASA tool called HORIZONS, which can give accurate position and velocity information about celestial bodies in (x, y, z) Cartesian coordinates. I set the coordinate origin to be the Sun and chose data from today, August 28, 2016 to use as the initial conditions for my simulation. The result is a simulation of the actual elliptical orbits of the inner planets, with 1000-second granularity (I re-calculated accelerations due to gravity for every 1000 simulated seconds). I have included a date counter so that you can trace the Earth around the Sun and see that it does in fact cross the same point on the same date.

Then I added some cool comet-looking tails just because.

Here's the simulation with the outer planets instead of the inner planets. The granularity is 100,000 seconds and it is sped up 100x from the earlier simulations since the outer planets have such long orbital periods.

I've been seeing this sort of art everywhere, with moving points connected by lines that are more solid the closer the points are to each other. It's fun to watch and seemed like a simple effect to replicate, so here is my take on it.

Click on the animations below to show them individually. If you are on a phone the animations will probably lag when they are all running on this one page.

This was my first attempt, a set of points starting in random positions with fixed, random velocities:

Here I've given the points random masses and introduced gravity between points, so the velocities can change:

Here I've given the points charges, so that like colors repel and opposite colors attract:

For this last one, rather than give the points completely random positions, I have used the HTML5 canvas's isPointInStroke() function to place points randomly within a power symbol:

It would also be cool to make more complex shapes and fill them in with this pattern, maybe even weighting some areas more than others.

If you wish to make a game from scratch, you must first invent the universe.

Hardware source | Tron source | Circles source | Emulator source | Assembler source | Compiler source

For my latest project, I am diving back into Verilog to create the hardware side of Consolite. For those who don't know, Consolite is the name I've given to my design of a tiny hobbyist game console and associated software toolchain. In my previous posts, I demoed a compiler that translates from a flavor of C to Consolite Assembly, an assembler that translates from Consolite Assembly to binary files, and an emulator that runs the resulting binaries.

In order to "complete the stack" in some sense, the last thing to do was to implement the console on an FPGA. I also wrote a multiplayer Tron light cycle game to check my work, which turned out to be a lot of fun especially since I ended up adding support for multiple SNES controllers. At the end of this post I've added a video of the system in action, as well as an embedded emulator so that you can play Tron in your browser!

This has been a long, extremely interesting project for me, and I may go into more technical detail about components such as the VGA display or SD card reader in future posts. However, this will just be an overview of the capabilities of Consolite, the hardware I used to achieve those capabilities, and of course a demo of the final product.

Major Hardware Modules

For this project, I used the Mimas V2 development board with Spartan 6 FPGA (pictured in Figure 1 below). The board only cost $50, which I consider a great deal given how much functionality it offers.

Figure 1. The Mimas V2 development board running Consolite, with relevant components labeled for clarity: (1) VGA output, (2) audio output, (3) microSD card, (4) LPDDR RAM, (5) Spartan 6 FPGA, (6) mini USB cable for power, (7) 7-segment display, (8) status LEDs, (9) buttons, (10) switches, (11) SNES controller connected to general purpose input/output (GPIO) ports.

Main Memory

The Mimas V2 has 64 MiB of on-board RAM, which is more than enough to store the 64 KiB of main memory and 48 KiB of video memory for a Consolite program. The RAM is (4) in Figure 1 above. A future 32-bit version of Consolite may take advantage of all 64 MiB of RAM, but for now the 16-bit addresses restrict it to 2^16 bytes = 64 KiB.

Video Output

The VGA output, (1) in Figure 1 above, allows you to set up any TV or monitor as a display for Consolite as long as it supports 1024x768@60Hz VGA. The VGA controller in the FPGA reads pixels from the 48 KiB of video memory and outputs a 256x192 pixel, 8-bit color screen (it is scaled up to fill the 1024x768 VGA output).

Audio

The 3.5mm audio jack, (2) in Figure 1 above, is not yet in use, but I plan on adding audio instructions in the future so that games can have music and sound effects.

Persistent Storage

The microSD card slot, (3) in Figure 1 above, is read-only right now. It is used to store up to 256 programs that can load on boot. See the programming documentation for more information on how to use either the microSD card or UART to load and run programs.

In the future the contents of the SD card could be exposed to user programs for reading and writing. This would be useful for saving progress, storing graphics and audio outside of main memory, creating a file system, etc.

Status

The status of the system is shown on the 3-digit 7-segment display and the 8 status LEDs, (7) and (8) in Figure 1 respectively. In Figure 1, the leftmost LED is on to indicate that the RAM calibration has finished (this is a boot-up process). The 6th LED from the left is on to indicate that the boot has completed. The 0x019 (decimal 25) on the 7-segment display indicates that the program is running at an average of 25 cycles per instruction (CPI). The master clock is 100 MHz, so 100 MHz / 25 = 4 million instructions executed per second. In the future I plan on decreasing CPI by making the instruction and data caches more efficient.

The 7-segment display and status LEDs can also indicate errors, and are critical for debugging both the hardware and the software - they're the only indicator you have if something unexpected happens!

User Input

User input can come from a variety of sources, and it is very easy to work with in software via the dedicated INPUT instruction. The buttons, switches, and general purpose input/output (GPIO) ports, labeled (9), (10), and (11) in Figure 1 above, are all exposed to the software. In addition, there is built-in support for up to 8 SNES controllers. Plugged into the GPIO ports at (11) is a modified SNES cable (with a "T" for top). I've written some documentation on how to get the controllers to work with Consolite here.

Power

The board needs 5V power to run. In Figure 1 above the board is getting power from the mini USB port, labeled (6). There is also a barrel jack right above the USB port in the photo, which can be used as an alternate power source.

High Level Circuit Diagram

Figure 2 below shows a high level overview of the circuit implemented on the FPGA chip, which is labeled (5) in Figure 1 above. Some modules are only used for specific instructions; for example, the random number generator is only used for RND, and the millisecond timer is only used for TIME and TIMERST.

Figure 2. A high level circuit diagram of Consolite as implemented on the FPGA.

The UART loader and the SD card loader can't both be used to load a program, so they are connected by signals that disable one once the other has started. The UART loader is used to load programs over USB if there is no SD card detected.

There are 6 modules with either read or write controls going to the RAM interface; these are the UART loader (write only) the SD Card loader (write only), the VGA display (read only), the pixel writer (write only), the instruction cache (read only), and the data cache (read/write). The RAM interface services all of these readers and writers with a round robin policy; the Verilog code for the RAM interface was generated by Xilinx software and is the only module I didn't write myself.

Demo

Emulation

Player 1 (blue) uses WASD to move, player 2 (red) uses the arrow keys. Use space or enter to start. Players 3 through 8 are not connected to any controls. If you're on mobile you're out of luck; two people are needed to play. Click the emulator to start, click off to halt. This prevents the emulator from chewing up your CPU while you read my blog.

Source code (MIT License)

After a few months of development, I'm proud to announce the first release of spaceship.codes! Spaceship.codes is a browser game for programmers, with a built in code editor that the player uses to write JavaScript to control their spaceship. I will illustrate this with a simple example; it might be helpful to open spaceship.codes in a new tab so that you can follow along.

First we need to load a level. We can do this by clicking the "Select Level" button, then clicking the first level (named "Thrust"), and finally clicking the "Load" button. After the level is loaded, you should see something like the following:

If you hover over the blue circle, you should see a tool tip pop up with more information about the object. It has a type of "target" and an objective of "reach" — this means that you need to navigate your spaceship into that blue circle in order to complete the level.

Now we have to write JavaScript code to get the ship into the reach target. Luckily for us, the target is straight ahead! All we need to do is accelerate. The documentation has information in its function reference about the thrust() function — it is a function that takes a single value, the thrust power, in the range from 0 to 1. We want to accelerate at full power, so the only code we need is thrust(1);.

To run this code, we need to open the code editor. There is a button on the left side of the screen that displays and hides the editor. Once it is open, type thrust(1);. This should look similar to the following:

Now you can close the editor. To install the new code, click the "Install & Restart" button. Then, to run the code, click the "Run" button. You should see your spaceship accelerate into the reach target, like the following:

Congratulations! You have completed the first level. The levels that follow quickly increase in difficulty, and force the player to make use of the other available functions, such as turn(), equip(), fire(), etc. Sometimes to complete a level you will simply have to navigate to some target, while other times you may have to destroy enemies or defend targets of your own.

In the future I may write up a tutorial for completing a more complicated level. In the meantime, if you wish to see the completion of a more complicated level in action, copy and paste this code into the editor, then install and run it with the "Obstacle" level loaded. Enjoy!

If you find any bugs or just have questions or comments, you can reach me at robert@fotino.me.

Skip to playing the game!

In my last post, I dipped my toes in the water with the Phaser game engine by making a simple game of Snake. I enjoyed using Phaser and decided to further test its capabilities by making something more complex. I've always wanted to make a side-scrolling shooter, but developing the storyline, levels, and graphics to do it right isn't something I have time for right now. So I thought, what if I cut corners and just made the level a loop, so you can play infinitely? That gave me the idea for a circular platformer, where you run around the surface of a planet and have to defend against waves of enemies. I'm sure it has been done before, but it seemed interesting enough to start working on. You can see the project on Github.

I began by finding an image for the planet and the player on sites for free clip art. The planet I used is earth, because it's familiar and its likeness is readily available. The player image at this point was just a humanoid placeholder. Since I wanted to use the more advanced capabilities of Phaser, I went with the p2.js physics library, which is one of the full-body physics engines bundled with Phaser. It has many, many options for things like collision, friction, bouncing, complex bounding shapes, acceleration, drag, etc. I would recommend looking at the Phaser P2 physics engine docs if you're interested.

The first iteration of the game was just two physics bodies, the planet and the player. The camera was positioned so that the player was always centered horizontally. The player could run and jump around the world, and the camera would rotate and follow. A screenshot is shown below.

At this point I decided that the P2 physics engine was overkill for this sort of game. I learned a lot about how to use it, but I was still getting annoying artifacts like the player sinking into the world a bit before rebounding out. So I took out Phaser's physics and implemented collision detection and response myself.

Another thing I realized at this point was that if there were cities on the planet that the player is trying to defend, they need to be able to see them at all times. I could have implemented a mini-map that showed the player and planet and cities and enemies, but I opted for a different approach. I zoomed out so that you could see the entire planet at once, and stopped the view from rotating with the player. I also added rotating platforms for the player to have something to jump on. A screenshot of this version of the game is shown below.

Next I wanted to make the plain white platforms look nicer, and I wanted to add animations to the player's sprite so that its movements more closely resembled running. I did some sketching of the various sprites that I wanted and their poses, then fired up GIMP. Halfway through trying to make a spaceman sprite, I wanted something more suited to making small graphics so I looked online for a pixel art creator. That's how I found Piskel. Piskel gives you layers, frames, a color palette, and spritesheet export tools. I used it to make the spaceman, spaceship, robot, city, and weapon sprites.

I added three cities to the planet that start out with full health, but which will deteriorate and disappear if you let the robots destroy them. I also added spaceships that come down at regular intervals to drop off between 1 and 5 robots. These robots start out in a random direction, clockwise or counterclockwise. They keep walking slowly around the planet (or on the platform they landed on) until they come in contact with a city. They will attack the city until either it is destroyed or you destroy them. When a robot has successfully destroyed a city, it will continue walking in its starting direction until it gets to the next city.

The player has two weapons, a pistol and an assault rifle. The pistol shoots more slowly but does more damage per bullet. The rifle shoots quickly but the bullets do less damage. Both of these weapons have unlimited ammo. On the wishlist is some type of more powerful weapon that randomly drops from space with a limited amount of ammo. Both robots and their spaceships can be killed. When damage is done to an enemy, it will become slightly more transparent so that you can tell how close it is to being destroyed.

Each robot that is dropped onto the planet has slightly more health than the one before it, and is worth slightly more points. Without this, the game would be too easy because you could just defend one city forever from the easily killed starting robots. There are many different mechanics to increasing the difficulty, with this being the easiest one to implement. Something else on the wishlist is having multiple levels, defined by their arrangement of platforms around the planet. Each level would have predefined waves of enemies that would come and attack. Once all of the enemies were defeated, the player could move onto the next level.

Demo

Not mobile friendly.

• UP - jump
• DOWN - drop through platforms
• LEFT - move left
• RIGHT - move right
• SPACE - shoot weapon
• X - change weapon
• SHIFT - hold down to maintain direction when moving left and right

Fullscreen | Source Code