This week I did something I don't often do: I gave a talk about Phaser. It took place at BristolJS, which is a local JavaScript meet-up. The event organiser approached me towards the start of the year, and it took until October before things fell into place.

Public speaking doesn't come naturally to me. Even though I know the subject matter inside-out, it doesn't mean I can always articulate my thoughts about it in the best way possible. But I planned, prepared slides, and gave it my best shot. And although I don't plan on increasing the amount of talks I do, it was really good fun at the same time. My talk was recorded, and if a video becomes available I'll let you all know.

Back in the land of code this week has seen me mostly focusing on the new WebGL Batch Manager and WebGL Renderer. I've refined, and fine-tuned the Batch Manager code countless times this week. Redundant properties are gone, un-necessary bindings removed, and I've streamlined it as best I can. Blend Mode support, multiple texture support, and custom shader support have all been added back in too. Yet one of the most important things, is that this no longer happens:

If you get your magnifying glass on the screen shot above, you'll see that the WebGLSpriteBatch render method has been deopt'd by Chrome. Given that this method is the beating heart of the batch process, to be deopted is quite possibly the single worst thing that can happen to it. The screen grab is from Phaser 2.6.2 running a pretty simple example test. And it's something I've been working solidly to ensure doesn't happen in v3. My latest profiles show an exact same example under v3 uses 3MB less memory, with far smaller GC drops, significantly less webgl operations, and less draw calls. And every time I make a new change, I re-test to make sure none of this has altered.

As well as the Batch Manager I've also been working on several new Game Objects. One of these is a PixelField, which allows you to blast thousands of pixels around the screen at insane speeds. Each pixel is literally just a coordinate and a color value, stored in an internal list, rather than being an object in its own right. So you can zip through the list really quickly and shove the data into the batch. It uses a custom (and tiny) shader for drawing.

I've also started planning out an FX Pipeline. I really want for you to be able to attach special effects to Game Objects, and have them impact the way they are rendered. For example a ghost trail that lags behind the movement of a Sprite, or a color inversion, flash or greyscale, that doesn't require the renderer to swap to a new shader (which takes time, and can be expensive when done a lot). I still need to finalise the approach I want to take, but as always, keep an eye on the GitHub repo to see what's going on.

Thanks to good levels of Phaser shop sales, and ever increasing Patreon backers, I'm able to spend a large percentage of my time on Phaser 3 development right now, and it's really starting to show. I don't think I've ever been more excited about a version, ever :) It finally feels like I'm not having to make any compromises. And that's a powerful feeling to have.