Release Phaser v3.60 Beta 23 · phaserjs/phaser

Version 3.60.0 - Miku - in development

New Features - Timeline Class

Phaser 3.60 has a new Timeline Class which allows for fine-grained control of sequenced events. Previously in 3.55 the Timeline was part of the Tween system and it never quite worked as intended. In 3.60 it has been removed from Tweens entirely, replaced with the much more solid and reliable Tween Chains and Timeline has now becomes its own first-class citizen within Phaser. It allows you to sequence any event you like, not just tweens.

A Timeline is a way to schedule events to happen at specific times in the future. You can think of it as an event sequencer for your game, allowing you to schedule the running of callbacks, events and other actions at specific times in the future.

A Timeline is a Scene level system, meaning you can have as many Timelines as you like, each belonging to a different Scene. You can also have multiple Timelines running at the same time.

If the Scene is paused, the Timeline will also pause. If the Scene is destroyed, the Timeline will be automatically destroyed. However, you can control the Timeline directly, pausing, resuming and stopping it at any time.

Create an instance of a Timeline via the Game Object Factory:

const timeline = this.add.timeline();

The Timeline always starts paused. You must call play on it to start it running.

You can also pass in a configuration object on creation, or an array of them:

const timeline = this.add.timeline({
    at: 1000,
    run: () => {
        this.add.sprite(400, 300, 'logo');
    }
});

timeline.play();

In this example we sequence a few different events:

const timeline = this.add.timeline([
    {
        at: 1000,
        run: () => { this.logo = this.add.sprite(400, 300, 'logo'); },
        sound: 'TitleMusic'
    },
    {
        at: 2500,
        tween: {
            targets: this.logo,
            y: 600,
            yoyo: true
        },
        sound: 'Explode'
    },
    {
        at: 8000,
        event: 'HURRY_PLAYER',
        target: this.background,
        set: {
            tint: 0xff0000
        }
    }
]);

timeline.play();

There are lots of options available to you via the configuration object. See the TimelineEventConfig typedef for more details.

New Features - ESM Support

Phaser 3.60 uses the new release of Webpack 5 in order to handle the builds. The configurations have been updated to follow the new format this upgrade introduced. As a bonus, Webpack 5 also bought a new experimental feature called 'output modules', which will take a CommonJS code-base, like Phaser uses and wrap the output in modern ES Module declarations.

We are now using this as part of our build. You will find in the dist folder a new phaser.esm.js file, which is also linked in from our package.json module property. Using this build you can access any of the Phaser modules directly via named imports, meaning you can code like this:

import { AUTO, Scene, Game } from './phaser.esm.js';

class Test extends Scene
{
    constructor ()
    {
        super();
    }

    create ()
    {
        this.add.text(10, 10, 'Welcome to Phaser ESM');
    }
}

const config = {
    type: AUTO,
    width: 800,
    height: 600,
    parent: 'phaser-example',
    scene: [ Test ]
};

const game = new Game(config);

Note that we're importing from the local esm bundle. By using this approach you don't need to even use a bundler for quick local prototyping or testing, you can simply import and code directly.

The dist folder still also contains phaser.js which, as before, uses a UMD export.

Because the Webpack feature is experimental we won't make the ESM version the default just yet, but if you're curious and want to explore, please go ahead!

New Features - Built-in Special FX

We have decided to bundle a selection of highly flexible special effect shaders in to Phaser 3.60 and provide access to them via an easy to use set of API calls. The FX included are:

Barrel - A nice pinch / bulge distortion effect.
Bloom - Add bloom to any Game Object, with custom offset, blur strength, steps and color.
Blur - 3 different levels of gaussian blur (low, medium and high) and custom distance and color.
Bokeh / TiltShift - A bokeh and tiltshift effect, with intensity, contrast and distance settings.
Circle - Add a circular ring around any Game Object, useful for masking / avatar frames, with custom color, width and background color.
ColorMatrix - Add a ColorMatrix to any Game Object with access to all of its methods, such as sepia, greyscale, lsd and lots more.
Displacement - Use a displacement texture, such as a noise texture, to drastically (or subtly!) alter the appearance of a Game Object.
Glow - Add a smooth inner or outer glow, with custom distance, strength and color.
Gradient - Draw a gradient between two colors across any Game Object, with optional 'chunky' mode for classic retro style games.
Pixelate - Make any Game Object appear pixelated, to a varying degree.
Shadow - Add a drop shadow behind a Game Object, with custom depth and color.
Shine - Run a 'shine' effect across a Game Object, either additively or as part of a reveal.
Vignette - Apply a vignette around a Game Object, with custom offset position, radius and color.
Wipe - Set a Game Object to 'wipe' or 'reveal' with custom line width, direction and axis of the effect.

What's more, the FX can be stacked up. You could add, for example, a Barrel followed by a Blur and then topped-off with a Circle effect. Just by adjusting the ordering you can achieve some incredible and unique effects, very quickly.

We've worked hard to make the API as easy to use as possible, too. No more messing with pipelines or importing plugins. You can simply do:

const player = this.add.sprite(x, y, texture);

player.preFX.addGlow(0xff0000, 32);

This will add a 32 pixel red glow around the player Sprite.

Each effect returns a new FX Controller instance, allowing you to easily adjust the special effects in real-time via your own code, tweens and similar:

const fx = container.postFX.addWipe();

this.tweens.add({
    targets: fx,
    progress: 1
});

This will add a Wipe Effect to a Container instance and then tween its progress value from 0 to 1, causing the wipe to play out.

All texture-based Game Objects have access to Pre FX (so that includes Images, Sprites, TileSprites, Text, RenderTexture and Video). However, all Game Objects have access to Post FX, as do cameras. The difference is just when the effect is applied. For a 'pre' effect, it is applied before the Game Object is drawn. For a 'post' effect, it's applied after it has been drawn. All of the same effects are available to both.

this.cameras.main.postFX.addTiltShift();

For example, this will apply a Tilt Shift effect to everything being rendered by the Camera. Which is a much faster way of doing it than applying the same effect to every child in a Scene. You can also apply them to Containers, allowing more fine-grained control over the display.

The full list of new methods are as follows:

Available only to texture-based Game Objects:

GameObject.preFX an instance of the FX Controller, which allows you to add and remove Pre FX from the Game Object. It features methods such as add, remove and clear. Plus the following:
GameObject.preFX.addGlow adds a Glow Pre FX effect to the Game Object.
GameObject.preFX.addShadow adds a Shadow Pre FX effect to the Game Object.
GameObject.preFX.addPixelate adds a Pixelate Pre FX effect to the Game Object.
GameObject.preFX.addVignette adds a Vignette Pre FX effect to the Game Object.
GameObject.preFX.addShine adds a Shine Pre FX effect to the Game Object.
GameObject.preFX.addBlur adds a Blur Pre FX effect to the Game Object.
GameObject.preFX.addGradient adds a Gradient Pre FX effect to the Game Object.
GameObject.preFX.addBloom adds a Bloom Pre FX effect to the Game Object.
GameObject.preFX.addColorMatrix adds a ColorMatrix Pre FX effect to the Game Object.
GameObject.preFX.addCircle adds a Circle Pre FX effect to the Game Object.
GameObject.preFX.addBarrel adds a Barrel Pre FX effect to the Game Object.
GameObject.preFX.addDisplacement adds a Displacement Pre FX effect to the Game Object.
GameObject.preFX.addWipe adds a Wipe Pre FX effect to the Game Object.
GameObject.preFX.addReveal adds a Reveal Pre FX effect to the Game Object.
GameObject.preFX.addBokeh adds a Bokeh Pre FX effect to the Game Object.
GameObject.preFX.addTiltShift adds a TiltShift Pre FX effect to the Game Object.

Available to all Game Objects:

GameObject.clearFX removes both Pre and Post FX from the Game Object.
GameObject.postFX an instance of the FX Controller, which allows you to add and remove Post FX from the Game Object. It features methods such as add, remove and clear. Plus the following:
GameObject.postFX.addGlow adds a Glow Post FX effect to the Game Object.
GameObject.postFX.addShadow adds a Shadow Post FX effect to the Game Object.
GameObject.postFX.addPixelate adds a Pixelate Post FX effect to the Game Object.
GameObject.postFX.addVignette adds a Vignette Post FX effect to the Game Object.
GameObject.postFX.addShine adds a Shine Post FX effect to the Game Object.
GameObject.postFX.addBlur adds a Blur Post FX effect to the Game Object.
GameObject.postFX.addGradient adds a Gradient Post FX effect to the Game Object.
GameObject.postFX.addBloom adds a Bloom Post FX effect to the Game Object.
GameObject.postFX.addColorMatrix adds a ColorMatrix Post FX effect to the Game Object.
GameObject.postFX.addCircle adds a Circle Post FX effect to the Game Object.
GameObject.postFX.addBarrel adds a Barrel Post FX effect to the Game Object.
GameObject.postFX.addDisplacement adds a Displacement Post FX effect to the Game Object.
GameObject.postFX.addWipe adds a Wipe Post FX effect to the Game Object.
GameObject.postFX.addReveal adds a Reveal Post FX effect to the Game Object.
GameObject.postFX.addBokeh adds a Bokeh Post FX effect to the Game Object.
GameObject.postFX.addTiltShift adds a TiltShift Post FX effect to the Game Object.

New Features - Spatial Sound

Thanks to a contribution from @alxwest the Web Audio Sound system now supports spatial sound. The Web Audio Sound Manager now has the ability to set the listener position and each sound can be positioned in 3D space:

this.music = this.sound.add('theme');

this.sound.setListenerPosition(400, 300);

this.music.play({
    loop: true,
    source: {
        x: 400,
        y: 300,
        refDistance: 50,
        follow: this.playerSprite
    }
});

This allows you to create a 3D sound environment in your game. The following new methods and properties have been added to the Web Audio Sound Manager and Web Audio Sound classes:

SpatialSoundConfig is a new configuration object that contains the properties required to create and set the values of a spatial sound:
SpatialSoundConfig.x sets the horizontal position of the audio in a right-hand Cartesian coordinate system.
SpatialSoundConfig.y sets the vertical position of the audio in a right-hand Cartesian coordinate system.
SpatialSoundConfig.z sets the longitudinal (back and forth) position of the audio in a right-hand Cartesian coordinate system.
SpatialSoundConfig.panningModel is an enumerated value determining which spatialization algorithm to use to position the audio in 3D space. Can be either equalpower or HRTF. The default value is equalpower.
SpatialSoundConfig.distanceModel sets which algorithm to use to reduce the volume of the audio source as it moves away from the listener. Possible values are "linear", "inverse" and "exponential". The default value is "inverse".
SpatialSoundConfig.orientationX sets the horizontal position of the audio source's vector in a right-hand Cartesian coordinate system.
SpatialSoundConfig.orientationY sets the vertical position of the audio source's vector in a right-hand Cartesian coordinate system.
SpatialSoundConfig.orientationZ sets the longitudinal (back and forth) position of the audio source's vector in a right-hand Cartesian coordinate system.
SpatialSoundConfig.refDistance is a double value representing the reference distance for reducing volume as the audio source moves further from the listener. For distances greater than this the volume will be reduced based on rolloffFactor and distanceModel.
SpatialSoundConfig.maxDistance is the maximum distance between the audio source and the listener, after which the volume is not reduced any further.
SpatialSoundConfig.rolloffFactor is a double value describing how quickly the volume is reduced as the source moves away from the listener. This value is used by all distance models.
SpatialSoundConfig.coneInnerAngle sets the angle, in degrees, of a cone inside of which there will be no volume reduction.
SpatialSoundConfig.coneOuterAngle sets the angle, in degrees, of a cone outside of which the volume will be reduced by a constant value, defined by the coneOuterGain property.
SpatialSoundConfig.coneOuterGain sets the amount of volume reduction outside the cone defined by the coneOuterAngle attribute. Its default value is 0, meaning that no sound can be heard. A value between 0 and 1.
SpatialSoundConfig.follow sets this Sound object to automatically track the x/y position of this object. Can be a Phaser Game Object, Vec2 or anything that exposes public x/y properties.
WebAudioSoundManager.setListenerPosition is a new method that allows you to set the position of the Spatial Audio listener.
BaseSoundManager.listenerPosition is a new Vector2 that stores the position of the Spatial Audio listener.
WebAudioSound.spatialNode is a new property that holds the PanNode that is used to position the sound in 3D space.
WebAudioSound.spatialSource is a new property that holds a Vector2 that stores the position of the sound in 3D space.
WebAudioSound.x is a new property that sets the x position of the sound in 3D space. This only works if the sound was created with a SpatialSoundConfig object.
WebAudioSound.y is a new property that sets the y position of the sound in 3D space. This only works if the sound was created with a SpatialSoundConfig object.

New Features - Spine 4 Support

Thanks to a contribution from @justintien we now have a Spine 4 Plugin available.

You can find it in the plugins/spine4.1 folder in the main repository. There are also a bunch of new npm scripts to help build this plugin:

npm run plugin.spine4.1.full.dist - To build new dist files for both canvas and WebGL.
npm run plugin.spine4.1.dist - To build new dist files.
npm run plugin.spine4.1.watch - To enter watch mode when doing dev work on the plugin.
npm run plugin.spine4.1.runtimes - To build new versions of the Spine 4 runtimes.

The core plugin API remains largely the same. You can find lots of updated examples in the Phaser 3 Examples repo in the 3.60/spine4.1 folder.

We will maintain both the Spine 3 and 4 plugins for the forseeable future.

Additional Spine 3 Bug Fixes

Using drawDebug on a Spine Game Object to view its skeleton would cause the next object in the display list to be skipped for rendering, if it wasn't a Spine Game Object too. This is because the Spine 3 skeleton debug draw ends the spine batch but the Scene Renderer wasn't rebound. Fix #6380 (thanks @spayton)
The Spine Plugin add and make functions didn't clear and rebind the WebGL pipeline. This could cause two different visual issues: The first is that a Phaser Game Object (such as a Sprite) could be seen to change its texture to display the Spine atlas texture instead for a single frame, and then on the next pass revert back to normal again. The second issue is that if the Spine skeleton wasn't added to the display list, but just created (via addToScene: false) then the Sprite would take on the texture frame entirely from that point on. Fix #6362 (thanks @frissonlabs)
Previously, it wasn't possible for multiple Spine Atlases to use PNGs with the exact same filename, even if they were in different folders. The SpineFile loader has now been updated so that the always-unique Spine key is pre-pended to the filename, for example if the key was bonus and the PNG in the atlas was coin.png then the final key (as stored in the Texture Manager) is now bonus:coin.png. The SpinePlugin.getAtlasCanvas and getAtlasWebGL methods have been updated to reflect this change. Fix #6022 (thanks @orjandh)
If a SpineContainer had a mask applied to it and the next immediate item on the display list was another Spine object (outside of the Container) then it would fail to rebind the WebGL pipeline, causing the mask to break. It will now rebind the renderer at the end of the SpineContainer batch, no matter what, if it has a mask. Fix #5627 (thanks @FloodGames)

New Features - Plane Game Object

Phaser v3.60 contains a new native Plane Game Object. The Plane Game Object is a helper class that takes the Mesh Game Object and extends it, allowing for fast and easy creation of Planes. A Plane is a one-sided grid of cells, where you specify the number of cells in each dimension. The Plane can have a texture that is either repeated (tiled) across each cell, or applied to the full Plane.

The Plane can then be manipulated in 3D space, with rotation across all 3 axis.

This allows you to create effects not possible with regular Sprites, such as perspective distortion. You can also adjust the vertices on a per-vertex basis. Plane data becomes part of the WebGL batch, just like standard Sprites, so doesn't introduce any additional shader overhead. Because the Plane just generates vertices into the WebGL batch, like any other Sprite, you can use all of the common Game Object components on a Plane too, such as a custom pipeline, mask, blend mode or texture.

You can use the uvScroll and uvScale methods to adjust the placement and scaling of the texture if this Plane is using a single texture, and not a frame from a texture atlas or sprite sheet.

The Plane Game Object also has the Animation component, allowing you to play animations across the Plane just as you would with a Sprite.

As of Phaser 3.60 this Game Object is WebGL only. Please see the new examples and documentation for how to use it.

New Features - Nine Slice Game Object

Phaser v3.60 contains a new native Nine Slice Game Object. A Nine Slice Game Object allows you to display a texture-based object that can be stretched both horizontally and vertically, but that retains fixed-sized corners. The dimensions of the corners are set via the parameters to the class. When you resize a Nine Slice Game Object only the middle sections of the texture stretch. This is extremely useful for UI and button-like elements, where you need them to expand to accommodate the content without distorting the texture.

The texture you provide for this Game Object should be based on the following layout structure:

    A                          B
  +---+----------------------+---+
C | 1 |          2           | 3 |
  +---+----------------------+---+
  |   |                      |   |
  | 4 |          5           | 6 |
  |   |                      |   |
  +---+----------------------+---+
D | 7 |          8           | 9 |
  +---+----------------------+---+

When changing this objects width and / or height:

areas 1, 3, 7 and 9 (the corners) will remain unscaled
areas 2 and 8 will be stretched horizontally only
areas 4 and 6 will be stretched vertically only
area 5 will be stretched both horizontally and vertically

You can also create a 3 slice Game Object:

This works in a similar way, except you can only stretch it horizontally. Therefore, it requires less configuration:

    A                          B
  +---+----------------------+---+
  |   |                      |   |
C | 1 |          2           | 3 |
  |   |                      |   |
  +---+----------------------+---+

When changing this objects width (you cannot change its height)

areas 1 and 3 will remain unscaled
area 2 will be stretched horizontally

The above configuration concept is adapted from the Pixi NineSlicePlane.

To specify a 3 slice object instead of a 9 slice you should only provide the leftWidth and rightWidth parameters. To create a 9 slice
you must supply all parameters.

The minimum width this Game Object can be is the total of leftWidth + rightWidth. The minimum height this Game Object
can be is the total of topHeight + bottomHeight. If you need to display this object at a smaller size, you can scale it.

In terms of performance, using a 3 slice Game Object is the equivalent of having 3 Sprites in a row. Using a 9 slice Game Object is the equivalent of having 9 Sprites in a row. The vertices of this object are all batched together and can co-exist with other Sprites and graphics on the display list, without incurring any additional overhead.

As of Phaser 3.60 this Game Object is WebGL only. Please see the new examples and documentation for how to use it.

New Features - Pre FX Pipeline

When defining the renderTargets in a WebGL Pipeline config, you can now set optional width and height properties, which will create a Render Target of that exact size, ignoring the scale value (if also given).
WebGLPipeline.isPreFX is a new boolean property that defines if the pipeline is a Sprite FX Pipeline, or not. The default is false.
GameObjects.Components.FX is a new component that provides access to FX specific properties and methods. The Image and Sprite Game Objects have this component by default.
fxPadding and its related method setFXPadding allow you to set extra padding to be added to the texture the Game Object renders with. This is especially useful for Pre FX shaders that modify the sprite beyond its bounds, such as glow or shadow effects.
The WebGLPipeline.setShader method has a new optional parameter buffer that allows you to set the vertex buffer to be bound before the shader is activated.
The WebGLPipeline.setVertexBuffer method has a new optional parameter buffer that allows you to set the vertex buffer to be bound if you don't want to bind the default one.
The WebGLRenderer.createTextureFromSource method has a new optional boolean parameter forceClamp that will for the clamp wrapping mode even if the texture is a power-of-two.
RenderTarget will now automatically set the wrapping mode to clamp.
WebGLPipeline.flipProjectionMatrix is a new method that allows you to flip the y and bottom projection matrix values via a parameter.
PipelineManager.renderTargets is a new property that holds an array of RenderTarget objects that all PreFX pipelines can share, to keep texture memory as low as possible.
PipelineManager.maxDimension is a new property that holds the largest possible target dimension.
PipelineManager.frameInc is a new property that holds the amount the RenderTargets will increase in size in each iteration. The default value is 32, meaning it will create targets of size 32, 64, 96, etc. You can control this via the pipeline config object.
PipelineManager.targetIndex is a new property that holds the internal target array offset index. Treat it as read-only.
The Pipeline Manager will now create a bunch of RenderTarget objects during its boot method. These are sized incrementally from 32px and up (use the frameInc value to alter this). These targets are shared by all Sprite FX Pipelines.
PipelineManager.getRenderTarget is a new method that will return the a RenderTarget that best fits the dimensions given. This is typically called by Pre FX Pipelines, rather than directly.
PipelineManager.getSwapRenderTarget is a new method that will return a 'swap' RenderTarget that matches the size of the main target. This is called by Pre FX pipelines and not typically called directly.
PipelineManager.getAltSwapRenderTarget is a new method that will return a 'alternative swap' RenderTarget that matches the size of the main target. This is called by Pre FX pipelines and not typically called directly.
The WebGLPipeline.setTime method has a new optional parameter shader, which allows you to control the shader on which the time value is set.
If you add #define SHADER_NAME to the start of your shader then it will be picked up as the WebGLShader name during the setShadersFromConfig process within WebGLPipeline.
Calling setPostPipeline on a Game Object will now pass the pipelineData configuration object (if provided) to the pipeline instance being created.
PipelineManager.getPostPipeline now has an optional 3rd parameter, a config object that is passed to the pipeline instance in its constructor, which can be used by the pipeline during its set-up.

New Features - Compressed Texture Support

Phaser 3.60 contains support for Compressed Textures. It can parse both KTX and PVR containers and within those has support for the following formats: ETC, ETC1, ATC, ASTC, BPTC, RGTC, PVRTC, S3TC and S3TCSRB. Compressed Textures differ from normal textures in that their structure is optimized for fast GPU data reads and lower memory consumption. Popular tools that can create compressed textures include PVRTexTool, ASTC Encoder and Texture Packer.

Compressed Textures are loaded using the new this.load.texture method, which takes a texture configuration object that maps the formats to the files. The browser will then download the first file in the object that it knows it can support. You can also provide Texture Atlas JSON data, or Multi Atlas JSON data, too, so you can use compressed texture atlases. Currently, Texture Packer is the best tool for creating these type of files.

TextureSoure.compressionAlgorithm is now populated with the compression format used by the texture.
Types.Textures.CompressedTextureData is the new compressed texture configuration object type.
TextureManager.addCompressedTexture is a new method that will add a compressed texture, and optionally atlas data into the Texture Manager and return a Texture object than any Sprite can use.
Textures.Parsers.KTXParser is a new parser for the KTX compression container format.
Textures.Parsers.PVRParser is a new parser for the PVR compression container format.
The WebGLRenderer.compression property now holds a more in-depth object containing supported compression formats.
The WebGLRenderer.createTextureFromSource method now accepts the CompressedTextureData data objects and creates WebGL textures from them.
WebGLRenderer.getCompressedTextures is a new method that will populate the WebGLRenderer.compression object and return its value. This is called automatically when the renderer boots.
WebGLRenderer.getCompressedTextureName is a new method that will return a compressed texture format GLenum based on the given format.

New Features - Updated Particle System

The Particle system has been mostly rewritten to give it a much needed overhaul. This makes the API cleaner, the Game Objects a lot more memory efficient and also introduces several great new features. In order to do this, we had to make some breaking changes. The largest being the way in which particles are now created.

Previously when you used the this.add.particles command it would create a ParticleEmitterManager instance. You would then use this to create an Emitter, which would actually emit the particles. While this worked and did allow a Manager to control multiple emitters we found that in discussion developers seldom used this feature and it was common for a Manager to own just one single Emitter.

In order to streamline memory and the display list we have removed the ParticleEmitterManager entirely. When you call this.add.particles you're now creating a ParticleEmitter instance, which is being added directly to the display list and can be manipulated just like any other Game Object, i.e. scaled, rotated, positioned, added to a Container, etc. It now extends the GameObject base class, meaning it's also an event emitter, which allowed us to create some handy new events for particles.

So, to create an emitter, you now give it an xy coordinate, a texture and an emitter configuration object (you can also set this later, but most commonly you'd do it on creation). I.e.:

const emitter = this.add.particles(100, 300, 'flares', {
    frame: 'red',
    angle: { min: -30, max: 30 },
    speed: 150
});

This will create a 'red flare' emitter at 100 x 300.

Prior to 3.60 it would have looked like:

const manager = this.add.particles('flares');

const emitter = manager.createEmitter({
    x: 100,
    y: 300,
    frame: 'red',
    angle: { min: -30, max: 30 },
    speed: 150
});

The change is quite subtle but makes a big difference internally.

The biggest real change is with the particle x/y coordinates. It's important to understand that if you define x/y coordinates within the emitter configuration, they will be relative to those given in the add.particles call:

const emitter = this.add.particles(100, 300, 'flares', {
    x: 100,
    y: 100,
    frame: 'red',
    angle: { min: -30, max: 30 },
    speed: 150
});

In the above example the particles will emit from 200 x 400 in world space, because the emitter is at 100 x 300 and the particles emit from an offset of 100 x 100.

By making this change it now means you're able to do things like tween the x/y coordinates of the emitter (something you couldn't do before), or add a single emitter to a Container.

Other new features include:

Animated Particles

The Particle class now has an instance of the Animation State component within it. This allows a particle to play an animation when it is emitted, simply by defining it in the emitter config.

For example, this will make each particle play the 'Prism' animation on emission:

const emitter = this.add.particles(400, 300, 'gems', {
    anim: 'prism'
    ...
});

You can also allow it to select a random animation by providing an array:

const emitter = this.add.particles(400, 300, 'gems', {
    anim: [ 'prism', 'square', 'ruby', 'square' ]
    ...
});

You've also the ability to cycle through the animations in order, so each new particle gets the next animation in the array:

const emitter = this.add.particles(400, 300, 'gems', {
    anim: { anims: [ 'prism', 'square', 'ruby', 'square' ], cycle: true }
    ...
});

Or even set a quantity. For example, this will emit 10 'prism' particles, then 10 'ruby' particles and then repeat:

const emitter = this.add.particles(400, 300, 'gems', {
    anim: { anims: [ 'prism', 'ruby' ], cycle: true, quantity: 10 }
    ...
});

The Animations must have already been created in the Global Animation Manager and must use the same texture as the one bound to the Particle Emitter. Aside from this, you can still control them in the same way as any other particle - scaling, tinting, rotation, alpha, lifespan, etc.

Fast Forward Particle Time

You can now 'fast forward' a Particle Emitter. This can be done via either the emitter config, using the new advance property, or by calling the new ParticleEmitter.fastForward method. If, for example, you have an emitter that takes a few seconds to 'warm up' and get all the particles into position, this allows you to 'fast forward' the emitter to a given point in time. The value is given in ms. All standard emitter events and callbacks are still handled, but no rendering takes place during the fast-forward until it has completed.
The ParticleEmitter.start method has a new optional parameter advance that allows you to fast-forward the given amount of ms before the emitter starts flowing.

Particle Interpolation

It's now possible to create a new Interpolation EmitterOp. You do this by providing an array of values to interpolate between, along with the function name:

const emitter = this.add.particles(0, 0, 'texture', {
    x: { values: [ 50, 500, 200, 800 ], interpolation: 'catmull' }
    ...
});

This will interpolate the x property of each particle through the data set given, using a catmull rom interpolation function. You can also use linear or bezier functions. Interpolation can be combined with an ease type, which controls the progression through the time value. The related EmitterOpInterpolationConfig types have also been added.

Particle Emitter Duration

The Particle Emitter config has a new optional parameter duration:

const emitter = this.add.particles(0, 0, 'texture', {
    speed: 24,
    lifespan: 1500,
    duration: 500
});

This parameter is used for 'flow' emitters only and controls how many milliseconds the emitter will run for before automatically turning itself off.

ParticleEmitter.duration is a new property that contains the duration that the Emitter will emit particles for in flow mode.
The ParticleEmitter.start method has a new optional parameter duration, which allows you to set the emitter duration when you call this method. If you do this, it will override any value set in the emitter configuration.
The ParticleEmitter.stop method has a new optional parameter kill. If set it will kill all alive particles immediately, rather than leaving them to die after their lifespan expires.

Stop After a set number of Particles

The Particle Emitter config has a new optional stopAfter property. This, combined with the frequency property allows you to control exactly how many particles are emitted before the emitter then stops:

const emitter = this.add.particles(0, 0, 'texture', {
    x: { start: 400, end: 0 },
    y: { start: 300, end: 0 },
    lifespan: 3000,
    frequency: 250,
    stopAfter: 6,
    quantity: 1
});

In the above code the emitter will launch 1 particle (set by the quantity property) every 250 ms (set by the frequency property) and move it to xy 0x0. Once it has fired 6 particles (the stopAfter property) the emitter will stop and emit the COMPLETE event.

The stopAfter counter is reset each time you call the start or flow methods.

Particle Hold

You can configure a Particle to be frozen or 'held in place' after it has finished its lifespan for a set number of ms via the new hold configuration option:

const emitter = this.add.particles(0, 0, 'texture', {
    lifespan: 2000,
    scale: { start: 0, end: 1 },
    hold: 1000
    ...
});

The above will scale a Particle in from 0 to 1 over the course of its lifespan (2 seconds). It will then hold it on-screen for another second (1000 ms) before the Emitter recycles it and removes it from display.

Particle Emitter Events

The Particle Emitter will now fire 5 new events. Listen for the events as follows:

const emitter = this.add.particles(0, 0, 'flares');

emitter.on('start', (emitter) => {
    //  emission started
});

emitter.on('explode', (emitter, particle) => {
    //  emitter 'explode' called
});

emitter.on('deathzone', (emitter, particle, deathzone) => {
    //  emitter 'death zone' called
});

emitter.on('stop', (emitter) => {
    //  emission has stopped
});

emitter.on('complete', (emitter) => {
    //  all particles fully dead
});

The Particles.Events.START event is fired whenever the Emitter begins emission of particles in flow mode. A reference to the ParticleEmitter is included as the only parameter.
The Particles.Events.EXPLODE event is fired whenever the Emitter explodes a bunch of particles via the explode method. A reference to the ParticleEmitter and a reference to the most recently fired Particle instance are the two parameters.
The Particles.Events.DEATH_ZONE event is fired whenever a Particle is killed by a Death Zone. A reference to the ParticleEmitter, the killed Particle and the DeathZone that caused it are the 3 parameters.
The Particles.Events.STOP event is fired whenever the Emitter finishes emission of particles in flow mode. This happens either when you call the stop method, or when an Emitter hits its duration or stopAfter limit. A reference to the ParticleEmitter is included as the only parameter.
The Particles.Events.COMPLETE event is fired when the final alive particle expires.

Multiple Emit Zones

In v3.60 a Particle Emitter can now have multiple emission zones. Previously, an Emitter could have only a single emission zone. The zones can be created either via the Emitter Config by passing an array of zone objects, or via the new ParticleEmitter.addEmitZone method:

const circle = new Phaser.Geom.Circle(0, 0, 160);

const emitter = this.add.particles(400, 300, 'metal');

emitter.addEmitZone({ type: 'edge', source: circle, quantity: 64 });

When an Emitter has more than one emission zone, the Particles will cycle through the zones in sequence. For example, an Emitter with 3 zones would emit its first particle from zone 1, the second from zone 2, the third from zone 3, the fourth from zone 1, etc.
You can control how many particles are emitted from a single zone via the new total property. EdgeZone.total and RandomZone.total are new properties that control the total number of particles the zone will emit, before passing control over to the next zone in the list, if any. The default is -1.
Because an Emitter now supports multiple Emit Zones, the method setEmitZone now performs a different task than before. It's now an alias for addEmitZone. This means if you call it multiple times, it will add multiple zones to the emitter, where-as before it would just replace the zone each time.
ParticleEmitter#removeEmitZone is a new method that allows you to remove an Emit Zone from an Emitter without needing to modify the internal zones array.
ParticleEmitter.getEmitZone is a new method that Particles call when they are 'fired' in order to set their starting position, if any.
The property ParticleEmitter.emitZone has been removed. It has been replaced with the new ParticleEmitter.emitZones array-based property.

Multiple Death Zones

In v3.60 a Particle Emitter can now have multiple death zones. Previously, an Emitter could have only a single death zone. The zones can be created either via the Emitter Config by passing an array of zone objects, or via the new ParticleEmitter.addDeathZone method:

const circle = new Phaser.Geom.Circle(0, 0, 160);

const emitter = this.add.particles(400, 300, 'metal');

emitter.addDeathZone({ type: 'onEnter', source: circle });

When an Emitter has more than one Death Zone, the Particles will check themselves against all of the Death Zones, to see if any of them kills them.
Because an Emitter now supports multiple Emit Zones, the method setEmitZone now performs a different task than before. It's now an alias for addEmitZone. This means if you call it multiple times, it will add multiple zones to the emitter, where-as before it would just replace the zone each time.
ParticleEmitter#removeDeathZone is a new method that allows you to remove a Death Zone from an Emitter without needing to modify the internal zones array.
ParticleEmitter.getDeathZone is a new method that Particles call when they are updated in order to check if they intersect with any of the Death Zones.
The property ParticleEmitter.deathZone has been removed. It has been replaced with the new ParticleEmitter.deathZones array-based property.

Particle Colors

You can now specify a new color property in the Emitter configuration. This takes the form of an array of hex color values that the particles will linearly interpolate between during theif lifetime. This allows you to now change the color of a particle from birth to death, which gives you far more control over your emitter visuals than ever before. You'd use it as follows:

const flame = this.add.particles(150, 550, 'flares',
{
    frame: 'white',
    color: [ 0xfacc22, 0xf89800, 0xf83600, 0x9f0404 ],
    colorEase: 'quad.out',
    lifespan: 2400,
    angle: { min: -100, max: -80 },
    scale: { start: 0.70, end: 0, ease: 'sine.out' },
    speed: 100,
    advance: 2000,
    blendMode: 'ADD'
});

Here you can see the array of 4 colors it will interpolate through.

The new colorEase configuration property allows you to define the ease used to calculate the route through the interpolation. This can be set to any valid ease string, such as sine.out or quad.in, etc. If left undefined it will use linear as default.
EmitterColorOp is a brand new Emitter Op class that specifically controls the handling of color values, it extends EmitterOp and uses the same methods but configured for faster color interpolation.
If you define color in your config it will override any Emitter tint values you may have set. In short, use color if you wish to adjust the color of the particles during their lifespan and use tint if you wish to modify either the entire emitter at once, or the color of the particles on birth only.
ParticleEmitter.particleColor is a new property that allows you to get and set the particle color op value.
ParticleEmitter.colorEase is a new property that allows you to get and set the ease function used by the color op.

Particle Sort Order

You now have much more control over the sorting order of particles in an Emitter. You can set the new ParticleEmitter.sortProperty and sortOrderAsc properties to set how (and if) particles should be sorted prior to rendering. For example, setting sortProperty to y would mean that the particles will be sorted based on their y value prior to rendering. The sort order controls the order in which the particles are rendered. For example:

const emitter = this.add.particles(100, 300, 'blocks', {
    frame: 'redmonster',
    lifespan: 5000,
    angle: { min: -30, max: 30 },
    speed: 150,
    frequency: 200
});

emitter.setSortProperty('y', true);

The new ParticleEmitter.setSortProperty method allows you to modify the sort property and order at run-time.
The new ParticleEmitter.setSortCallback method allows you to set a callback that will be invoked in order to sort the particles, rather than using the built-in one. This gives you complete freedom over the logic applied to particle render sorting.

Particle Bounds, Renderer Culling and Overlap

Particles now have the ability to calculate their bounding box, based on their position, scale, rotation, texture frame and the transform of their parent. You can call the new Particle.getBounds method to return the bounds, which also gets stored in the new Particle.bounds Rectangle property.
ParticleEmitter.getBounds is a new method that will return the bounds of the Emitter based on all currently active particles. Optional parameters allow you to pad out the bounds and/or advance time in the particle flow, to allow for a more accurate overall bounds generation.
ParticleEmitter.viewBounds is a new property that is a Geom Rectangle. Set this Rectangle to define the overall area the emitter will render to. If this area doesn't intersect with the Camera then the emitter will be culled from rendering. This allows you to populate large Scenes with active emitters that don't consume rendering resources even though they are offscreen. Use the new getBounds method to help define the viewBounds area.
ParticleEmitter.overlap is a new method that will run a rectangle intersection test against the given target and all alive particles, returning those that overlap in an array. The target can be a Rectangle Geometry object or an Arcade Physics Body.
Particle.kill is a new method that will set the life of the particle to zero, forcing it to be immediately killed on the next Particle Emitter update.
ParticleEmitter.getWorldTransformMatrix is a new method that allows a Particle Emitter to calculate its world transform, factoring in any parents.
ParticleEmitter.worldMatrix is a new property that holds a TransformMatrix used for bounds calculations.

Particle Emitter Bounds

Prior to v3.60 a Particle Emitter had a bounds property. This was a Rectangle and if a Particle hit any of its edges it would rebound off it based on the Particles bounce value. In v3.60 this action has been moved to a Particle Processor. You can still configure the bounds via the Emitter config using the bounds property, as before. And you can configure which faces collide via the collideLeft etc properties. However, the following internal changes have taken place:
ParticleBounds is a new Particle Processor class that handles updating the particles.
The ParticleEmitter.setBounds method has been replaced with ParticleEmitter.addParticleBounds which now returns a new ParticleBounds Particle Processor instance.
The ParticleEmitter.bounds property has been removed. Please see the addParticleBounds method if you wish to retain this object.
The ParticleEmitter.collideLeft property has been removed. It's now part of the ParticleBounds Particle Processor.
The ParticleEmitter.collideRight property has been removed. It's now part of the ParticleBounds Particle Processor.
The ParticleEmitter.collideTop property has been removed. It's now part of the ParticleBounds Particle Processor.
The ParticleEmitter.collideBottom property has been removed. It's now part of the ParticleBounds Particle Processor.
The Particle.checkBounds method has been removed as it's now handled by the Particle Processors.

Particle Processors

ParticleProcessor is a new base class that you can use to create your own Particle Processors, which are special processors capable of manipulating the path of Particles based on your own logic or math. It provides the structure required to handle the processing of particles and should be used as a base for your own classes.
GravityWell now extends the new ParticleProcessor class.
ParticleEmitter.addParticleProcessor is a new method that allows you to add a Particle Processor instance to the Emitter. The old createGravityWell method now uses this.
ParticleEmitter.removeParticleProcessor is a new method that will remove a Particle Processor from an Emitter.
ParticleEmitter.processors is a new List property that contains all of the Particle Processors belonging to the Emitter.
The ParticleEmitter.wells property has been removed. You should now use the new processors property instead, they are functionally identical.
ParticleProcessor.update is the method that handles all of the particle manipulation. It now has a new 4th parameter t that is the normalized lifespan of the Particle being processed.

Particle System EmitterOp Breaking Changes and Updates:

All of the following properties have been replaced on the ParticleEmitter class. Previously they were EmitterOp instances. They are now public getter / setters, so calling, for example, emitter.particleX will now return a numeric value - whereas before it would return the EmitterOp instance. This gives developers a lot more freedom when using Particle Emitters. Before v3.60 it was impossible to do this, for example:

this.tweens.add({
    targets: emitter,
    particleX: 400
});

I.e. you couldn't tween an emitters particle spawn position by directly accessing its x and y properties. However, now that all EmitterOps are getters, you're free to do this, allowing you to be much more creative and giving a nice quality-of-life improvement.

If, however, your code used to access EmitterOps, you'll need to change it as follows:

//  Phaser 3.55
emitter.x.onChange(value)
//  Phaser 3.60
emitter.particleX = value

//  Phaser 3.55
let x = emitter.x.propertyValue
//  Phaser 3.60
let x = emitter.particleX

//  Phaser 3.55
emitter.x.onEmit()
emitter.x.onUpdate()
//  Phaser 3.60
emitter.ops.x.onEmit()
emitter.ops.x.onUpdate()

All of following EmitterOp functions can now be found in the new ParticleEmitter.ops property and have been replaced with getters:

accelerationX
accelerationY
alpha
angle
bounce
color
delay
lifespan
maxVelocityX
maxVelocityY
moveToX
moveToY
quantity
rotate
scaleX
scaleY
speedX
speedY
tint
x
y

Which means you can now directly access, modify and tween any of the above emitter properties at run-time while the emitter is active.

Another potentially breaking change is the removal of two internal private counters. These should never have been used directly anyway, but they are:

ParticleEmitter._counter - Now available via ParticleEmitter.flowCounter
ParticleEmitter._frameCounter - Now available via ParticleEmitter.frameCounter
EmitterOp._onEmit is a new private reference to the emit callback function, if specified in the emitter configuration. It is called by the new EmitterOp.proxyEmit method, to ensure that the Emitter current property remains current.
EmitterOp._onUpdate is a new private reference to the update callback function, if specified in the emitter configuration. It is called by the new EmitterOp.proxyUpdate method, to ensure that the Emitter current property remains current.
EmitterOp.destroy is a new method that nulls all references. This is called automatically when a ParticleEmitter is itself destroyed.

Further Particle System Updates and Fixes:

The Particle DeathZone.willKill method now takes a Particle instance as its only parameter, instead of x and y coordinates, allowing you to perform more complex checks before deciding if the Particle should be killed, or not.
The Particle.resetPosition method has been renamed to setPosition and it now takes optional x/y parameters. If not given, it performs the same task as resetPosition did in earlier versions.
The ParticleEmitter class now has the AlphaSingle Component. This allows you to call setAlpha on the Emitter instance itself and have it impact all particles being rendered by it, allowing you to now 'fade in/out' a whole Emitter.
Setting frequency wasn't working correctly in earlier versions. It should allow you to specify a time, in ms, between which each 'quantity' of particles is emitted. However, the preUpdate loop was calculating the value incorrectly. It will now count down the right amount of time before emiting another batch of particles.
Calling ParticleEmitter.start wouldn't reset the _frameCounter value internally, meaning the new emission didn't restart from the first texture frame again.
ParticleEmitter.counters is a new Float32Array property that is used to hold all of the various internal counters required for emitter operation. Both the previous _counter and _frameCounter properties have been merged into this array, along with new ones required for new features.
The WebGL Renderer will now use the new setQuad feature of the Transform Matrix. This vastly reduces the amount of math and function calls per particle, from 8 down to 1, increasing performance.
Particles with a scaleX or scaleY value of zero will no longer be rendered.
ParticleEmitter.preDestroy is a new method that will now clean-up all resources and internal arrays and destroy all Particles that the Emitter owns and clean-up all external references.
Particle.destroy is a new method that will clean up all external references and destroy the Animation State controller.
The ParticleEmitter._frameLength property is now specified on the class, rather than added dynamically at run-time, helping preserve class shape.
The ParticleEmitter.defaultFrame property has been removed as it's not required.
Calling ParticleEmitter.setFrame no longer resets the internal _frameCounter value to zero. Instead, the counter comparison has been hardened to >= instead of === to allow this value to change mid-emission and never reach the total.
The ParticleEmitter.configFastMap property has been moved to a local var within the ParticleEmitter JS file. It didn't need to be a property on the class itself, reducing the overall size of the class and saving memory.
The ParticleEmitter.configOpMap property has been moved to a local var within the ParticleEmitter JS file. It didn't need to be a property on the class itself, reducing the overall size of the class and saving memory.
Particle.scene is a new property that references the Scene the Particle Emitter belongs to.
Particle.anims is a new property that is an instance of the AnimationState component.
Particle.emit is a new proxy method that passes all Animation related events through to the Particle Emitter Manager to emit, as Particles cannot emit events directly.
Particle.isCropped is a new read-only property. Do not modify.
Particle.setSizeToFrame is a new internal NOOP method. Do not call.
ParticleEmitter.anims is a new property that contains the Animation keys that can be assigned to Particles.
ParticleEmitter.currentAnim is a new property that contains the index of the current animation, as tracked in cycle playback.
ParticleEmitter.randomAnim is a new boolean property that controls if the animations are selected randomly, or in a cycle.
ParticleEmitter.animQuantity is a new property that controls the number of consecutive particles that are emitted with the current animation.
ParticleEmitter.counters is a new internal Float32Array that holds all the counters the Emitter uses.
ParticleEmitter.getAnim is a new method, called by Particles when they are emitted, that will return the animation to use, if any.
ParticleEmitter.setAnim is a new method, called with the Emitter Manager, that sets the animation data into the Emitter.
The Particles.EmitterOp.toJSON method will now JSON stringify the property value before returning it.
Particles.EmitterOp.method is a new property that holds the current operation method being used. This is a read-only numeric value.
Particles.EmitterOp.active is a new boolean property that defines if the operator is alive, or not. This is now used by the Emitter instead of nulling Emitter properties, helping maintain class shape.
Particles.EmitterOp.getMethod is a new internal method that returns the operation function being used as a numeric value. This is then cached in the method property.
The Particles.EmitterOp.setMethods method has been updated so it now has a non-optional 'method' parameter. It has also been rewritten to be much more efficient, now being just a single simple select/case block.
The Particles.EmitterOp.onChange method will now use the cached 'method' property to avoid running through the setMethods function if not required, allowing each Particle EmitterOp to skip a huge chunk of code.
We've also greatly improved the documentation around the Particle classes.
ParticleEmitter.setConfig is a new method that allows you to set the configuration of the Emitter. Previously this was known as fromJSON.
The ParticleEmitter.setPosition method no longer changes the position of the particle emission point, but of the Emitter itself.
The ParticleEmitter.setBounds method has been renamed to setParticleBounds.
The ParticleEmitter.setSpeed method has been renamed to setParticleSpeed.
The ParticleEmitter.setScale method has been renamed to setParticleScale as setScale will now set the scale of the whole Emitter.
The ParticleEmitter.setScaleX and setScaleY methods have been removed. Please use setParticleScale.
The ParticleEmitter.setGravity method has been renamed to setParticleGravity.
The ParticleEmitter.setGravityX and setGravityY methods have been removed. Please use setParticleGravity.
The ParticleEmitter.setAlpha method has been renamed to setParticleAlpha as setAlpha will now set the alpha of the whole Emitter.
The ParticleEmitter.setTint method has been renamed to setParticleTint.
The ParticleEmitter.setLifespan method has been renamed to setParticleLifespan.
The ParticleEmitter.on property has been renamed to emitting to avoid conflicts with the Event Emitter.
The ParticleEmitter.x property has been renamed to particleX and is a new EmitterOp capable of being tweened.
The ParticleEmitter.y property has been renamed to particleY and is a new EmitterOp capable of being tweened.
The ParticleEmitter.scaleX property has been renamed to particleScaleX and is a new EmitterOp capable of being tweened.
The ParticleEmitter.scaleY property has been renamed to particleScaleY and is a new EmitterOp capable of being tweened.
The ParticleEmitter.tint property has been renamed to particleTint and is a new EmitterOp capable of being tweened.
The ParticleEmitter.alpha property has been renamed to particleAlpha and is a new EmitterOp capable of being tweened.
The ParticleEmitter.angle property has been renamed to particleAngle and is a new EmitterOp capable of being tweened.
The ParticleEmitter.rotate property has been renamed to particleRotate and is a new EmitterOp capable of being tweened.

New Features - Vastly Improved Mobile Performance and WebGL Pipeline Changes

TODO

WebGL Renderer Updates

Due to all of the changes with how WebGL texture batching works a lot of mostly internal methods and properties have been removed. This is the complete list:

The WebGLRenderer.currentActiveTexture property has been removed.
The WebGLRenderer.startActiveTexture property has been removed.
The WebGLRenderer.tempTextures property has been removed.
The WebGLRenderer.textureZero property has been removed.
The WebGLRenderer.normalTexture property has been removed.
The WebGLRenderer.textueFlush property has been removed.
The WebGLRenderer.isTextureClean property has been removed.
The WebGLRenderer.setBlankTexture method has been removed.
The WebGLRenderer.setTextureSource method has been removed.
The WebGLRenderer.isNewNormalMap method has been removed.
The WebGLRenderer.setTextureZero method has been removed.
The WebGLRenderer.clearTextureZero method has been removed.
The WebGLRenderer.setNormalMap method has been removed.
The WebGLRenderer.clearNormalMap method has been removed.
The WebGLRenderer.unbindTextures method has been removed.
The WebGLRenderer.resetTextures method has been removed.
The WebGLRenderer.setTexture2D method has been removed.
The WebGLRenderer.pushFramebuffer method has had the resetTextures argument removed.
The WebGLRenderer.setFramebuffer method has had the resetTextures argument removed.
The WebGLRenderer.popFramebuffer method has had the resetTextures argument removed.
The WebGLRenderer.deleteTexture method has had the reset argument removed.
The Textures.TextureSource.glIndex property has been removed.
The Textures.TextureSource.glIndexCounter property has been removed.

Previously, WebGLRenderer.whiteTexture and WebGLRenderer.blankTexture had a data-type of WebGLTexture but they were actually Phaser.Textures.Frame instances. This has now been corrected and the two properties are now actually WebGLTexture instances, not Frames. If your code relies on this mistake being present, please adapt it.

The RenderTarget class will now create a Framebuffer that includes a Depth Stencil Buffer attachment by default. Previously, it didn't. By attaching a stencil buffer it allows things like Geometry Masks to work in combination with Post FX and other Pipelines. Fix #5802 (thanks @mijinc0)
When calling PipelineManager.clear and rebind it will now check if the vao extension is available, and if so, it'll bind a null vertex array. This helps clean-up from 3rd party libs that don't do this directly, such as ThreeJS.
The mipmapFilter property in the Game Config now defaults to '' (an empty string) instead of 'LINEAR'. The WebGLRenderer has been updated so that it will no longer create mipmaps at all with a default config. This potential saves a lot of VRAM (if your game has a lot of power-of-two textures) where before it was creating mipmaps that may never have been used. However, you may notice scaling doesn't look as crisp as it did before if you were using this feature without knowing it. To get it back, just add mipmapFilter: 'LINEAR' to your game config. Remember, as this is WebGL1 it only works with power-of-two sized textures.

Mobile Pipeline

The Mobile Pipeline is a new pipeline that extends the Multi Tint pipeline, but uses customized shaders and a single-bound texture specifically for mobile GPUs. This should restore mobile performance back to the levels it was around v3.22, before Multi Tint improved it all for desktop at the expense of mobile.
shaders/Mobile.vert and shaders/Mobile.frag are the two shaders used for the Mobile Pipeline.
PipelineManager#MOBILE_PIPELINE is a new constant-style reference to the Mobile Pipeline instance.
autoMobilePipeline is a new Game Configuration boolean that toggles if the Mobile Pipeline should be automatically deployed, or not. By default it is enabled, but you can set it to false to force use of the Multi Tint pipeline (or if you need more advanced conditions to check when to enable it)
defaultPipeline is a new Game Configuration property that allows you to set the default Game Object Pipeline. This is set to Multi Tint as standard, but you can set it to your own pipeline from this value.
PipelineManager.default is a new propery that is used by most Game Objects to determine which pipeline they will init with.
PipelineManager.setDefaultPipeline is a new method that allows you to change the default Game Object pipeline. You could use this to allow for more fine-grained conditional control over when to use Multi or Mobile (or another pipeline)
The PipelineManager.boot method is now passed the default pipeline and auto mobile setting from the Game Config.

Multi Tint Pipeline

The batchLine method in the Multi Pipeline will now check to see if the dxdy len is zero, and if so, it will abort drawing the line. This fixes issues on older Android devices, such as the Samsung Galaxy S6 or Kindle 7, where it would draw erroneous lines leading up to the top-left of the canvas under WebGL when rendering a stroked rounded rectangle. Fix #5429 (thanks @fkoch-tgm @sreadixl)
The Multi.frag shader now uses a highp precision, or mediump if the device doesn't support it (thanks @arbassic)
The WebGL.Utils.checkShaderMax function will no longer use a massive if/else glsl shader check and will instead rely on the value given in gl.getParameter(gl.MAX_TEXTURE_IMAGE_UNITS).
The internal WebGL Utils function GenerateSrc has been removed as it's no longer required internally.
Previously, the Multi Tint methods batchSprite, batchTexture, batchTextureFrame and batchFillRect would all make heavy use of the TransformMatrix.getXRound and getYRound methods, which in turn called getX and getY and applied optional rounding to them. This is all now handled by one single function (setQuad) with no branching, meaning rendering one single sprite has cut down 16 function calls and 48 getters to just 1 function.

Lights Pipeline

The Light fragment shader will now use the outTintEffect attribute meaning the Light Pipeline will now correctly light both tinted and fill-tinted Game Objects. Fix #5452 (thanks @kainage)
The Light Pipeline will now check to see if a Light2D enabled Game Object has a parent Container, or not, and factor the rotation and scale of this into the light calculation. Fix #6086 (thanks @irongaze)
The Light Pipeline no longer creates up to maxLights copies of the Light shader on boot. Previously it would then pick which shader to use, based on the number of visible lights in the Scene. Now, the number of lights is passed to the shader and branches accordingly. This means rather than compiling n shaders on boot, it now only ever needs to create one.
You can now have no lights in a Scene, but the Scene will still be impacted by the ambient light. Previously, you always needed at least 1 light to trigger ambient light (thanks jstnldrs)
The Light.frag shader now uses a new uLightCount uniform to know when to stop iterating through the max lights.
The LightPipeline.LIGHT_COUNT constant has been removed as it's not used internally.
The LightPipeline previous created a global level temporary vec2 for calculations. This is now part of the class as the new tempVec2 property.

Removed - Graphics Pipeline

The WebGL Graphics Pipeline has been removed. This pipeline wasn't used in v3.55, as all Graphics rendering is handled by the MultiTint pipeline, for better batching support. No Phaser Game Objects use the Graphics pipeline any longer, so to save space it has been removed and is no longer installed by the Pipeline Manager.

New Features - Matter Physics v0.19

We have updated the version of Matter Physics to the latest v0.19 release. This is a big jump and brings with it quite a few internal changes to Matter. The following are the differences we have identified in this release:

Improves general consistency of results between different timesteps based on 60hz as a baseline
Changes Body.setAngularVelocity and Body.setVelocity functions to be timestep independent
Adds timestep independent Body.setSpeed, Body.setAngularSpeed, Body.getSpeed, Body.getVelocity and Body.getAngularVelocity
Adds optional updateVelocity argument to Body.setPosition, Body.setAngle, Body.translate and Body.rotate
Removes correction parameter from Engine.update as it is now built-in
Changed Body.setAngularVelocity and Body.setVelocity to be timestep independent
Improved similarity of results between different timesteps based on 60hz as a baseline
Added timestep independent Body.setSpeed, Body.setAngularSpeed, Body.getSpeed, Body.getVelocity, Body.getAngularVelocity
Added optional updateVelocity argument to Body.setPosition, Body.setAngle, Body.translate, Body.rotate
Added extended documentation for Body.applyForce
Moved time correction feature from Engine.update to be built-in to Matter.Body
Added readonly body.deltaTime property
Added speed setters to Body.set
Added updateVelocity argument to Body.setPosition, Body.setAngle, Body.translate and Body.rotate
Changed engine collisionStart event to trigger after resolving and after updating body velocities
Derive velocity from position in setters
Fixed issues with engine event.delta
Handle null constraint points in Constraint.pointAWorld and Constraint.pointBWorld
Improved Body.applyForce docs
Improved delta factors in resolver and constraint stiffness
Improved Matter.Body docs for functions and properties including readonly
Improved Matter.Engine docs
Improved delta consistency
Removed render element warning
Removed unused delta params
Updated body velocity properties after resolving
Updated timing improvements
Used Body.getVelocity in Matter.Render
Used speed getter in Matter.Sleeping and Matter.Render

Notes

When using a fixed timestep of 60hz (~16.666ms engine delta) results should look similar to before, as this was taken as the baseline.

If you're using a non-fixed timestep or one other than 60hz (~16.666ms) results should now become more similar to the 60hz baseline, therefore you may need to adjust e.g. body and constraint properties.

Since Body.setAngularVelocity and Body.setVelocity are now timestep independent, you may need to adjust code you may have been using that factored in the timestep.

For timestep independence, the Matter.Body speed and velocity getter and setter functions now relate to a fixed time unit rather than timestep, currently set as 1000/60 for easier backwards compatibility at the baseline 60hz.

Note that Body.applyForce naturally still remains timestep dependent as before, see the updated Body.applyForce docs for details.

While the properties body.velocity and body.speed (and angular versions) still exist they are not typically recommended for user code, in most cases you should switch to the new Body.getVelocity and Body.getSpeed functions as they are timestep independent.

The following changes came from the v0.18 release, which are also part of v0.19:

Up to ~40% performance improvement (on average measured over all examples, in Node on a Mac Air M1)
Replaces Matter.Grid with a faster and more efficient broadphase in Matter.Detector.
Reduced memory usage and garbage collection.
Resolves issues in Matter.SAT related to collision reuse.
Removes performance issues from Matter.Grid.
Improved collision accuracy.
MatterPhysics.collision is a new reference to the Collision module, which now handles all Matter collision events.
MatterPhysics.grid has been removed as this is now handled by the Collision module.
MatterPhysics.sat has been removed as this is now handled by the Collision module.
The Matter.Body.previousPositionImpulse property has been removed as it's no longer used.

Because of the changes above, the following new methods are available to any Phaser Matter Physics Game Object:

getVelocity - Returns the current linear velocity of the Body as a Vec2.
getAngularVelocity - Returns the current rotation velocity of the Body.
setAngularSpeed - Sets the current rotational speed of the body. Direction is maintained. Affects body angular velocity.
getAngularSpeed - Returns the current rotational speed of the body. Equivalent to the magnitude of its angular velocity.

New Features - New Tween Manager

TODO - TweenData to class
TODO - TweenData and Tween State methods
TODO - CONST removals

The Phaser 3.60 Tween system has been rewritten to help with performance, resolve some of its lingering issues and unifies the Tween events and callbacks.

The following are breaking changes:

Tween Timelines have been removed entirely. Due to the way they were implemented they tended to cause a range of esoteric timing bugs which were non-trivial to resolve. To that end, we made the decision to remove Timelines entirely and introduced the ability to chain tweens together using the new chain method. This should give most developers the same level of sequencing they had using Timelines, without the timing issues.
The Tween.seek method used to take a value between 0 and 1, based on how far through the Tween you wished to seek. However, it did not work with infinitely looping or repeating Tweens and would crash the browser tab. The new seek method takes a value in milliseconds instead and works perfectly on infinite Tweens.
When creating a Tween, you can no longer pass a function for the following properties: duration, hold, repeat and repeatDelay. These should be numbers only. You can, however, still provide a function for delay, to keep it compatible with the StaggerBuilder.
The TweenManager#getAllTweens method has been renamed to TweenManager#getTweens. Functionally, it is the same.
The property and feature Tween.useFrames has been removed and is no longer a valid Tween Config option. Tweens are now entirely millisecond based.
The TweenOnUpdateCallback now has the following parameters: tween, targets, key (the property being tweened), current (the current value of the property), previous (the previous value of the property) and finally any of the params that were passed in the onUpdateParams array when the Tween was created.
The TweenOnYoyoCallback now has the following parameters: tween, targets, key (the property being tweened), current (the current value of the property), previous (the previous value of the property) and finally any of the params that were passed in the onYoyoParams array when the Tween was created.
The TweenOnRepeatCallback now has the following parameters: tween, targets, key (the property being tweened), current (the current value of the property), previous (the previous value of the property) and finally any of the params that were passed in the onRepeatParams array when the Tween was created.
Tween.stop has had the resetTo parameter removed from it. Calling stop on a Tween will now prepare the tween for immediate destruction. If you only wish to pause the tween, see Tween.pause instead.
Tweens will now be automatically destroyed by the Tween Manager upon completion. This helps massively in reducing stale references and memory consumption. However, if you require your Tween to live-on, even after playback, then you can now specify a new persists boolean flag when creating it, or toggle the Tween.persist property before playback. This will force the Tween to not be destroyed by the Tween Manager, allowing you to replay it at any later point. The trade-off is that you are now entirely responsible for destroying the Tween when you are finished with it, in order to free-up resources.
All of the 'Scope' tween configuration callback properties have been removed, including onActiveScope, onCompleteScope, onLoopScope, onPauseScope, onRepeatScope, onResumeScope, onStartScope, onStopScope, onUpdateScope and onYoyoScope. You should set the callbackScope property instead, which will globally set the scope for all callbacks. You can also set the Tween.callbackScope property.

The following are to do with the new Chained Tweens feature:

TweenManager.chain - TODO
Tween.getChainedTweens is a new method that will return all of the tweens in a chained sequence, starting from the point of the Tween this is called on.
TweenManager.getChainedTweens(tween) is a new method that will return all of the tweens in a chained sequence, starting from the given tween.
You can now specify a target property as 'random' to have the Tween pick a random float between two given values, for example: alpha: 'random(0.25, 0.75)'. If you wish to force it to select a random integer, use 'int' instead: x: 'int(300, 600)'.

The following are further updates within the Tween system:

TweenManager.add and TweenManager.create can now optionally take an array of Tween Configuration objects. Each Tween will be created, added to the Tween Manager and then returned in an array. You can still pass in a single config if you wish.
Tween.pause is a new method that allows you to pause a Tween. This will emit the PAUSE event and, if set, fire the onPause callback.
Tween.resume is a new method that allows you to resume a paused Tween. This will emit the RESUME event and, if set, fire the onResume callback.
There is a new TweenOnPauseCallback available when creating a Tween (via the onPause property). This comes with associated onPauseParams and onPauseScope properties, too, like all other callbacks and can also be added via the Tween.setCallbacks method. This callback is invoked if you pause the Tween.
There is a new TweenOnResumeCallback available when creating a Tween (via the onResume property). This comes with associated onResumeParams and onResumeScope properties, too, like all other callbacks and can also be added via the Tween.setCallbacks method. This callback is invoked if you resume a previously paused Tween.
The property value of a Tween can now be an array, i.e. x: [ 100, 300, 200, 600 ] in which case the Tween will use interpolation to determine the value.
You can now specify an interpolation property in the Tween config to set which interpolation method the Tween will use if an array of numeric values have been given as the tween value. Valid values includes linear, bezier and catmull (or catmullrom), or you can provide your own function to use.
You can now specify a scale property in a Tween config and, if the target does not have a scale property itself (i.e. a GameObject) then it will automatically apply the value to both scaleX and scaleY together during the tween. This is a nice short-cut way to tween the scale of Game Objects by only specifying one property, instead of two.
killTweensOf(targets) now supports deeply-nested arrays of items as the target parameter. Fix #6016 (thanks @michalfialadev)
killTweensOf(target) did not stop target tweens if called immediately after tween creation. Fix #6173 (thanks @michalfialadev)
It wasn't possible to resume a Tween that was immediately paused after creation. Fix #6169 (thanks @trynx)
Calling Tween.setCallback() without specifying the params argument would cause an error invoking the callback params. This parameter is now fully optional. Fix #6047 (thanks @orcomarcio)
Calling Tween.play immediately after creating a tween with paused: true in the config wouldn't start playback. Fix #6005 (thanks @MartinEyebab)
Fixed an issue where neither Tweens or Timelines would factor in the Tween Manager timeScale value unless they were using frame-based timing instead of delta timing.
The first parameter to Tween.seek, toPosition now defaults to zero. Previously, you had to specify a value.
The TweenBuilder now uses the new GetInterpolationFunction function internally.
The TweenBuilder has been optimized to perform far less functions when creating the TweenData instances.
The keyword interpolation has been added to the Reserved Words list and Defaults list (it defaults to null).
The keyword persists has been added to the Reserved Words list and Defaults list (it defaults to false).
Tween.initTweenData is a new method that handles the initialisation of all the Tween Data and Tween values. This replaces what took place in the init and seek methods previously. This is called automatically and should not usually be invoked directly.
The internal Tween.calcDuration method has been removed. This is now handled as part of the initTweenData call.
Fixed a bug where setting repeat and hold would cause the Tween to include one final hold before marking itself as complete. It now completes as soon as the final repeat concludes, not after an addition hold.

New Features - Dynamic Textures and Render Textures

A Dynamic Texture is a special texture that allows you to draw textures, frames and most kind of Game Objects directly to it.

You can take many complex objects and draw them to this one texture, which can then be used as the base texture for other Game Objects, such as Sprites. Should you then update this texture, all Game Objects using it will instantly be updated as well, reflecting the changes immediately.

It's a powerful way to generate dynamic textures at run-time that are WebGL friendly and don't invoke expensive GPU uploads on each change.

Before Phaser 3.60 this was known as a Render Texture. Dynamic Textures have been optimized and also offer the following new features and updates. All of these are also available to the new Render Texture, via the texture property:

TextureManager.addDynamicTexture(key, width, height) is a new method that will create a Dynamic Texture and store it in the Texture Manager, available globally for use by any Game Object.
Unlike the old Render Texture, Dynamic Texture extends the native Phaser.Texture class, meaning you can use it for any texture based object and also call all of the native Texture methods, such as the ability to add frames to it, use it as the backing source for a sprite sheet or atlas, and more.
Dynamic Textures no longer create both Render Targets and Canvas objects, only the one that they require based on the renderer. This means Render Textures and Dynamic Textures now use 50% less memory under WebGL and don't create Canvas DOM elements.
You can now directly use a Dynamic Texture as the source for a Bitmap Mask.
Game Objects that have a mask will now reflect this when drawn to a Dynamic Texture.
DynamicTexture.isDrawing is a new boolean that allows you to tell if a batch draw has been started and is in process.
DynamicTexture.isSpriteTexture is a new boolean that informs the texture if it is being used as a backing texture for Sprite Game Objects, or not. If it is (which is the default) then items drawn to the texture are automatically inversed. Doing this ensures that images drawn to the Render Texture are correctly inverted for rendering in WebGL. Not doing so can cause inverted frames. If you use this method, you must use it before drawing anything to the Render Texture. Fix #6057 #6017 (thanks @andymikulski @Grandnainconnu)
DynamicTexture.setIsSpriteTexture is a new method that allows you to toggle the isSpriteTexture property in a chained manner.
DynamicTexture.renderTarget is a new property that holds an instance of a RenderTarget under WebGL. This encompasses a framebuffer and backing texture, rather than having them split.
DynamicTexture.stamp is a new method that takes a given texture key and then stamps it at the x/y coordinates provided. You can also pass in a config object that gives a lot more control, such as alpha, tint, angle, scale and origin of the stamp. This is a much cleaner way of stamping a texture to the DynamicTexture without having to first turn it into a Game Object.
DynamicTexture.repeat is a new method that will take a given texture and draw it to the Dynamic Texture as a fill-pattern. You can control the offset, width, height, alpha and tint of the draw (thanks xlapiz)
batchGameObject now splits based on the renderer, allowing us to combine lots of the rendering code together, saving space.
The snapshot and snapshotPixel methods now use the snapshotArea method to reduce code and filesize.
The snapshotPixel function, used by the Canvas and WebGL Renderers and the RenderTexture would mistakenly divide the alpha value. These values now return correctly (thanks @samme)
DynamicTexture.batchTextureFrame will now skip the drawImage call in canvas if the frame width or height are zero. Fix #5951 (thanks @Hoshinokoe)
Using DynamicTexture.fill in CANVAS mode only would produce a nearly always black color due to float conversion (thanks @andymikulski)
Using DynamicTexture.fill in CANVAS mode only, after using the erase method, wouldn't reset the global composite operation correctly, resulting in fills. Fix #6124 (thanks @mateuszkmiecik)
Drawing a frame via draw, drawFrame or batchDrawFrame and specifying a tint value would inverse the Red and Blue channels. These are now handled properly. Fix #5509 (thanks @anthonygood)

Due to the creation of the Dynamic Texture class, we have completely revamped the old Render Texture Game Object. This is now a combination of a Dynamic Texture and an Image Game Object, that uses the Dynamic Texture to display itself with.

In versions of Phaser before 3.60 a Render Texture was the only way you could create a texture like this, that had the ability to be drawn on. But in 3.60 we split the core functions out to the Dynamic Texture class as it made a lot more sense for them to reside in there. As a result, the Render Texture is now a light-weight shim that sits on-top of an Image Game Object and offers proxy methods to the features available from a Dynamic Texture.

Render Texture breaking changes:

Render Textures used to be able to take key and frame arguments in their constructors, which would take the texture from the Texture Manager and use that instance, instead of creating a new one. Because Dynamic Textures are always stored in the Texture Manager from the beginning, there is no need to specify these arguments. You can just get it from the Texture Manager by using its key.
The following RenderTexture properties have changed:
renderer is now available via texture.renderer.
textureManager has been removed.
globalTint has been removed.
globalAlpha has been removed.
canvas is now available via texture.canvas.
context is now available via texture.context.
dirty is now available via texture.dirty.
camera is now available via texture.camera.
renderTarget is now available via texture.renderTarget.
origin is now (0.5, 0.5) by default instead of (0, 0).
The following RenderTexture methods have changed:
drawGameObject has been removed, this is now handled by the batch methods.
resize has been renamed. Use setSize(width, height) instead.
setGlobalTint has been removed as it's no longer used internally.
setGlobalAlpha has been removed as it's no longer used internally.
batchGameObjectWebGL has been removed, now handled by batchGameObject.
batchGameObjectCanvas has been removed, now handled by batchGameObject.

When should you use a Render Texture vs. a Dynamic Texture?

You should use a Dynamic Texture if the texture is going to be used by multiple Game Objects, or you want to use it across multiple Scenes, because textures are globally stored.

You should use a Dynamic Texture if the texture isn't going to be displayed in-game, but is instead going to be used for something like a mask or shader.

You should use a Render Texture if you need to display the texture in-game on a single Game Object, as it provides the convenience of wrapping an Image and Dynamic Texture together for you.

Post Pipeline Updates

In order to add clarity in the codebase we have created a new PostPipeline Component and moved all of the relevant functions from the Pipeline component in to it. This leads to the following changes:

PostPipeline is a new Game Object Component that is now inherited by all Game Objects that are capable of using it.
Game Objects with the PostPipeline component now have a new property called postPipelineData. This object is used for storing Post Pipeline specific data in. Previously, both regular and post pipelines used the same pipelineData object, but this has now been split up for flexibility.
The Pipeline.resetPipeline method no longer has its first resetPostPipelines argument. It now has just one argument resetData so please be aware of this if you call this function anywhere in your code.
PostPipeline.initPostPipeline is a new method that should be called by any Game Object that supports Post Pipelines.
The following Game Objects now have the new PostPipeline Component exclusively: Container and Layer.

Input System Updates

There are breaking changes from previous versions of Phaser.

The InteractiveObject.alwaysEnabled property has been removed. It is no longer checked within the InputPlugin and setting it will have no effect. This property has not worked correctly since version 3.52 when the new render list was implemented. Upon further investigation we decided to remove the property entirely, rather than shoe-horn it into the render list. If you need to create a non-rendering Interactive area, use the Zone Game Object instead.

Bitmap Mask Updates