Phaser 2.4.8

The latest version of Phaser was released on May 19th and included 7 bug fixes, 7 updates and 3 new features. The new features include the ability to draw RenderTextures to BitmapData objects, which is handy if you're passing in the results of Sprite.generateTexture. Most of the Arcade Physics methods, such as distanceBetween and angleToPointer, now have a new world argument, allowing you to perform the calculation using world coordinates instead of local coordinates. Finally there is a new worldBound property, allowing you to define the elasticity of an Arcade Physics body when it collides specifically with the world bounds. If you leave it set to 'null' it will use the Body.bounce property as before, but if you set it to a new Point object you can now control the world bounce and body bounce separately.

Arcade Physics 2

Work continues on Arcade Physics 2 for Lazer. The development is being undertaken by Felipe Alfonso - who goes by @bitnenfer on the Phaser Slack channel. So say hi if you see him! You can track all of his commits to the repo, but new features this week include a custom polygon ear cutting routine, polygon to point intersection tests and lots of new examples in the lazer-dev repo.

Phaser Next

Now that Phaser 2.4.8 is released I will start work on Phaser 2.5.0. The first task being to test Pixi v4 integration, to get an idea of what level of effort is involved making it all work. There's a fine line between expending effort on this vs. working on Lazer, but I feel I owe it to the Pixi team to at least give it a shot :)

As 2.5.0 is likely to be a quite dramatic change internally I am very likely to also create a 2.4.9 release as well. This way issues won't remain ignored for too long, should 2.5.0 take a while to create (which is likely).

The challenge of fixing long-term broken things

In Phaser 2.4.8 the way that Sprite anchors and Body offsets work is now different than it was before. It's actually now correct in its implementation. But it had been incorrect for so long, that the incorrect version became the 'standard', and the new fixed one itself appears to be broken. When I say 'broken' I mean that the end result isn't what is expected - the functions have always actually worked, it's just the outcome that differs.

This is an interesting paradox you encounter when maintaining such a diverse API like Phasers. Devs get used to the 'broken' implementation, and it becomes normal to them. Which begs the question: should it actually be 'fixed' or not? In some such cases I have definitely turned around and said "this is a legacy issue and will remain as one", but the Body offset one felt like more of a proper bug to me, so I fixed it. I guess the old saying of "you can't please everyone" applies here.