Phaser World Issue 170
Here is what the team has been up to this week:
Arian: Greetings from South Florida! This has been a week very similar to the previous one. I have been testing different cloud build services, which we will use for some of our products. Cloud compilation? Surely you can imagine what we're up to. The good news, I have carried out very satisfactory tests with the solutions provided by AWS. I believe that with AWS we will be able to create robust and efficient products, therefore, next week I will continue exploring how to use AWS to solve the different challenges we have.
In addition to my adventures with AWS CodeBuild, AWS S3, AWS EC2, Docker, Microsoft Azure, Windows Server, Linux, Android SDK, squirrels in the garden, ducks in the street, and crocodiles in puddles, the most pleasant time is talking with you, the Phaser community, and help you with Phaser Editor. If you have any questions, ideas, or problems with our editor, connect to the #phaser-editor channel on our Discord server. You can also stop by and say hi, we'd love that.
Robert: This week my time has been consumed with codemods which have been meticulously crafted to automate the refactoring process and seamlessly transition the codebase to ES6, that is 2000+ files! As I prepare to wrap up this effort, my focus shifts to patterns which can be restructured and reduce interdependence. It's a delicate process, ensuring that the improvements translate to a uninterrupted experience for the end user.
My next goal: unlocking Space Dude in Vampire Survivors!
Francisco: Greetings from Spain (and also Nicaragua from my heart). This week, I released new templates for Svelte, Solidjs, and Angular. These are designed to help developers get started on their projects more efficiently. I'm also working on a project to make it easier for developers to download these templates. The goal is to streamline the process and improve the development workflow without any fuss.
Can: Hello there from the Mediterranean Sea,
This week, I had the pleasure of integrating the final ad network on our list, Kayzen, into our repertoire. With this latest addition, we now boast support for a total of 10 ad networks tailored specifically for playable ads! However, the journey doesn't end here. I'm currently dedicating my efforts towards the development of a unified API, designed to streamline the implementation process for your playable ads. Rest assured, documentation will accompany this, guiding you seamlessly through its integration. I'm eagerly anticipating the deployment of this project into production and am excited to witness the enhancement it will bring to your creative playables.
If you have any questions on how Phaser can help you with playables, feel free to contact me at can@phaser.io
Ben: Tales from the Pixel Mines - dated 2024.03.08
"Those who seek shall find". It's a truism, but it conceals a secret: when you start searching, you don't always know what you're going to find.
This week, I started work on a new WebGL state management system, to support cool new mask features. But early on, I took a moment to check some issues with compressed textures. I didn't know how deep the investigation would go.
Hardware compressed textures were rendering darker than expected. This surprised a lot of people. The truth of the matter is, the Web and WebGL have a small disagreement about color. In the depths of WebGL, color is linear: a value of 0.4 is twice as bright as 0.2. On the Web, everything is treated as sRGB color. This color space is non-linear, so 0.4 might be three times brighter than 0.2. Ordinary textures are adjusted from sRGB as they are loaded into WebGL, and adjusted back when they go onto the screen, so they look correct. But hardware compressed textures are decompressed on the GPU itself, so they can't be loaded with adjustments. Compressed textures in WebGL are just darker than usual.
The solution is simple: lighten the textures before compressing them. I consulted an ancient wizard, and learned to use ImageMagick: magick input.png -set colorspace RGB -colorspace sRGB output.png.
But as I investigated, I found that this wizardry was rare knowledge. In fact, while consulting many examples of compressed textures across the Web, I found that nearly all of them were riddled with mistakes. Some textures were lightened; some were not; frequently they were mixed together. It's as though nobody told them that they needed to lighten their textures.
So I'm here to share the ancient wizardry. Lighten your textures before compression! You, too, can benefit from the magick that I found.
I believe I'm going to get back to masks, but who knows what mystery tomorrow may bring?
Rich: This week has been a usual mixture of project management, meetings, and coding. And oh, so many projects! In our private Phaser Studio Discord, we have a Projects category, with channels for each project that is in active development. They all have unique names. For example, Project Kraken is our endeavor to provide as many Phaser project templates as possible. So, if you want to get started using Rollup, React, or Svelte, the aim is that we've got you covered. Why kraken? Because it's a multi-tentacled beast, of course! Hopefully dragging you into the Phaser universe :)
Project Zeus is (hopefully!) going to be our physics system that replaces everything that has come before it. Farewell Arcade, Matter, Ninja, P2, Box2d, Impact et all. Testing has proven it's more than capable, but there's still more development and lots of documentation and examples left to create.
Project Ad-Venture is all the work Can has been doing, creating a unified API for communicating with all of the major Ad Networks out there.
Project Giftwrap allows you to launch Phaser Editor (or a page on our new site), hit 'publish, and get a cloud-built Android APK or Windows EXE or similar back again, all wrapped and bundled for you.
Project Catnip is the process of upgrading the entire Phaser codebase to ES6 and ESM. This will form the basis of our Phaser v4 release.
Project Lucifer is all of the work Ben is doing upgrading the WebGL Renderer, and eventually moving onto WebGPU.
Plus, there's lots more going on I can't quite yet talk about. Hopefully, what you can see here is the bigger picture building up whereby we offer you the full development lifecycle. Start with a template that is most comfortable for you (React? Svelte? No problem!), bring it into Phaser Editor, save it to your project space on our site, and when you're ready, publish it to a mobile or desktop app or maybe to any of the 10 major Playable Ad Networks we support. The idea is that everything is interconnected, and you don't suddenly hit a point where we say to you, "No, go research and do that bit yourself." Phaser Studio is starting its third month of operation as I write this, and we've already achieved a lot. There's more to go, of course, but it's going to be an exciting year for sure.
I received an email from a long-time Phaser developer, which I felt was worth answering here for everyone's benefit. This is mostly relevant to those of you who have followed Phaser for a few years, but hopefully, it clears things up.
The email asked: Is Phaser 3 end of life, and what happened to all the work that was done on Phaser 4?
I spent a lot of time during 2021/2022 working on Phaser 4 and writing about the progress in my Dev Logs. There were plenty of examples and sample code, and I was excited by the direction in which it was taking. However, it was never production ready. Not even close. I wouldn't even class it as Beta level. It was a complete rewrite from scratch. Every single thing about it was new and un-tested. Why? Because that's what developers do, isn't it? Starting a fresh project is like having infinite possibilities stretching out before you. It's exciting. After almost a decade of working on Phaser, I needed to start over again for my own sake. To try and right some of the corners I had painted myself into with the Phaser 3 structure.
Yet the one thing I didn't do back then was ask anyone if this was a good idea or not. I never really factored in what the thousands of people using Phaser actually wanted. Make no mistake, there were (and still are) whole companies formed around developing with it. Teams trained on it. Thousands of products were created with it.
Had I stopped to think and talk, I would have quickly realized what most people wanted wasn't to have to re-learn everything again from scratch and fight with potentially hundreds of unknown bugs in an un-tested framework. It was simply to resolve the bigger issues in the current one.
It took me a while but I did come to understand this. That is what all of the work on the v3.60 release was for. It was my way of righting most of the wrongs and addressing the big-ticket items in v3 that needed sorting. People were very happy with v3.60, so I carried on with more updates and moved over lots of the knowledge I had gained in the v4 R\&D to v3.70. Even after this release, however, I still fully anticipated moving back to Phaser 4.
Then I met OCV, and together, we created Phaser Studio. And this changed everything. For a start, I no longer have to do everything on my own! We literally have someone whose sole job is upgrading Phaser 3 to a modern codebase. We have someone who can spend all of his time deep-diving into the guts of WebGL and ensuring we stay fast and performant. We've got Arian and his superb Phaser Editor to bring visual tools to those who need them.
It took me quite a while to realize that Phaser 3 was not at the end of its life. It's a solid, battle-tested, and very capable framework. Yes, it needs modernizing from the internals and build point of view, but that is literally happening as I type this. We closed off hundreds of bugs and issues in the recent 3.80 release. Ben is pushing the renderer into superb new realms and the rest of the team are ensuring the whole ecosystem around Phaser grows along with it.
We still have a decision to make about version numbers. The ES6/ESM version will almost certainly be our 4.0.0 release. The "old" 2021 Phaser 4 has been put on ice, and the repo set to Private. There are no plans to re-open it. I feel that now, with our team in place, we can easily migrate the more important core concepts I explored into the current version of Phaser, so everyone can benefit without having to start over from scratch.
When Phaser Studio changes into its next form in 2025, we will look at implementing 3D, WebGPU, and other features by evolving the framework, not replacing it. No more throwing the baby out with the bath water. Evolution is the key.
Here is what the team has been up to this week:
Arian: Greetings from South Florida! This has been a week very similar to the previous one. I have been testing different cloud build services, which we will use for some of our products. Cloud compilation? Surely you can imagine what we're up to. The good news, I have carried out very satisfactory tests with the solutions provided by AWS. I believe that with AWS we will be able to create robust and efficient products, therefore, next week I will continue exploring how to use AWS to solve the different challenges we have.
In addition to my adventures with AWS CodeBuild, AWS S3, AWS EC2, Docker, Microsoft Azure, Windows Server, Linux, Android SDK, squirrels in the garden, ducks in the street, and crocodiles in puddles, the most pleasant time is talking with you, the Phaser community, and help you with Phaser Editor. If you have any questions, ideas, or problems with our editor, connect to the #phaser-editor channel on our Discord server. You can also stop by and say hi, we'd love that.
Robert: This week my time has been consumed with codemods which have been meticulously crafted to automate the refactoring process and seamlessly transition the codebase to ES6, that is 2000+ files! As I prepare to wrap up this effort, my focus shifts to patterns which can be restructured and reduce interdependence. It's a delicate process, ensuring that the improvements translate to a uninterrupted experience for the end user.
My next goal: unlocking Space Dude in Vampire Survivors!
Francisco: Greetings from Spain (and also Nicaragua from my heart). This week, I released new templates for Svelte, Solidjs, and Angular. These are designed to help developers get started on their projects more efficiently. I'm also working on a project to make it easier for developers to download these templates. The goal is to streamline the process and improve the development workflow without any fuss.
Can: Hello there from the Mediterranean Sea,
This week, I had the pleasure of integrating the final ad network on our list, Kayzen, into our repertoire. With this latest addition, we now boast support for a total of 10 ad networks tailored specifically for playable ads! However, the journey doesn't end here. I'm currently dedicating my efforts towards the development of a unified API, designed to streamline the implementation process for your playable ads. Rest assured, documentation will accompany this, guiding you seamlessly through its integration. I'm eagerly anticipating the deployment of this project into production and am excited to witness the enhancement it will bring to your creative playables.
If you have any questions on how Phaser can help you with playables, feel free to contact me at can@phaser.io
Ben: Tales from the Pixel Mines - dated 2024.03.08
"Those who seek shall find". It's a truism, but it conceals a secret: when you start searching, you don't always know what you're going to find.
This week, I started work on a new WebGL state management system, to support cool new mask features. But early on, I took a moment to check some issues with compressed textures. I didn't know how deep the investigation would go.
Hardware compressed textures were rendering darker than expected. This surprised a lot of people. The truth of the matter is, the Web and WebGL have a small disagreement about color. In the depths of WebGL, color is linear: a value of 0.4 is twice as bright as 0.2. On the Web, everything is treated as sRGB color. This color space is non-linear, so 0.4 might be three times brighter than 0.2. Ordinary textures are adjusted from sRGB as they are loaded into WebGL, and adjusted back when they go onto the screen, so they look correct. But hardware compressed textures are decompressed on the GPU itself, so they can't be loaded with adjustments. Compressed textures in WebGL are just darker than usual.
The solution is simple: lighten the textures before compressing them. I consulted an ancient wizard, and learned to use ImageMagick: magick input.png -set colorspace RGB -colorspace sRGB output.png.
But as I investigated, I found that this wizardry was rare knowledge. In fact, while consulting many examples of compressed textures across the Web, I found that nearly all of them were riddled with mistakes. Some textures were lightened; some were not; frequently they were mixed together. It's as though nobody told them that they needed to lighten their textures.
So I'm here to share the ancient wizardry. Lighten your textures before compression! You, too, can benefit from the magick that I found.
I believe I'm going to get back to masks, but who knows what mystery tomorrow may bring?
Rich: This week has been a usual mixture of project management, meetings, and coding. And oh, so many projects! In our private Phaser Studio Discord, we have a Projects category, with channels for each project that is in active development. They all have unique names. For example, Project Kraken is our endeavor to provide as many Phaser project templates as possible. So, if you want to get started using Rollup, React, or Svelte, the aim is that we've got you covered. Why kraken? Because it's a multi-tentacled beast, of course! Hopefully dragging you into the Phaser universe :)
Project Zeus is (hopefully!) going to be our physics system that replaces everything that has come before it. Farewell Arcade, Matter, Ninja, P2, Box2d, Impact et all. Testing has proven it's more than capable, but there's still more development and lots of documentation and examples left to create.
Project Ad-Venture is all the work Can has been doing, creating a unified API for communicating with all of the major Ad Networks out there.
Project Giftwrap allows you to launch Phaser Editor (or a page on our new site), hit 'publish, and get a cloud-built Android APK or Windows EXE or similar back again, all wrapped and bundled for you.
Project Catnip is the process of upgrading the entire Phaser codebase to ES6 and ESM. This will form the basis of our Phaser v4 release.
Project Lucifer is all of the work Ben is doing upgrading the WebGL Renderer, and eventually moving onto WebGPU.
Plus, there's lots more going on I can't quite yet talk about. Hopefully, what you can see here is the bigger picture building up whereby we offer you the full development lifecycle. Start with a template that is most comfortable for you (React? Svelte? No problem!), bring it into Phaser Editor, save it to your project space on our site, and when you're ready, publish it to a mobile or desktop app or maybe to any of the 10 major Playable Ad Networks we support. The idea is that everything is interconnected, and you don't suddenly hit a point where we say to you, "No, go research and do that bit yourself." Phaser Studio is starting its third month of operation as I write this, and we've already achieved a lot. There's more to go, of course, but it's going to be an exciting year for sure.
I received an email from a long-time Phaser developer, which I felt was worth answering here for everyone's benefit. This is mostly relevant to those of you who have followed Phaser for a few years, but hopefully, it clears things up.
The email asked: Is Phaser 3 end of life, and what happened to all the work that was done on Phaser 4?
I spent a lot of time during 2021/2022 working on Phaser 4 and writing about the progress in my Dev Logs. There were plenty of examples and sample code, and I was excited by the direction in which it was taking. However, it was never production ready. Not even close. I wouldn't even class it as Beta level. It was a complete rewrite from scratch. Every single thing about it was new and un-tested. Why? Because that's what developers do, isn't it? Starting a fresh project is like having infinite possibilities stretching out before you. It's exciting. After almost a decade of working on Phaser, I needed to start over again for my own sake. To try and right some of the corners I had painted myself into with the Phaser 3 structure.
Yet the one thing I didn't do back then was ask anyone if this was a good idea or not. I never really factored in what the thousands of people using Phaser actually wanted. Make no mistake, there were (and still are) whole companies formed around developing with it. Teams trained on it. Thousands of products were created with it.
Had I stopped to think and talk, I would have quickly realized what most people wanted wasn't to have to re-learn everything again from scratch and fight with potentially hundreds of unknown bugs in an un-tested framework. It was simply to resolve the bigger issues in the current one.
It took me a while but I did come to understand this. That is what all of the work on the v3.60 release was for. It was my way of righting most of the wrongs and addressing the big-ticket items in v3 that needed sorting. People were very happy with v3.60, so I carried on with more updates and moved over lots of the knowledge I had gained in the v4 R\&D to v3.70. Even after this release, however, I still fully anticipated moving back to Phaser 4.
Then I met OCV, and together, we created Phaser Studio. And this changed everything. For a start, I no longer have to do everything on my own! We literally have someone whose sole job is upgrading Phaser 3 to a modern codebase. We have someone who can spend all of his time deep-diving into the guts of WebGL and ensuring we stay fast and performant. We've got Arian and his superb Phaser Editor to bring visual tools to those who need them.
It took me quite a while to realize that Phaser 3 was not at the end of its life. It's a solid, battle-tested, and very capable framework. Yes, it needs modernizing from the internals and build point of view, but that is literally happening as I type this. We closed off hundreds of bugs and issues in the recent 3.80 release. Ben is pushing the renderer into superb new realms and the rest of the team are ensuring the whole ecosystem around Phaser grows along with it.
We still have a decision to make about version numbers. The ES6/ESM version will almost certainly be our 4.0.0 release. The "old" 2021 Phaser 4 has been put on ice, and the repo set to Private. There are no plans to re-open it. I feel that now, with our team in place, we can easily migrate the more important core concepts I explored into the current version of Phaser, so everyone can benefit without having to start over from scratch.
When Phaser Studio changes into its next form in 2025, we will look at implementing 3D, WebGPU, and other features by evolving the framework, not replacing it. No more throwing the baby out with the bath water. Evolution is the key.