Phaser World Issue 32

Published on 27th May 2016

Felipe has been hard at work on Arcade Physics 2 for Lazer. This week has seen stacks of development, including implementations of Arcade Physics simulation (velocity, acceleration, gravity, bounce, etc) and polygon collision solving. Remember this is using the new SAT functions we've created, rather than just the bounding box tests Phaser has.

Here are some gifs (hopefully you can see them animated in the newsletter!). The first showing masses of bodies being emitted, and the second the new collision system in operation:

This new Lazer’s Arcade Physics 2 system exposes a very similar API to Phaser’s Arcade. For example you’ll still be able to affect a body using properties like velocity, acceleration, bounce, drag, friction, mass, etc:

This means that ...

sprite.body.velocity.x = getSomeValue();

... will still be a valid way of setting body properties by hand.

A new thing that that you must have in mind is that when creating a Body you’ll have to also define a Collider type. This is because the collision system uses a SAT (Separating Axis Theorem) based solver. This means that it now handles convex polygon collisions. This is how you can define a new Body in Arcade 2:

var newBody = new Body(130, 20, new RectangleCollider(0, 0, 100, 100));

This will create a body with a position (x:130, y:20) and a rectangle collider of (x: 0, y: 0, width: 100, height: 100).

So what really changed?

Externally Arcade Physics 2 will look very similar to the current API, but internally it had a complete remake. Originally Phaser handles bodies and physics simulation iterating through each body. Something like this:

for (var a = this.children.length; a--; )

this.children[a].preUpdate();

Inside the preUpdate function we have something like this:

this.game.physics.arcade.updateMotion(this);

This is a very straightforward and easy to understand Object-Oriented approach. The problem with this is that it has many performance pitfalls. Just to mention some, multiple branches inside tight loops, hash map look ups through all the member access and polymorphism (which is terrible for JS compiler optimizer).

All the jumping from one function to another, accessing members randomly affect performance greatly, specially on modern CPU. The approach I took for the new physics system is inspired from Data Oriented Design. Basically what I wanted to do is take advantage of data locality and avoid as much as I could cache misses.

So how does the new system look internally? It's more like this:

let SystemPositionX = new Float32Array(MAX_CAPACITY);

let SystemPositionY = new Float32Array(MAX_CAPACITY);

let SystemVelocityX = new Float32Array(MAX_CAPACITY);

let SystemVelocityY = new Float32Array(MAX_CAPACITY);

export function RunSimulationFrame(physicsElapsed) {

for (let index = 0; index < BodyCount; ++index) {

SystemPositionX[index] += SystemVelocityX[index];

SystemPositionY[index] += SystemVelocityY[index];

Here we are taking advantage of Typed Arrays contiguous memory blocks. As we know they have that property this will make accessing the data much faster. There is also the fact that we are not doing any hash map look ups and also avoiding as much as possible branching.

Benchmark Test

Here is a small benchmark which explains a bit the problem and the solution. You are welcome to try it out. The performance of your browser will be recorded.

You can follow the progress of Lazer in the official GitHub repos, where you'll find all the tests above.