If it seems I've been quiet recently, that's because I've had my head down pummelling away at Project Blue Comb. There's a blog post coming on that later, but as always there's just one more thing I simply must add before it's ready to be seen.

However, I couldn't see a new platform being launched without porting Ancient Frog to it. Windows 8 is a pretty radical reboot of the franchise (consult the internet to hear what a brilliant / terrible idea that is). I was keen to jump in and see what it's like to develop for.

It's already live on the Windows store here so if you're giving the Windows 8 preview a go, grab it now!

 

Metro

I got Ancient Frog working pretty quickly (it's very malleable by now, and all the early work on resolution / aspect ratio independence, and the later work on up-rezzing, have paid off well). There were a few things I did to make it sit better with the new Windows style (previously called "Metro").

I finally updated the level choosing interface, which was a weak point from the beginning. Reworking that to the Windows tile grid worked out very well - it's not just that it makes it consistent with the rest of the platform; the tile system provides a very simple set of rules for laying out UI effectively.

 

I changed some of the in game UI to use charms & swiping. Hints, undo/redo, volume and so on are now summoned up in the Windows manner. I was a little more wary of doing this - a game is, by its nature, its own UI. I'm not sure whether consistency with the platform is more or less potentially confusing than consistency with the game's own world. However, the end result does seem to be improved by doing things Windows' way (it's not as if the original mishmash of buttons placed wherever they would fit was some precious jewel).

 

The feature I really like is snapping. In Windows 8, you can drag an app to the side of the screen, to run side-by-side with another app. It's a nice compromise between the simplicity / restrictiveness of full screen apps, and the power / mess of layered windows. On a tablet, where managing windows with a finger is pretty awkward, it's particularly welcome. The really clever part is that the snapped application is 320 pixels wide - the (logical) width of a smartphone app. So if you're building a Windows 8 app, you're encouraged to implement a smartphone-usable view of it right alongside your tablet / desktop view. I'm assuming Microsoft is hoping that this will stop them falling into the hole that Android tablets have ended up in, where developers are encouraged to write one app for all form factors. Without carefully tailoring the experience to the device size, you end up with some pretty odd layouts of varying usability. 

  

I have (of course) already built separate phone and tablet versions of Ancient Frog. For the Windows 8 port, these had to be combined so that it could switch between them based on window size. This was a little more complicated than adding the phone assets to the build. For a start, 320 pixels is just the width - the height is whatever height the user's monitor is, so the aspect ratio can easily go beyond the limits of the phone version's background textures. The desktop / tablet version is much more flexible in how it can be laid out, but assumes more space around the board for the frog to breathe. I had to change the camera to zoom in as close as the current puzzle allows, and rearrange UI elements to get out of the way vertically. The end result is that the big screen version can now reformat itself right down to the small screen layout, and beyond into crazy stretched territory.

 

The Port

Given that Ancient Frog was developed primarily on a Windows PC, and for most of its development was intended for release only on Windows, it's a little odd that this port ended up involving the most work. This is because Windows 8 has introduced some important changes. The new style of applications need to be built on WinRT to be eligible for the Windows store. (That's "WinRT" - Windows RunTime - not to be confused with "Windows RT", which is the ARM edition of Windows 8.)

Porting Ancient Frog to a new platform has always been pretty simple to kick off - create a new project in that platform's development environment (ideally using a '3D app' template or simple sample), add all the Frog source files to it, and call Frog's Draw() from the sample's render loop. This is how I started the Windows 8 port, and moving from the creaky old Win32 initialisation & game loop to the nice modern XAML setup was pretty painless. There's just one gotcha - there's no OpenGL in WinRT.

This is the first port I've done which didn't use OpenGL. It's been a while since I've even used DirectX, so I wasn't sure, when I started working on it, how much work would be involved and whether it would be worth the effort. My assumption was that, since both APIs exist to communicate with the same 3D hardware with largely the same constraints, there would probably be a pretty simple mapping from one to the other so how hard could it be?

OpenGL calls all go through my own layer which handles all the messy platform specific setup stuff (setting up contexts, getting function pointers for extensions and so on). It also handles the bits that were removed from OpenGL ES 2.0 (all the matrix operations). For the D3D version I continued this approach, removing all the rest of the actual OpenGL calls from the back end. The game code and data remain unchanged, and the draw stuff is translated into D3D on the fly. I drew the line at shaders - automatically converting GLSL to HLSL was more work than my handful of shaders warrants, so I just rewrote them manually.

I was up and running very quickly, but various problems became apparent as I worked through the rest of the port. Problems with some early 3D drivers made me wary about relying on modifying D3D's rasterizer state, so I reorder vertices as I pass them through, rather than changing the cull mode. The biggest problem was performance - it worked fine on a normal desktop PC (it's never been a game for pushing the boundaries of the hardware), but when I tried it on ARM it ground to a halt. I wasn't too worried at first - the iPad port took a bit of massaging to get up to speed, and I thought I could simply reuse the work I'd done there (reducing some of the scene complexity and baking in the lighting to reduce fillrate). Performance improved, but was still not acceptable (and still nowhere near what the hardware was capable of).

There is a simple two step process for speeding up rendering:

1 - draw less stuff

2 - batch everything that is drawn

I'd covered step 1, so I had a closer look at step 2. The obvious candidates were already well batched (text, for instance, all goes off in a single call). However, the frog itself isn't. Rendering the articulated character was pretty much the first piece of code I wrote for the first prototype of what turned into Ancient Frog, and it's implemented very naively. Each movable part (torso, eyes, leg segments, toes) is a separate quad, and I'm setting up a matrix for each one to scale, rotate and translate it into position. Now, that's only 32 quads (and another 32 for the shadow), and it's never given me trouble on the low powered devices I've used before, but I'd run out of stuff to draw less of. I still wanted to do it all on the back end, so I reordered my D3D code to hold off issuing any draw calls until forced to by a state change, and moved the transform from the vertex shader onto the CPU at the point where I'm copying the vertices over to D3D.

This fixed the problem completely - ARM performance went straight up to where I'd expected it to be from the start.

 

Buy Ancient Frog. Buy it.

 

Anyway, here it is. Available in 32-bit & 64-bit Intel versions, and a spiffy new ARM version all ready for when Windows RT devices actually exist.