V3 Beta 9, loads of fixes everywhere and lots of new examples.
Another week, another beta: Phaser 3 Beta 9 is now out. You can grab it from GitHub pre-built, or from npm using the beta tag. This build includes all work completed over the past week.
Help is at hand
I'm pleased to announce that I've now got two people helping me out with the Phaser News articles. It took a bit of time getting set-up but now they're up and running. It should free-up nearly a whole day a week for me, which is all time can now dedicate to v3.
A number of you also responded to my request for freelance devs to help get the V3 build finished. Thank you to everyone who did so. I have been in touch with several of you and we're in negotiations to get help underway for the Tilemap API and Sound API. Originally I was going to do the new Sound API, but someone with a lot more experience offered his help, so it'll free me up to work on another area instead. I'm having to be very careful because as you can appreciate these devs are being paid for their time, and I don't want to burn through what little reserves we have - even so, I feel this will be money well invested as it'll tick-off two massive areas of the API.
Nip and Tuck
We've seen a noticeable uptick in V3 issues reported on GitHub. This is great because it means people are starting to really look at it and it makes the API more solid as we work through the bugs and address them. So what's happened over the past 5 days of dev?
First I finished off adding in support for particle emitters on curves and paths. This has been shown in the Dev Logs before and isn't something new, but the API was tidied up and made a lot easier to extend and I created a couple of pretty demos to show it in action. Drag the handles around on this one for example:
You can emit along the edges of a Curve or Path now, either in sequence, with a yoyo enabled or just at random. This new example shows all 3 types in action at once on the same curve:
That's enough particles. Other than wanting to change how you apply a tint to them they're effectively fully complete now.
Felipe's first task of the week was to fix an issue with the Tilemap renderer where it would completely ignore the zoom factor of a camera, making creating mini-maps quite hard. This now works properly (as can be seen in this basic example).
Also on Tilemaps I also addressed an issue raised on GitHub where the renderer would cause corruption should the first tile of the tileset image not be transparent. When dealing with maps created in Tiled it starts with a 1 based offset for the tile IDs, but with map data from CSV files this isn't always the case. So in some cases, you want the renderer to skip zero index tiles and in others you want it to actually render them. The solution was a new flag in the Tilemap class 'skipIndexZero'. Toggle this and the renderer will switch accordingly. This works for both the Static and Dynamic tilemaps and covers both bases.
Game Object Bounds
After fixing some issues in the Event Dispatcher (deleting an event during its callback would throw an error) I moved on to addressing another reported issue, that getBounds didn't work if the origin of the Game Object wasn't zero. This actually turned out to be more involved than expected but lead way to some new API features that had been on the backlog for a while anyway. First of all Get Bounds was fixed, regardless of origin or scale:
And as a result, I implemented the methods getTopLeft, getTopRight, getBottomLeft and getBottomRight which return Vec2 objects containing the corresponding coordinate of the Game Object, again regardless of origin, rotation or scale:
The colored rectangles are the edge points. While the bounds are really useful for things like quick elimination tests and culling, the edge points are even more useful when it comes to object overlaps and more precise intersections. It's something I feel you should always have been able to get from any Game Object in v2, but you now can.
Sprite Sheets in Texture Atlases
Months ago when I built the Texture Manager I included the option to extract a sprite sheet from out of a texture atlas. At the time it only worked if the sprite sheet was un-trimmed and duly an issue was raised in GitHub about it. So I sat down and finished it off for once and all. It turned out to be a quite significant task but one which I feel was vitally important all the same.
What this now means is that you can include traditional fixed-frame sprite sheets within your texture atlases. This is especially useful if you have a number of animations that use sprite sheets and want to avoid texture thrashing on the GPU as a result of swapping from the atlas to another image and back again.
The reason it took a while to fix is that atlas software like Texture Packer has an option called 'Trim', which basically chops off all of the transparent space around images added to the atlas in order to save space. The offsets are then recorded in the atlas data and it's up to the renderer to figure it all out. Of course, everyone uses this feature. I certainly do! But it caused real problems for sprite sheets because sprite sheets work on the basis of every single frame being the exact same size. But if the atlas software has trimmed the edges fo the sheet then what you're left with is potentially the frames all along the top, bottom and sides having different sizes to those that were safely nestled in the middle.
After hours of wrestling with it, testing and creating all kinds of messed-up atlases I finally found a solid solution and merged it into V3. You can now have your cake and eat it.
Even more fixes
I also fixed issues with the displayOrigin setters, where it would calculate the wrong value due to an operator order error. I fixed an issue with the Input Manager where one event would be emitted from all scenes, rather than just the scene in which it was dispatched from. I fixed some eslint issues, removed random console logs, did more jsdoc work, fixed a huge stack of examples that relied on the old mousemove API and even fixed an issue in the TweenData class where it would incorrectly set the start values if the end value was relative. It's been a busy week for sure.
While I've been doing this, Felipe has been working on adding the last great (and needed) feature to the renderer: masks. We're supporting both Geometry and Bitmap based masks, using a variety of methods: stencil buffer, canvas clip and shader FBO based, to give the best variety of results and speed. Masking is vitally important in games and in V2 it was quite limited. You could only use shapes like rectangles and circles for it, and invoking more complex shapes over lots of objects became really expensive. We wanted V3 to have a proper modern mask system and that is what we will hopefully demo to you next week.
Friday Fun
It was a long, hard week of development. So to let off a little steam, and to also test another approach at isometric support, I created a small demo on Friday. It's basically a bunch of iso blocks with a fun wave pattern running through them, each z-index depth sorted in real-time.
You can use the arrow keys to move the camera and zoom in and out :) Feel free to edit the source and see what you can create. It's all handled with a couple of tween callbacks.
That's it for this Dev Log. Next week I'll bring you an update on the development schedule. We're obviously behind where we wanted to be (by around 1 month) although I'm hoping the extra help I'm bringing onboard will claw some of that back. I've got a mixed bag of issues, features and the ever continuing jsdoc work to do this week and then I'll start planning out the new Scale Manager in more depth. I've already got a lot of ideas for it but haven't started development yet.
If you were one of those who opened a V3 GitHub issue then thank you! They all help make it more stable and powerful. If not, please give Beta 9 and whirl and let us know how you get on.
Phaser 3 Labs
Phaser 3 Beta 9 is out and ready for testing.
Visit the Phaser 3 Labs to view the new API structure in depth, read the FAQ, previous Developer Logs and contribution guides.
You can also join the Phaser 3 Google Group or post to the Phaser 3 Forum - we'd love to hear from you!
Another week, another beta: Phaser 3 Beta 9 is now out. You can grab it from GitHub pre-built, or from npm using the beta tag. This build includes all work completed over the past week.
Help is at hand
I'm pleased to announce that I've now got two people helping me out with the Phaser News articles. It took a bit of time getting set-up but now they're up and running. It should free-up nearly a whole day a week for me, which is all time can now dedicate to v3.
A number of you also responded to my request for freelance devs to help get the V3 build finished. Thank you to everyone who did so. I have been in touch with several of you and we're in negotiations to get help underway for the Tilemap API and Sound API. Originally I was going to do the new Sound API, but someone with a lot more experience offered his help, so it'll free me up to work on another area instead. I'm having to be very careful because as you can appreciate these devs are being paid for their time, and I don't want to burn through what little reserves we have - even so, I feel this will be money well invested as it'll tick-off two massive areas of the API.
Nip and Tuck
We've seen a noticeable uptick in V3 issues reported on GitHub. This is great because it means people are starting to really look at it and it makes the API more solid as we work through the bugs and address them. So what's happened over the past 5 days of dev?
First I finished off adding in support for particle emitters on curves and paths. This has been shown in the Dev Logs before and isn't something new, but the API was tidied up and made a lot easier to extend and I created a couple of pretty demos to show it in action. Drag the handles around on this one for example:
You can emit along the edges of a Curve or Path now, either in sequence, with a yoyo enabled or just at random. This new example shows all 3 types in action at once on the same curve:
That's enough particles. Other than wanting to change how you apply a tint to them they're effectively fully complete now.
Felipe's first task of the week was to fix an issue with the Tilemap renderer where it would completely ignore the zoom factor of a camera, making creating mini-maps quite hard. This now works properly (as can be seen in this basic example).
Also on Tilemaps I also addressed an issue raised on GitHub where the renderer would cause corruption should the first tile of the tileset image not be transparent. When dealing with maps created in Tiled it starts with a 1 based offset for the tile IDs, but with map data from CSV files this isn't always the case. So in some cases, you want the renderer to skip zero index tiles and in others you want it to actually render them. The solution was a new flag in the Tilemap class 'skipIndexZero'. Toggle this and the renderer will switch accordingly. This works for both the Static and Dynamic tilemaps and covers both bases.
Game Object Bounds
After fixing some issues in the Event Dispatcher (deleting an event during its callback would throw an error) I moved on to addressing another reported issue, that getBounds didn't work if the origin of the Game Object wasn't zero. This actually turned out to be more involved than expected but lead way to some new API features that had been on the backlog for a while anyway. First of all Get Bounds was fixed, regardless of origin or scale:
And as a result, I implemented the methods getTopLeft, getTopRight, getBottomLeft and getBottomRight which return Vec2 objects containing the corresponding coordinate of the Game Object, again regardless of origin, rotation or scale:
The colored rectangles are the edge points. While the bounds are really useful for things like quick elimination tests and culling, the edge points are even more useful when it comes to object overlaps and more precise intersections. It's something I feel you should always have been able to get from any Game Object in v2, but you now can.
Sprite Sheets in Texture Atlases
Months ago when I built the Texture Manager I included the option to extract a sprite sheet from out of a texture atlas. At the time it only worked if the sprite sheet was un-trimmed and duly an issue was raised in GitHub about it. So I sat down and finished it off for once and all. It turned out to be a quite significant task but one which I feel was vitally important all the same.
What this now means is that you can include traditional fixed-frame sprite sheets within your texture atlases. This is especially useful if you have a number of animations that use sprite sheets and want to avoid texture thrashing on the GPU as a result of swapping from the atlas to another image and back again.
The reason it took a while to fix is that atlas software like Texture Packer has an option called 'Trim', which basically chops off all of the transparent space around images added to the atlas in order to save space. The offsets are then recorded in the atlas data and it's up to the renderer to figure it all out. Of course, everyone uses this feature. I certainly do! But it caused real problems for sprite sheets because sprite sheets work on the basis of every single frame being the exact same size. But if the atlas software has trimmed the edges fo the sheet then what you're left with is potentially the frames all along the top, bottom and sides having different sizes to those that were safely nestled in the middle.
After hours of wrestling with it, testing and creating all kinds of messed-up atlases I finally found a solid solution and merged it into V3. You can now have your cake and eat it.
Even more fixes
I also fixed issues with the displayOrigin setters, where it would calculate the wrong value due to an operator order error. I fixed an issue with the Input Manager where one event would be emitted from all scenes, rather than just the scene in which it was dispatched from. I fixed some eslint issues, removed random console logs, did more jsdoc work, fixed a huge stack of examples that relied on the old mousemove API and even fixed an issue in the TweenData class where it would incorrectly set the start values if the end value was relative. It's been a busy week for sure.
While I've been doing this, Felipe has been working on adding the last great (and needed) feature to the renderer: masks. We're supporting both Geometry and Bitmap based masks, using a variety of methods: stencil buffer, canvas clip and shader FBO based, to give the best variety of results and speed. Masking is vitally important in games and in V2 it was quite limited. You could only use shapes like rectangles and circles for it, and invoking more complex shapes over lots of objects became really expensive. We wanted V3 to have a proper modern mask system and that is what we will hopefully demo to you next week.
Friday Fun
It was a long, hard week of development. So to let off a little steam, and to also test another approach at isometric support, I created a small demo on Friday. It's basically a bunch of iso blocks with a fun wave pattern running through them, each z-index depth sorted in real-time.
You can use the arrow keys to move the camera and zoom in and out :) Feel free to edit the source and see what you can create. It's all handled with a couple of tween callbacks.
That's it for this Dev Log. Next week I'll bring you an update on the development schedule. We're obviously behind where we wanted to be (by around 1 month) although I'm hoping the extra help I'm bringing onboard will claw some of that back. I've got a mixed bag of issues, features and the ever continuing jsdoc work to do this week and then I'll start planning out the new Scale Manager in more depth. I've already got a lot of ideas for it but haven't started development yet.
If you were one of those who opened a V3 GitHub issue then thank you! They all help make it more stable and powerful. If not, please give Beta 9 and whirl and let us know how you get on.
Phaser 3 Labs
Phaser 3 Beta 9 is out and ready for testing.
Visit the Phaser 3 Labs to view the new API structure in depth, read the FAQ, previous Developer Logs and contribution guides.
You can also join the Phaser 3 Google Group or post to the Phaser 3 Forum - we'd love to hear from you!