New Renderer and FBO Tests

Published on 4th November 2016

image

This week has been an insane one in terms of work on Phaser 3. A quick glance at the dev branch commit history will give you some idea of the level of work I've been putting in.

If you support Phaser on Patreon (thank you!) then you'll have seen the video I uploaded already. It's a 1 minute run through of some of the Phaser 3 renderer tests I've been working on.

What you're seeing in the video are some new features, including the Pixel Field Game Object. Think of this as a way to plot pixels to the canvas (or webgl context) extremely quickly, and with minimal memory overhead. You can control the size and color of each pixel, and internally it uses a special shader I built specifically for the task. We're talking 10's of thousands of pixels in a single frame, and a single draw call, allowing for some really sweet effects in your games.

I had the new batch renderer finished last week, and performance was awesome! But I also wanted the ability for you to be able to do really advanced stuff with your games, so I spent a number of days implementing a new Frame Buffer Object (fbo) system in, which is what the video is really showing.

In Phaser 3 each State has its own frame buffer, meaning that the State itself renders to a GPU bound texture, allowing you to then apply all kinds of effects on the top of it, or pass it over to another shader for further processing. Because Phaser 3 states can run in parallel it means you can do some really neat stuff, like applying a huge 'ripple' effect to just the background of your game, or rendering your Phaser game into a three.js texture.

I also continued to work on refining the number of calls taking place under a normal 'single state' environment. I managed to get it to the point where a full scene was completing in literally 1 draw and just 4 WebGL calls, by optimising away needless calls, and aggressively caching shaders, blend states and other things that all take-up needless little WebGL calls when not always needed.

Towards the end of the week I recoded the Phaser State Manager. This was a huge chunk of work, but progress has been great, and I'm really pleased with the direction it's moving in. I'll talk more about it next week, hopefully with another video, because what it allows you to do now is so exciting, and I've rambled on for long enough already this week :)

As always, thank you to the Phaser patrons who make all of this possible, by funding the time I can spend on development. I'm incredibly happy with how things are shaping up, and I'm even more happy by the fact that I finally am responsible for every single line of code in the core library - there are no more excuses about doing things 'because that's how X does it', it's literally crafted exactly the way I want it to be, and the results are speaking for themselves.

image

This week has been an insane one in terms of work on Phaser 3. A quick glance at the dev branch commit history will give you some idea of the level of work I've been putting in.

If you support Phaser on Patreon (thank you!) then you'll have seen the video I uploaded already. It's a 1 minute run through of some of the Phaser 3 renderer tests I've been working on.

What you're seeing in the video are some new features, including the Pixel Field Game Object. Think of this as a way to plot pixels to the canvas (or webgl context) extremely quickly, and with minimal memory overhead. You can control the size and color of each pixel, and internally it uses a special shader I built specifically for the task. We're talking 10's of thousands of pixels in a single frame, and a single draw call, allowing for some really sweet effects in your games.

I had the new batch renderer finished last week, and performance was awesome! But I also wanted the ability for you to be able to do really advanced stuff with your games, so I spent a number of days implementing a new Frame Buffer Object (fbo) system in, which is what the video is really showing.

In Phaser 3 each State has its own frame buffer, meaning that the State itself renders to a GPU bound texture, allowing you to then apply all kinds of effects on the top of it, or pass it over to another shader for further processing. Because Phaser 3 states can run in parallel it means you can do some really neat stuff, like applying a huge 'ripple' effect to just the background of your game, or rendering your Phaser game into a three.js texture.

I also continued to work on refining the number of calls taking place under a normal 'single state' environment. I managed to get it to the point where a full scene was completing in literally 1 draw and just 4 WebGL calls, by optimising away needless calls, and aggressively caching shaders, blend states and other things that all take-up needless little WebGL calls when not always needed.

Towards the end of the week I recoded the Phaser State Manager. This was a huge chunk of work, but progress has been great, and I'm really pleased with the direction it's moving in. I'll talk more about it next week, hopefully with another video, because what it allows you to do now is so exciting, and I've rambled on for long enough already this week :)

As always, thank you to the Phaser patrons who make all of this possible, by funding the time I can spend on development. I'm incredibly happy with how things are shaping up, and I'm even more happy by the fact that I finally am responsible for every single line of code in the core library - there are no more excuses about doing things 'because that's how X does it', it's literally crafted exactly the way I want it to be, and the results are speaking for themselves.