Due to the rapid pace of change some links or details may no longer be correct.

Published in Phaser World Issue 49 on 2nd October 2016 by Richard Davey   @photonstorm

Consolidating Pixi


If you have the Phaser GitHub repo on your Watchlist, then you'll no doubt have seen a massive flurry of activity last week. The commit list alone should give you some clue as to what has been going on.

First of all, I spent several days doing nothing but tackling issues reports on GitHub. Believe me, this is a (mostly) thankless task. I know you all appreciate the effort I put in, but sadly that doesn't make the process any more enjoyable! The majority of issues raised for Phaser now are deep and complex ones, with very few 'easy wins' along the road. Having said that, I do enjoy seeing the issue count steadily fall. My aim is to keep the total number of issues below 50, and I'm very close to that now. A few more weeks hard work should see it cleared.

Consolidating Pixi

The other big change is that in the dev branch I've been steadily consolidating all of the Pixi source code. The objective is to get rid of the deep inheritance tree structure, and to give everything a really good tidy-up, replacing legacy systems where needed. A quick glance at the commit list will show that I've been really busy here, often coding into the small hours of the morning trying to get this done. I've been merging Pixi classes into Phaser, getting rid of lines of redundant code, tidying up duplicate properties, and getting our house in order.

There are going to be some very significant internal changes in Phaser 3. Yes, it's still ES5. Yes, it's still our heavily rebuilt Pixi engine at the core. But to all other intents and purposes, there are loads of changes and new features as a result. At the end of the week I finished off working on the new Texture system. It had long bothered me that Textures had such a long class tail, and that Animation was quite inflexible as a result. Due to the way I chose to structure Phaser on-top of Pixi, the simple act of getting a texture on a Sprite went through too many layers, and it was terrible at re-using them too.

After the days of work I put in, the new texture system is much better and simpler. Textures are shared and pooled. This means that 1000 Sprites using the same texture frame, will all now just use the exact same underlying TextureFrame object. Where-as in Phaser 2 there would exist one shared BaseTexture, but 1000 unique Textures, FrameData sets, Animation Managers and Frames! I worked hard to boil this all down, and it unlocked great new features as a result. For example Phaser 3 now supports multi-packed (or split) texture atlas files. It supports the ability to have Bitmap Fonts or Sprite Sheets as frames in an atlas. It supports animations being able to have frames within them from any texture, in any atlas, and it does it all using far less memory than before.

So keep your eye on the dev branch if you don't mind being inundated with emails, because there is a lot going on, it's all pretty exciting, and next week is going to be even more intense.