Blitter Batch and Sprite Batch Renderers
A short update this week, even though lots of work has taken place. I'll explain why in the Phaser 3 section:
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.
Phaser 3 Updates
Work this week has been split into two parts. We've been plugging away getting the new renderers slotted into the main v3 source (as opposed to sitting on their own, like last weeks test).
So far we've got the Blitter Batch and the Sprite Batch in place. The Blitter Batch is for rendering Blitter / Bob Game Objects. These are essentially just direct image frame transfers - no transform, no children - no effects, so they are insanely fast as a result.
The Sprite Batch is a general Sprite renderer. Even so, we've changed it significantly since the first iteration, and it will now calculate the transform matrix on the GPU, shifting a boatload of math away from the CPU. The Canvas renderer is now coming to life as well. I can't tell you how good it feels to finally have things rendering on-screen, and knowing it's doing so from the actual v3 source, and not a monkey-patched implementation we hung off the end for testing :)
What we're aiming for is to release a Beta 1 next week.
Let me be very clear here: This will be purely a test of the new renderers and State Manager. There will be lots missing. For example no mouse input, no scale manager, no physics, not even any tweens. So what's the point you ask? The reason is simple: It will be a 'minimum viable product' in the sense that you can still actually make games with it. It will include Keyboard input and all the rendering you need to actually make stuff move, and move fast. What we'll be looking at is getting it tested as widely as possible, so we can tweak and improve it (especially across mobile devices), before adding in more features.
Once we're happy we've got a rock solid sprite renderer and state system in place we'll drop a Beta 2 with another feature added (perhaps Bitmap Text, or Graphics) and continue the process. What I'd very much like to do is drop a new Beta once a week until all the key features are in, and we can head towards a Release Candidate. If that takes 20 beta versions, then so be it. Phaser 3 has taken long enough, I'm not going to rush to meet some arbitrary date.
So please keep reading, join the google group if you like, and look out because we're getting closer than ever before :)
A short update this week, even though lots of work has taken place. I'll explain why in the Phaser 3 section:
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.
Phaser 3 Updates
Work this week has been split into two parts. We've been plugging away getting the new renderers slotted into the main v3 source (as opposed to sitting on their own, like last weeks test).
So far we've got the Blitter Batch and the Sprite Batch in place. The Blitter Batch is for rendering Blitter / Bob Game Objects. These are essentially just direct image frame transfers - no transform, no children - no effects, so they are insanely fast as a result.
The Sprite Batch is a general Sprite renderer. Even so, we've changed it significantly since the first iteration, and it will now calculate the transform matrix on the GPU, shifting a boatload of math away from the CPU. The Canvas renderer is now coming to life as well. I can't tell you how good it feels to finally have things rendering on-screen, and knowing it's doing so from the actual v3 source, and not a monkey-patched implementation we hung off the end for testing :)
What we're aiming for is to release a Beta 1 next week.
Let me be very clear here: This will be purely a test of the new renderers and State Manager. There will be lots missing. For example no mouse input, no scale manager, no physics, not even any tweens. So what's the point you ask? The reason is simple: It will be a 'minimum viable product' in the sense that you can still actually make games with it. It will include Keyboard input and all the rendering you need to actually make stuff move, and move fast. What we'll be looking at is getting it tested as widely as possible, so we can tweak and improve it (especially across mobile devices), before adding in more features.
Once we're happy we've got a rock solid sprite renderer and state system in place we'll drop a Beta 2 with another feature added (perhaps Bitmap Text, or Graphics) and continue the process. What I'd very much like to do is drop a new Beta once a week until all the key features are in, and we can head towards a Release Candidate. If that takes 20 beta versions, then so be it. Phaser 3 has taken long enough, I'm not going to rush to meet some arbitrary date.
So please keep reading, join the google group if you like, and look out because we're getting closer than ever before :)