Release Candidate 1 of Phaser 2.5.1 is now available for download. As usual you can get the pre-built files from the `dev` branch of the Phaser GitHub repo:

https://github.com/photonstorm/phaser/tree/dev/build

You can also read about what's changed in this release in the Change Log.

2.5.1 is a point release that is specifically aimed at bug fixes and minor updates. This includes fixes such as making Input work again on Graphics objects. Also updates such as the TilemapParser pulling in extra image data, new arguments to help render Text quicker in async processes, and various docs and TypeScript fixes.

Please grab the build files and give it a test. If you're using 2.5.0 already it should be an easy swap, with zero breaking changes to your code. If you have a clone of the Phaser repo then pull down the dev branch, and you'll find updated docs and TypeScript defs too.

Lazer Development

Over the past couple of weeks we've been focusing on how to handle Transforms in Lazer. Transforms are vital to any game framework, as they handle all transformations of display objects, such as the objects position, rotation and scale.

When you have an object as a child of another, and you perform a transform on the parent such as scaling the parent, then it should influence the scale of the child as well. This is how all display lists work - the transforms flow down from the top to the bottom, branching out as they reach children on the way.

One of the biggest problems we have with Phaser is the way it uses Pixi's deferred transform system. In this set-up the transforms are only ever updated once, just before the display objects are rendered. This means that if you need to use a value, such as the scale of an object, in a calculation prior to the render loop, then the values are all 'stale', being based on the previous frame. It was important we addressed this in Lazer: if you poll an object for its rotation for example, you should get the exact perfect value back,taking all of its parents into consideration, no matter when you make that call.

As every object has a transform it's imperative that they calculate themselves extremely quickly, and that is what Felipe has been working on the past few weeks.

There are 5 Transform tests in the Lazer Labs. They are:

GPGPU

The main idea of this was to offload transformation computation to the GPU using frame buffers as a way to input and output data from it. This approach is very efficient for computing the transformations thanks to the data parallelism found in GPUs, but the main bottleneck was trying to read information and making available for users. This might be a good idea but for a different problem.

Intrusive Doubly Linked List

This approach was about implementing an intrusive linked list into the Transform class. This would allow for easy inserting and removing of items and also for easy traversing of a huge scene graph tree. This would allow as to have a nice looking API like this:

Matrix Decomposition

This implementation idea is about defining the Transform abstraction as a matrix or a simple 1D typed array. There wouldn’t be any position, scale or rotation variables but only a matrix from which we read values and apply transformations.

This approach would allow us to have a similar design like the previous one but with a small difference. Values wouldn’t be stored directly on the Transform class but would have to be used and disposed right away, especially if you are dealing with and element that is constantly having transformations applied to it:

Matrix Stack

This approach is a very known and old one. It’s used on canvas and it was also used on old OpenGL API. Basically you have a stack of matrices and you push and pop to save or restore the current matrix state.

This isn’t much for solving the original problem but more for rendering a scene graph. All computation is done on CPU but it’s an easy and clear to use interface.

Keep an eye on the Lazer GitHub repo to see all the code that has gone into these tests and more.