Blog

Above: "Hungry Hamster' running on the Windows Store simulator

In follow up to our test port to BlackBerry Playbook, we decided to also try out Microsoft's Windows Store. Targeting Windows Store gets you onto Windows RT, the Windows 8 Store and close to Windows 8 Phone.

The tool chain and APIs are as expected, of very high quality. Visual Studio Express is free and all you need, although the quite expensive Professional version includes valuable features such as graphics debugging (formerly PIX). Not only is C++ is supported, it has some powerful new features such as automatic reference counting, simple job management and lambdas (closures). The 3D graphics API is DirectX 11 and there is a powerful set of APIs for audios. Most of the standard C runtime is available, including standard file IO (with some limitations). Documentation, white papers, tutorials, etc. are all excellent.

For the test port, we used the same code base used on Playbook. In general the port was quite straightforward, however to took more than twice the time as the port to Playbook. Converting from OpenGL to DirectX 11 was the largest effort. DirectX 11 is an very capable API that maps well onto modern graphics hardware, however for simple rendering such as we had, DX11 requires much more code and is far less forgiving. Visual Studio Professional's Graphics Debugger is highly recommended.

Overall, the experience was very good. The robustness and quality of the tool chain goes a long way towards mitigating any negatives over the effort required for graphics conversion.

Scitech recently released a timelapse video of the installation of their Science Fiction, Science Future exhibition. Fun stuff. We contributed to the augmented reality portion of the exhibit.

Above: "Hungry Hamster' running on a BlackBerry Playbook and iPhone 4S

A while back we heard of RIM having a new software platform that was very easy to develop for and, especially relevant to us, easy to port to from iOS. We contacted someone we knew at RIM and were promptly provided with one of their Playbook tablets. Impressive given that we didn't even have a potential title at the time. The hardware has a high quality feel and as we have since discovered, the Playbook and BB10 phones perform very well compared to most other non-Apple devices¹. We were keen to see what it was like to work with.

BlackBerry's QNX based Native platform has actually been available for the Playbook tablet for some time. However it is new to the BlackBerry 10 phones that will ship in early 2013. QNX Neutrino RTOS is an embedded Unix-like OS typically used in mission critical systems. In practice, this provides a very efficient, stable foundation - unusual for first versions of software in the consumer space. On top of this, RIM have added a complete and simple to use set of services required by games such as OpenGL, OpenAL, streamed media playback and system messages for input, application switching, etc. The API's are all in C and are generally minimalist in nature. All API's are documented and there are a decent set of samples also. For anyone with a mostly C/C++ game engine, the Native platform will be hard not to like.

RIM also provide as part of their Native SDK an Eclipse based IDE providing all the usual integrated building, signing, packaging, deployment and debugging capabilities. Device simulators are also available and require VMWare Player to run. PC and Mac are both supported. The IDE and simulators are both satisfactory, however at the current time, are not as polished or reliable as those from Apple or Microsoft. Visual Studio integration has also been recently released which we have not tried.

To feel out new platforms, we like to perform a test port. In our early years we used Quake (see here and here).The Quake code is cleanly laid out with multiple platform support in mind and so is generally easy to port. However a couple of years ago one of us had been experimenting with a 2D game engine for iOS, in part because of a request from his daughter to "help make an app", and in part to experiment with a number of architectural ideas. The code base was written to be very portable and so this time we used it for the test port. Port time to the Playbook was just 18 hours and about half of that was figuring out the best, clean way to place Eclipse and Xcode projects side by side - a one time learning experience. For a large, complex game with a typical amount of Apple specific calls, porting time is more likely to be two to three weeks.

As developers, it is important to have a choice of platforms. We think it would be great to have a choice with good hardware, a great software platform and a strong belief in games. Beyond that, in our experience RIM have been great folks to work with. For anyone with a strong selling title, we suggest looking into supporting BlackBerry 10. The time and/or financial investment will be small and the install base of the Playbook alone is likely to bring in a profit. But more importantly, you will be putting your support behind a solid platform.

1. Apple appear to be the king with respect to phone/tablet gaming performance by a very large margin. Even devices with the generation old A5 have better real world performance than any competitor we are aware of.

This post is originally from 2003 when we created a test port of Quake for the original Xbox. At the time the post was only made available to a few folks so we are reproducing it here:

Above are a few screen shots. Nothing really new there but Xbox's antialiasing and texture filtering are pretty sweet.

Above is the first and easiest experiment. Quake uses a sine perturbation to create a swirling motion for water, slip gates, etc. The water texture has been replaced with a grid texture to highlight the effect for the still screen shot. On the left of the composite image is the original GL Quake per vertex effect. On the right is the Xbox enhanced version, a pixel shader using dependent texture reads. Ironically, the algorithm is based on the one used by the software rendered version of Quake.

Implicit quadratic bezier patches for real time mesh smoothing (n-patches but different). Generating patches on the fly from ordinary triangle data and implemented in a vertex shader. These trivial to use primitives are suitable for very memory efficient mesh representations and getting more out of existing mesh assets. Performance currently peaks at around 18 million tris/second.

The left image shows a dog rendered with normal triangles. Center is the smoothed model rendered with patches. The right images show how a mesh created to light well also smoothes well (the armour) whereas one which is not lit accurately is smoothed incorrectly (the nail gun).

As it turns out, n-patches (cubic) aren't a great deal more expensive than quadratic when everything is implemented in the vertex shader. You can see that the dog is smoother in places, particularly along the hind legs.

After much work between projects, our new site is live.