3D Line Rendering with the Graphics API
This week saw me merge even more Pull Requests into Phaser CE. From small fixes to some Math functions, to emitter updates and TypeScript defs patches. It's great to see it continue to be supported.
I also enabled GitHub pages on the Phaser CE docs folder (thanks to DaxChen for the suggestion). this means you can now browse the latest Phaser CE docs online, without having to clone the repo first. I've also made clear links to this from the main Phaser site. A lot of you thought that because the docs weren't listed on the Phaser site that CE didn't have any, which has never been the case - it's always had them! Now they're just a lot easier to find.
Keep it simple and sexy
Back in the land of Phaser 3 Felipe spent this week finishing off his updates to the Graphics API and also the WebGL BitmapText batched renderer. We made the decision a while ago that the core Game Objects should be as sleek and minimal as possible. When we find ourselves straying from this (which is quite easy to do), we have to rethink the approach. That is what we did at the start of the week with the BitmapText.
Last week I explained about the callback feature we'd enabled, allowing you to do some really neat per-character effects, such as scaling or rotating individual glyphs. However this feature meant that we could no longer use our really fast blitter renderer for text, because each glyph could potentially need to be transformed, and the blitter batch works on the basis of pure texture transfer, with no transformation stack slowing it down. So we decided to split it up into two classes, the core BitmapText class and a new DynamicBitmapText class. If you just need really fast text with nothing fancy, you can use the core one. Want to go all PS1 menu screen on your game? Then Dynamic is for you.
This is a concept we will continue to use as we expand the range of Game Objects.
Let's 3D like it's 1999
Last week I explained how Felipe was working on the WebGL Graphics API, and early this week he completed his line renderer and pushed up all the changes. I was keen to see how far it could be pushed, so started making a few tests.
You know how you get caught up in something, that is related to what you should be doing, but is just so much fun you end up spending a little too much time on it and getting carried away? I think it's fair to say that happened to me this week. I figured that a good test of a Graphics line fill routine would be some good old-fashioned 3D wireframe objects. So I dusted off some old code, did a bit of googling, and soon had a 3D spinning cube up.
Click the images to run the examples in browser.
Neat, but hardly a stress test with such few lines. So I did a bit more reading and figured out that the Wavefront obj file format is fundamentally really easy to parse, being plain text and cleanly formatted. So I borrowed a bit of code, made a few adaptions, and voila.. soon we had the classic teapot rendering:
Now that's more like it! 6320 faces and 3644 vertices. And remember this is all being done with nothing more than Graphics.moveTo and Graphics.lineTo (and some math of course).
Feeling buoyed at how many lines the new renderer could push I started to get delusions of grandeur, and figured it would be fun to create a full scene from it. So I spoke to Ilija and asked him to create me some low poly objects that would look good as wireframes. I then modified the Wavefront parser to handle quads as well as tris (the teapot is pure tris, but the new objects needed quad support), and created a new test with 4 objects on the go at once:
And then I figured a 3D camera was in order. I know I shouldn't have, it was already getting into the small hours of the morning, but I was coding on the kind of adrenalin that only comes when you do something and it bloody well works. I found some great tutorials written by David Rousset, one of the main developers of Babylon.js. In it he goes through the paces of creating a software 3D renderer. I didn't need all of it (his series goes into filled faces and lighting), but I did nick their math library and 3D camera, adapting it for my needs. Empowered by the neat camera, and new objects from Ilija, I threw it all together in the way that can only be done when you're firing on early morning coffee, and this is what fell out the other end:
A zooming and panning camera, bouncey rotating bevelled cubes, spinning old school PC and even fading and changing shapes on the screen. Leave it running for a bit and you'll see new objects appear.
It serves little actual purpose beyond being a damn good thrashing of the Graphics API, but it was really fun to make, and sometimes you just need that when you're as deep in a project as we are with Phaser 3. It also made me realise that although there is still a lot to do, Phaser 3 is getting more and more stable every day.
This experiment also made me decide that next week we'll both do our usual development work, but we'll also take 2 days out to create a game each. Nothing too big or complex, as it has to be finished within 2 days, but I honestly feel it will be a really good test to show us where there are gaps in the current API. So hopefully this time next week we'll have something for you to actually play, as well as a clearer idea of what to prioritise. Exciting stuff!
Phaser 3 Mailing List and Developers Guide
If you're interested in helping evolve the shape of Phaser 3, then please join the Phaser 3 Google Group. Discussions this week have included varying render loops. The group is for anyone who wishes to help shape what the Phaser 3 API and feature-set will contain.
The Phaser 3 Developers Guide is available. Essential reading for anyone who'd like to help build Phaser 3.
This week saw me merge even more Pull Requests into Phaser CE. From small fixes to some Math functions, to emitter updates and TypeScript defs patches. It's great to see it continue to be supported.
I also enabled GitHub pages on the Phaser CE docs folder (thanks to DaxChen for the suggestion). this means you can now browse the latest Phaser CE docs online, without having to clone the repo first. I've also made clear links to this from the main Phaser site. A lot of you thought that because the docs weren't listed on the Phaser site that CE didn't have any, which has never been the case - it's always had them! Now they're just a lot easier to find.
Keep it simple and sexy
Back in the land of Phaser 3 Felipe spent this week finishing off his updates to the Graphics API and also the WebGL BitmapText batched renderer. We made the decision a while ago that the core Game Objects should be as sleek and minimal as possible. When we find ourselves straying from this (which is quite easy to do), we have to rethink the approach. That is what we did at the start of the week with the BitmapText.
Last week I explained about the callback feature we'd enabled, allowing you to do some really neat per-character effects, such as scaling or rotating individual glyphs. However this feature meant that we could no longer use our really fast blitter renderer for text, because each glyph could potentially need to be transformed, and the blitter batch works on the basis of pure texture transfer, with no transformation stack slowing it down. So we decided to split it up into two classes, the core BitmapText class and a new DynamicBitmapText class. If you just need really fast text with nothing fancy, you can use the core one. Want to go all PS1 menu screen on your game? Then Dynamic is for you.
This is a concept we will continue to use as we expand the range of Game Objects.
Let's 3D like it's 1999
Last week I explained how Felipe was working on the WebGL Graphics API, and early this week he completed his line renderer and pushed up all the changes. I was keen to see how far it could be pushed, so started making a few tests.
You know how you get caught up in something, that is related to what you should be doing, but is just so much fun you end up spending a little too much time on it and getting carried away? I think it's fair to say that happened to me this week. I figured that a good test of a Graphics line fill routine would be some good old-fashioned 3D wireframe objects. So I dusted off some old code, did a bit of googling, and soon had a 3D spinning cube up.
Click the images to run the examples in browser.
Neat, but hardly a stress test with such few lines. So I did a bit more reading and figured out that the Wavefront obj file format is fundamentally really easy to parse, being plain text and cleanly formatted. So I borrowed a bit of code, made a few adaptions, and voila.. soon we had the classic teapot rendering:
Now that's more like it! 6320 faces and 3644 vertices. And remember this is all being done with nothing more than Graphics.moveTo and Graphics.lineTo (and some math of course).
Feeling buoyed at how many lines the new renderer could push I started to get delusions of grandeur, and figured it would be fun to create a full scene from it. So I spoke to Ilija and asked him to create me some low poly objects that would look good as wireframes. I then modified the Wavefront parser to handle quads as well as tris (the teapot is pure tris, but the new objects needed quad support), and created a new test with 4 objects on the go at once:
And then I figured a 3D camera was in order. I know I shouldn't have, it was already getting into the small hours of the morning, but I was coding on the kind of adrenalin that only comes when you do something and it bloody well works. I found some great tutorials written by David Rousset, one of the main developers of Babylon.js. In it he goes through the paces of creating a software 3D renderer. I didn't need all of it (his series goes into filled faces and lighting), but I did nick their math library and 3D camera, adapting it for my needs. Empowered by the neat camera, and new objects from Ilija, I threw it all together in the way that can only be done when you're firing on early morning coffee, and this is what fell out the other end:
A zooming and panning camera, bouncey rotating bevelled cubes, spinning old school PC and even fading and changing shapes on the screen. Leave it running for a bit and you'll see new objects appear.
It serves little actual purpose beyond being a damn good thrashing of the Graphics API, but it was really fun to make, and sometimes you just need that when you're as deep in a project as we are with Phaser 3. It also made me realise that although there is still a lot to do, Phaser 3 is getting more and more stable every day.
This experiment also made me decide that next week we'll both do our usual development work, but we'll also take 2 days out to create a game each. Nothing too big or complex, as it has to be finished within 2 days, but I honestly feel it will be a really good test to show us where there are gaps in the current API. So hopefully this time next week we'll have something for you to actually play, as well as a clearer idea of what to prioritise. Exciting stuff!
Phaser 3 Mailing List and Developers Guide
If you're interested in helping evolve the shape of Phaser 3, then please join the Phaser 3 Google Group. Discussions this week have included varying render loops. The group is for anyone who wishes to help shape what the Phaser 3 API and feature-set will contain.
The Phaser 3 Developers Guide is available. Essential reading for anyone who'd like to help build Phaser 3.