Clarifying Phaser 3, new Components, Colors and Dirty Renderer
It's been another insane week of Phaser 3 development. If you're subscribed to the GitHub watch list, then I apologise for the huge volume of commit emails you'll have been receiving lately :)
There is some confusion over what Phaser 3 is. I take the blame for that, because I confused matters by talking about Lazer so much, and saying it would be Phaser 3. So it's time to set the record straight:
- Phaser 3 is written in ES5, not ES6.
- It uses the same renderer as Phaser 2, but with huge improvements
- It removes the PIXI namespace
- There are brand new Game Objects and Components
- There is a new internal structure
- It deprecates a bunch of old Phaser 2 ways of doing things
- It is NOT API compatible with Phaser 2
- There will be a migration guide published on release
- It is in heavy active development right now, changing every day
- It will be maintained after release
- There is no ETA yet, but I'm confident it'll be this year
Fundamentally the way you do things in Phaser 3 is very similar to Phaser 2. In lots of cases it's identical, but you absolutely will not be able to just run your Phaser 2 code directly and expect it to work, because it's highly likely it won't. Migration will be needed. Lots of new Examples are being created to help ease the transition.
New Components
This week I added a bunch of new Components. The first was the Transform component. This manages all transform updates for a Game Object, such as changing position, scale or rotation. It also propagates those down to any children it may have. It uses aggressive caching and a Dirty state manager, meaning if nothing has changed in the display list, then no transform updates take place. If a leaf node in the display list is dirty, then only that node (and its direct children) are updated, the rest of the list is kept clean. This has reduced processing overhead on scenes tremendously. I'll share some stats and timeline charts with you soon to show this.
Transform properties, such as Scale, are no longer Point objects. This reduced the sheer number of objects being created for every Game Object, but more importantly we don't need to worry about Observable Points, and you can now do things like single tweens that adjust the position, scale and rotation of a Sprite all at once, in one single go. It's a lot cleaner, and I'm looking forward to sharing it with you.
Another feature of the new Transform class is that it's not tied to the Game Object hierarchy. Every Game Object has a Transform component, and a Game Object can also have a parent - but the two are not linked. This means you can group similar Game Objects together in a single Container or pool, but that when it comes to rendering them they can have their own entirely separate transform ancestry. While for most use-cases you will want them combined, they don't have to be, and that's the key difference.
Colors Ahoy
Another new Component is the Color component. This manages display related properties for a Game Object, such as the blend mode, alpha, tinting and a new feature: the ability to set a background color behind a Sprite. As with Transforms, Color updates are aggressively cached, and also use the Dirty state manager. You're now able to set a background color that renders behind the Sprite, and you can control each color channel directly - allowing you to easily tween the values.
Dirty Renderer
Because of the way that the Components work, it's possible to set the renderer into a new state whereby it only updates the scene if something on the display list is dirty. For example you could render 1000 sprites, but if none of them move for a while, then it doesn't need to re-render the scene. It can just skip the clear and draw phase entirely. It's not just motion either, even changing alpha is handled. So a Game Object that is fading in and out will still cause a render refresh, but a static scene won't.
In tests this has made a huge improvement. You tend to notice it most on mobile, where because it doesn't have to redraw the frame 60 times a second, then the CPU / GPU does a lot less work, and the devices don't get so hot! Obviously for some games this will be useless, but I feel there are many potential use-cases for it, especially in the casual space, and anything that saves battery life, and improves performance, has to be a win.
There's more I want to write about, but you'll have to come back next week for it :) Development is really exciting right now. I'm loving the shape this is all taking, and I thank you to everyone on Patreon who is making this possible by supporting Phaser.
It's been another insane week of Phaser 3 development. If you're subscribed to the GitHub watch list, then I apologise for the huge volume of commit emails you'll have been receiving lately :)
There is some confusion over what Phaser 3 is. I take the blame for that, because I confused matters by talking about Lazer so much, and saying it would be Phaser 3. So it's time to set the record straight:
- Phaser 3 is written in ES5, not ES6.
- It uses the same renderer as Phaser 2, but with huge improvements
- It removes the PIXI namespace
- There are brand new Game Objects and Components
- There is a new internal structure
- It deprecates a bunch of old Phaser 2 ways of doing things
- It is NOT API compatible with Phaser 2
- There will be a migration guide published on release
- It is in heavy active development right now, changing every day
- It will be maintained after release
- There is no ETA yet, but I'm confident it'll be this year
Fundamentally the way you do things in Phaser 3 is very similar to Phaser 2. In lots of cases it's identical, but you absolutely will not be able to just run your Phaser 2 code directly and expect it to work, because it's highly likely it won't. Migration will be needed. Lots of new Examples are being created to help ease the transition.
New Components
This week I added a bunch of new Components. The first was the Transform component. This manages all transform updates for a Game Object, such as changing position, scale or rotation. It also propagates those down to any children it may have. It uses aggressive caching and a Dirty state manager, meaning if nothing has changed in the display list, then no transform updates take place. If a leaf node in the display list is dirty, then only that node (and its direct children) are updated, the rest of the list is kept clean. This has reduced processing overhead on scenes tremendously. I'll share some stats and timeline charts with you soon to show this.
Transform properties, such as Scale, are no longer Point objects. This reduced the sheer number of objects being created for every Game Object, but more importantly we don't need to worry about Observable Points, and you can now do things like single tweens that adjust the position, scale and rotation of a Sprite all at once, in one single go. It's a lot cleaner, and I'm looking forward to sharing it with you.
Another feature of the new Transform class is that it's not tied to the Game Object hierarchy. Every Game Object has a Transform component, and a Game Object can also have a parent - but the two are not linked. This means you can group similar Game Objects together in a single Container or pool, but that when it comes to rendering them they can have their own entirely separate transform ancestry. While for most use-cases you will want them combined, they don't have to be, and that's the key difference.
Colors Ahoy
Another new Component is the Color component. This manages display related properties for a Game Object, such as the blend mode, alpha, tinting and a new feature: the ability to set a background color behind a Sprite. As with Transforms, Color updates are aggressively cached, and also use the Dirty state manager. You're now able to set a background color that renders behind the Sprite, and you can control each color channel directly - allowing you to easily tween the values.
Dirty Renderer
Because of the way that the Components work, it's possible to set the renderer into a new state whereby it only updates the scene if something on the display list is dirty. For example you could render 1000 sprites, but if none of them move for a while, then it doesn't need to re-render the scene. It can just skip the clear and draw phase entirely. It's not just motion either, even changing alpha is handled. So a Game Object that is fading in and out will still cause a render refresh, but a static scene won't.
In tests this has made a huge improvement. You tend to notice it most on mobile, where because it doesn't have to redraw the frame 60 times a second, then the CPU / GPU does a lot less work, and the devices don't get so hot! Obviously for some games this will be useless, but I feel there are many potential use-cases for it, especially in the casual space, and anything that saves battery life, and improves performance, has to be a win.
There's more I want to write about, but you'll have to come back next week for it :) Development is really exciting right now. I'm loving the shape this is all taking, and I thank you to everyone on Patreon who is making this possible by supporting Phaser.