Welcome to this week's Dev Log! We've been busy, adding in features across large parts of the API. Before I dive in I just wanted to say that Mozilla is meeting to discuss the v3 funding application today. So I'm extremely nervous but at the same time pumped because it's been a great week of dev work (as you'll see below). Internally I should know next week if our funding application was successful or not, but publically it'll be a little longer before I can announce it. Fingers crossed though, believe me!

RetroFonts Return

I added RetroFonts to Phaser 2 mostly because I really like using them in my own games and because they were a nice processing step-down from Bitmap Text, working more like sprite sheets and not needing any kerning data. I wanted them in v3 but they were a really low priority and more importantly I didn't want to clog up the API with yet another Game Object type just for them.

Then it occurred to me - they don't need to be their own type of Game Object at all. In fact, I could just write a simple parser that took a config object and image and converted it into the standard BitmapText that we had already implemented. So I bashed out a 'ParseRetroFont' function and voila, it works perfectly! You can define your font in an easy to read object, throw it into the cache and use it just like any other BitmapText. Have a look at the code in this example to see how it works.

Personally, I think the end result is a lot better than v2 because the BitmapText objects are much more powerful, and it works with both Static and Dynamic versions.

Scroll-line Massacre

While implementing the RetroFont I realised I could very easily add the ability to scroll the contents of a Dynamic BitmapText object. A few hours later and it worked nicely:

In the demo above the BitmapFont itself never actually changes x coordinate, it is the contents of it that are being scrolled via the new scrollX and scrollY properties. There is also the ability to crop the display, which allows you to do some fun stuff, like this:

Woo! That's a whole load of WebGL batched scroller goodness right there. Another feature I added this week was support for the pixelArt game configuration setting in both Canvas and WebGL. It's a boolean value and if you enable it then the GL and Canvas texture managers will automatically apply the correct scale-mode or texture filter required for lovely crisp pixel art, without you having to do anything else. It's a feature I wanted in v3 from the very start and this week it arrived :)

However, the biggest addition this week was nothing to do with text, but to do with Tilemaps.

Super Mario Level Scroller

Felipe pushed a whole stack of Tilemap renderer updates into v3 over the past couple of weeks. As I mentioned a few issues ago we've got two implementations: Static and Dynamic. Static is basically just a crazy-fast tile renderer. You feed it an image and an array of data and it gives you a slick and speedy tilemap. The map can be scrolled with the camera and positioned anywhere in the world, as you can see in this example:

Use the left / right cursors to scroll. What you're seeing are 2 completely independent tilemaps rendering. I offset the bottom one a little so you can see the positioning working. The maps are from Super Mario Bros on the NES (Worlds 1 and 3 respectively) and although simple due to the low volume of tiles, serve as good horizontal examples.

But, we can do more, right? I promised the tilemap renderer would be fast, so let's take it full-screen in a nice 30,000 tile example. Again, use the cursor keys to move around:

Sweeeeet, right?! So this is showcasing two things at once here. First, of course, the tilemap renderer. This is a Static tilemap which means you cannot do any per-tile effects (i.e. animating a tile, or setting its alpha, or removing it), for that you need a Dynamic Tilemap. But, if you've got 'standard' tilemap requirements, which I guess covers the majority of games, then this is the system you'd use.

The smooth cursor key scrolling is enabled by a new function available via the Camera Manager. Take a look at the code for it:

You give it a Key object for each direction you wish to be enabled (you can leave them out if you like) and then just set some speed values for acceleration and drag. And that's it! Call 'controls.update' in your update loop and it will take care of the rest. The full code for this example can be seen here, and I hope you agree that's pretty compact and easy to follow!

The Key Control functions for the camera are entirely optional and like the rest of v3 they live in their own single function files in the camera folder. So they're dead easy to replace with your own custom ones, or enhance, or just ignore entirely. This is the philosophy of avoiding 'God classes' in v3 at work and we're trying to stick to it everywhere.

Next week I hope to show you Dynamic Tilemaps. It's where things get really interesting because although it has to use a slower method of rendering, it's a lot more flexible allowing for per-tile effects and manipulation. Even so, Static Tilemaps are superb too and I can't wait to get them hooked to physics so you can start charging around them :)

Phaser 3 Labs

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. The group is for anyone who wishes to discuss what the Phaser 3 API will contain.