Phaser 3.61 Beta 2 is out

Published on 7th September 2023

I'm pleased to announce that Phaser v3.61 Beta 2 is now available. You can grab pre-built files and see the full Change Log on GitHub:

https://github.com/photonstorm/phaser/releases/tag/v3.61.0-beta.2

or you can grab the 'beta' tagged package from npm:

https://www.npmjs.com/package/phaser/v/3.61.0-beta.2

I have also updated the Phaser Labs, so 3.61 Beta 2 is now available in the drop-down versions list.

This release is a continuation of the work started in 3.61 Beta 1, with a focus on fixing issues reported by the community. The biggest fix, which I'd appreciate if you could test as much as possible, is the one involving PostFX becoming all screwed if you then resize the canvas. I've done quite a bit of testing after implementing the fix, and it seems to be working well, but I'd like to be sure.

Another big fix is the way that Dynamic Textures were destroyed. Although they had a pre-destroy method, it was never called. This would cause an accumulation of framebuffers in memory, as the old ones were never removed. They now override the base Texture class and hook into the destroy method there, so they are properly cleaned up.

I've also tidied up the way that frame buffers are destroyed within the WebGL Renderer. They'll automatically check to see if they have an attached depth texture, and if so, destroy that as well. This should help prevent memory leaks in extended play sessions.

I also found a really lovely bug myself, which would cause Chrome to fully crash WebGL! If you specified the width and height in your game config as a string, i.e. "800" instead of just 800, then it would try to create a monster-sized framebuffer, 800 times the size of the parent container. Needless to say, WebGL really didn't like this! Sneaky :)

This is now a lot more solid. If you use a string, i.e. to use a value such as "100%" (which is what you'd typically do), then it now recognizes this and uses the parent container scale as before. But if you have just a number value as a string, or it has a "px" suffix, then it will use that value directly as a number.

In terms of new features, I'm trying to keep those to a minimum. But I did add one, which I think is really handy. When you define or play an animation, you can set the new boolean property 'randomFrame'. If true, the animation will pick a random frame from any of those it has available and start playing from that. This is useful when you have a bunch of sprites all using the same animation, starting at the same time. You can see it in action here:

https://labs.phaser.io/view.html?src=src\animation\start%20from%20random%20frame.js&v=dev

Notice how even though the 3 sprites are all using the same animation, started at the exact same time, we're still able to give them some variety. Swap the version to 3.60, and you'll see them all start from frame 0.

Also, you can use this feature in the particle emitters! Emitters can actually accept Animation Play config objects as part of the emitter configuration. So, any property available in there, including this new one, is automatically available to the emitter.

Please give this version a test. I don't plan on doing much more before releasing it but I would like to give it some time to bake and get feedback on Discord before pulling the trigger.

See you all soon!

I'm pleased to announce that Phaser v3.61 Beta 2 is now available. You can grab pre-built files and see the full Change Log on GitHub:

https://github.com/photonstorm/phaser/releases/tag/v3.61.0-beta.2

or you can grab the 'beta' tagged package from npm:

https://www.npmjs.com/package/phaser/v/3.61.0-beta.2

I have also updated the Phaser Labs, so 3.61 Beta 2 is now available in the drop-down versions list.

This release is a continuation of the work started in 3.61 Beta 1, with a focus on fixing issues reported by the community. The biggest fix, which I'd appreciate if you could test as much as possible, is the one involving PostFX becoming all screwed if you then resize the canvas. I've done quite a bit of testing after implementing the fix, and it seems to be working well, but I'd like to be sure.

Another big fix is the way that Dynamic Textures were destroyed. Although they had a pre-destroy method, it was never called. This would cause an accumulation of framebuffers in memory, as the old ones were never removed. They now override the base Texture class and hook into the destroy method there, so they are properly cleaned up.

I've also tidied up the way that frame buffers are destroyed within the WebGL Renderer. They'll automatically check to see if they have an attached depth texture, and if so, destroy that as well. This should help prevent memory leaks in extended play sessions.

I also found a really lovely bug myself, which would cause Chrome to fully crash WebGL! If you specified the width and height in your game config as a string, i.e. "800" instead of just 800, then it would try to create a monster-sized framebuffer, 800 times the size of the parent container. Needless to say, WebGL really didn't like this! Sneaky :)

This is now a lot more solid. If you use a string, i.e. to use a value such as "100%" (which is what you'd typically do), then it now recognizes this and uses the parent container scale as before. But if you have just a number value as a string, or it has a "px" suffix, then it will use that value directly as a number.

In terms of new features, I'm trying to keep those to a minimum. But I did add one, which I think is really handy. When you define or play an animation, you can set the new boolean property 'randomFrame'. If true, the animation will pick a random frame from any of those it has available and start playing from that. This is useful when you have a bunch of sprites all using the same animation, starting at the same time. You can see it in action here:

https://labs.phaser.io/view.html?src=src\animation\start%20from%20random%20frame.js&v=dev

Notice how even though the 3 sprites are all using the same animation, started at the exact same time, we're still able to give them some variety. Swap the version to 3.60, and you'll see them all start from frame 0.

Also, you can use this feature in the particle emitters! Emitters can actually accept Animation Play config objects as part of the emitter configuration. So, any property available in there, including this new one, is automatically available to the emitter.

Please give this version a test. I don't plan on doing much more before releasing it but I would like to give it some time to bake and get feedback on Discord before pulling the trigger.

See you all soon!