Navigation

New Loader Filetypes, Shader Effects and Animations

Published on 7th April 2017

image

Another week of significant work across all fronts, so let's dive in:

First of all Phaser CE has been going crazy the past few weeks. I gave repo contributor status to samme a few weeks back, and the results have been fantastic. He's been doing some stellar work. So many PRs merged, issues fixed and tests made. It's great to see all of this activity, and I'm sure we aren't far off a 2.7.6 release.

Phaser 3 Updates

This week I focused on the new Animation Manager, and also adding in some extra features to the Loader. Felipe worked on adding shader support. As usual the screen shots are all linked to examples, so click away!

New Loader Filetypes

After some experimentation I updated the Phaser 3 Loader to handle 2 new file formats: SVG files, and HTML files. SVGs can now be loaded as part of the preload process, and are converted into textures automatically on load, which can then be assigned to any texture based Game Object:

image

SVG files have obvious merits, their typically tiny size being one of them. Browser support is pretty good too, especially if you don't need to worry about older browsers too much.

The other file type I added was HTML. It loads a block of HTML, then renders that to a texture. As with SVGs this can be used on any texture based object. In the crude example below you can see a CSS gradient on a div, with some pre tags and a few fonts. It's a daft little example, but hopefully shows what is possible:

image

Browser support is much more limited on this, but if you can use it, and need it, it's a damn handy thing to have available. I can especially see a use for it in rendering instruction screens for example.

Phaser 3 Shader Effects

Felipe has been working on adding shader support into v3. Obviously shaders are used in the WebGL renderer, but this update exposes them to you via a new Game Object called an EffectLayer.

EffectLayers are a way of redirecting the WebGL rendering target of each Game Object to an offscreen framebuffer. You can later apply custom post processing shaders to that offscreen framebuffers color buffer, which in the case of an EffectLayer is a texture. You can even access the texture from the EffectLayer via the dstRenderTexture property.

Using an EffectLayer is very simple, being just a single call to the Game Object Factory, but for taking full advantage it may require understanding how shaders work. You can find a simple and useful explanation of how to use fragment shaders to manipulate the pixels on the EffectLayer rendering pass in this tutorial.

We will extend the features available in an EffectLayer to allow for easier use and setting of shader uniforms, but in the meantime this is an example of how to use an EffectLayer, adding an Image Game Object to it:

image

As you can (hopefully!) see in the code above the Effect Layer is simply a piece of fragment shader source with a position and a size. You can then add normal Game Objects to the Effects Layer, and the shader will be applied to them. The result looks like this:

image

Of course this is a very simple effect, just to demonstrate it running, but with a little more time spent in the shader code you can start creating things like this, and easily merge them into the display list of your game (as always, click the image to see the demo running)

image

Hopefully you can see how easy this will be to use :) There's more work to be done on it of course, but it's a great start - and you're free to play around with it right now to test it out. You can edit it live online, just by changing the labs URL to say 'edit.html' instead of 'view.html', or you can pull the code from the repos and build it.

New Animation Manager

While Felipe battled with shaders, I personally spent this week working on the new Phaser 3 Animation Manager. I'm extremely pleased with the progress made and the features added. It's already significantly more advanced than anything we had in v2, while being a lot less heavy on both the CPU and memory use. It's a big topic to cover though, and will take up a whole issue to explain, so look out for it in issue 76 next week. Until then, here are just a few of the features that are in and working already to whet your appetite, and some of the choices I made when building it.

Global Animations

Animations are stored globally. In v2 every single Sprite had its own animation manager, and would maintain its own collection of frames. This worked, but was pretty damn heavy. If you had an animated bullet for example, and 100 bullets, that would be 100 animation manager instances, each with its own set of frames and associated data. That needed to change.

So in v3 there is a single global Animation Manager, and all animations are created and stored within it. When you play an animation onto a Sprite all the Sprite really receives is a reference to the animation, and a bunch of playhead data. Going back to our 100 bullets example, under v3 there is only 1 instance of the animation, and instead each bullet just maintains a mini timeline of its own, tracking its play through the animation.

Animation Controls

Animations in v3 are built by providing a configuration object. This tells the manager which frames should be used, but it also allows you to set playback controls. For example you can now set either a framerate (in frames per second) for the animation, or you can specify a duration instead, and it'll calculated the required framerate for you. You can also now specify a delay before the animation will start, a repeat value to set it to repeat however many times you need (including forever), along with repeat delay, allowing it to pause before repeating again. There's even a yoyo setting, so it can play forwards and backwards again, before repeating (if set).

All of these settings are configured on the animation itself, so are picked up automatically by any Sprite that plays it. However, the Sprite can override them all too, changing them as it needs without impacting the data stored in the global animation - so if a specific sprite needs to have a different delay for example, it can do so:

image

There's a lot more I want to talk about, including features like transitions: so you can define a set of frames that are played when a sprite is playing one animation, and is then told to play another. Or the per-frame settings: for example you can make specific frames of the animation do things to the sprite, like change its visible property, or change its alpha, or anything you like via an update callback. But I'll cover this, and more, next issue.

Phaser 3 Mailing List and Developers Guide

If you're interested in helping evolve the shape of Phaser 3, then please join the Phaser 3 Google Group. Discussions this week have included varying render loops. The group is for anyone who wishes to help shape what the Phaser 3 API and feature-set will contain.

The Phaser 3 Developers Guide is available. Essential reading for anyone who'd like to help build Phaser 3.