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

Published in Phaser World Issue 59 on 9th December 2016 by Richard Davey   @photonstorm

Texture Manager, Math Classes and Graphics API Started


Phaser 3 development this week has been intense to say the least. I personally have added in 69 new math functions, covering everything from interpolation to value snapping. I also added in the brand new global Texture Manager, the Loader and the WebGL Renderer. It's really exciting to finally be able to run all of the early tests again, and see things rendered on-screen :)

For too long my work has consisted purely of monitoring output in the console, but thankfully no longer! I'd like to take a little moment to explain in more detail what I've been doing:

Phaser 3 is now built with webpack2. This has literally replaced the entire build chain from Phaser 2, which quite frankly is a great thing, because that had grown into a beast. In order to benefit from using webpack2 I had to take all the work I'd done so far, and break it up into CJS modules. In order to speed-up this process I actually back-ported a lot of the code from Lazer back into Phaser 3. Yes, you read that right - a huge amount of Lazer code was stripped of its ES6'ness and then merged with Phaser 3. As strange as that sounds it actually makes complete sense, and for me feels like everything is coming a full circle, and the ends are joining up properly.

I spent a lot of time creating the Lazer modules, so I'm glad to have them re-used within Phaser 3. I also spent a lot of time creating the brand new systems, such as the new Texture Manager, and State Manager, and it's nice to have these now all broken down into tidy little modules, imported cleanly via webpack. If you take a glance at the structure of the v3 source folder you'll see what I mean.

So what's next on the list? I need to finish off porting over the Cache, adding in the final few Loader functions, and then I can start putting the Game Objects back in. At the moment only Image exists.

The plan is that I really want to release a 'Beta 1' before the end of the year, although that is shockingly close already. This will not be feature complete, for example I may leave out all of the Input classes (except keyboard handling), physics and sound - because they all need recoding from scratch - but Beta 1 will still be perfectly usable to make games with. More importantly it will allow you to start playing around with it. Because it differs from how Phaser v2 works in a lot of important ways, so the sooner you get used to the new structure, and where to find things, the better. I'm also really keen to see how the new renderer works for you all.

Phaser 3 Graphics Update

While I've been getting all the plumbing sorted out, Felipe had the task of building the brand new Graphics API from scratch. We're literally not using anything at all from Phaser 2, and started over again, mostly to dramatically improve performance, but also because we feel the API could be cleaner as well. Over to Felipe ...

"For the shapes and line rendering I decided to go with a canvas-like API. This is because I feel the API expresses well the basic instructions to generate any type of shape, like lines, stars, rectangles, polygons, etc. This implementation layer will work mostly as an intermediate layer between a more object oriented approach for shapes like the ones mentioned before.

Most of the work has been done in WebGL, since the API is the same as canvas I don't have to worry about that. Right now to do a simple circles you just have to write it like you would with canvas. For example:


As you can see it's the same functions as canvas. The only difference is that at the end of the frame you must call "flush()". This is because all of the shapes and line information is encoded into the vertex buffers and then sent in a single drawcall. This is great since you don't have to pay any penalty on state changes like moving from drawing lines to polygon shape to arcs. It also limits the amount of indirection layers between the drawing routine and WebGL. If you look into the source of the implementation you'll mostly see WebGL calls.

Here is a small look of what can be done so far: