Geometry Classes and Bitmap Text Rendering

Published on 30th December 2016

image

It's been an interesting couple of weeks to say the least.

A few days after Issue 60 of the newsletter was published, I posted an in-depth article called The Evolution of Phaser 3 and Lazer. If you've ever been confused over what happened to Lazer, and what is Phaser 3, and how does it all fit together, then I urge you to read it. It answers everything.

The article went into detail about what has been happening since January 2015, right up to today, and ended with a big question: Should we drop the name Lazer or not? If you've read the Phaser 2016 Round-up then you'll know the answer, and if you haven't, and are interested, then I urge you to please do so. Long story short: Lazer is no more, and we'll continue using the name Phaser for as long as we can.

A number of you have expressed an interest in helping with Phaser 3 development. In order to facilitate this, and for my own sanity, I am currently compiling a comprehensive roadmap of what needs to be done. When it's ready I'll announce it here, and publish it for everyone to see. It should make it a lot easier for those who want to help, to actually do so.

Bits and Pieces

As we've been closed for Christmas there hasn't been much in the way of development over the past week. I did find time to carry on porting some classes over, and made a start with the Geometry classes. So we now have Rectangle and Circle back in the API, and all of their associated functions.

Unlike with Phaser 2 these objects are now much more light-weight. The core class consists of just the geometry data and a handful of important getters and setters. All of the functions, such as Circle.circumference, or Rectangle.union, are now their own modules, and not part of the geometry class itself.

This serves two purposes: It means if you want to compile your own build of Phaser, you can require just the geometry functions you need, not all of them. Plus it makes it a lot easier to test and document the modules in isolation.

The whole concept behind Lazer was always one of 'lego bricks' - build what you need, however you need it, and this is something we're making possible with the structural choices being made with Phaser 3. Yet there is no ignoring the popularity of the Phaser API being 'easy to use', so we will absolutely be providing 'pre built' bundles of the most common Phaser classes and functions, so you can consume just a single JS lib if you prefer. For those that want fine-grained control though, you now have it.

Things will be back in full flow next week. Felipe is tackling creating a new Bitmap Text renderer, and I'll carry on porting over essential functions, and working on the roadmap.

image

It's been an interesting couple of weeks to say the least.

A few days after Issue 60 of the newsletter was published, I posted an in-depth article called The Evolution of Phaser 3 and Lazer. If you've ever been confused over what happened to Lazer, and what is Phaser 3, and how does it all fit together, then I urge you to read it. It answers everything.

The article went into detail about what has been happening since January 2015, right up to today, and ended with a big question: Should we drop the name Lazer or not? If you've read the Phaser 2016 Round-up then you'll know the answer, and if you haven't, and are interested, then I urge you to please do so. Long story short: Lazer is no more, and we'll continue using the name Phaser for as long as we can.

A number of you have expressed an interest in helping with Phaser 3 development. In order to facilitate this, and for my own sanity, I am currently compiling a comprehensive roadmap of what needs to be done. When it's ready I'll announce it here, and publish it for everyone to see. It should make it a lot easier for those who want to help, to actually do so.

Bits and Pieces

As we've been closed for Christmas there hasn't been much in the way of development over the past week. I did find time to carry on porting some classes over, and made a start with the Geometry classes. So we now have Rectangle and Circle back in the API, and all of their associated functions.

Unlike with Phaser 2 these objects are now much more light-weight. The core class consists of just the geometry data and a handful of important getters and setters. All of the functions, such as Circle.circumference, or Rectangle.union, are now their own modules, and not part of the geometry class itself.

This serves two purposes: It means if you want to compile your own build of Phaser, you can require just the geometry functions you need, not all of them. Plus it makes it a lot easier to test and document the modules in isolation.

The whole concept behind Lazer was always one of 'lego bricks' - build what you need, however you need it, and this is something we're making possible with the structural choices being made with Phaser 3. Yet there is no ignoring the popularity of the Phaser API being 'easy to use', so we will absolutely be providing 'pre built' bundles of the most common Phaser classes and functions, so you can consume just a single JS lib if you prefer. For those that want fine-grained control though, you now have it.

Things will be back in full flow next week. Felipe is tackling creating a new Bitmap Text renderer, and I'll carry on porting over essential functions, and working on the roadmap.