I set out to write an article about the unique features of XNA Game Studio on Windows Phone 7 Series, but while trying to populate my outline, I realized, wow, there actually aren’t many things different about Game Studio 4.0 on the phone compared to Windows and Xbox 360! That’s bad news for this article, but I think good news for our platform as a whole. With Game Studio 4.0, we made a concerted effort to increase portability and consistency across our target platforms.
In some areas it was obvious how to achieve consistency. For instance, Windows Phone 7 Series includes a Zune media client, so we could port our existing Zune media APIs. Input is similarly straightforward. If you only want to access a single touch point, you can use our existing Mouse API. If you need multitouch (the phone supports four simultaneous touches), you can use an API similar to what we previously shipped for Zune HD. This touch API works on Windows 7 PCs with multitouch displays, too.
Other areas, especially graphics, were more challenging to design. Had we just ported the Game Studio 3.1 graphics API, we would have been left with a confusing mess of non-overlapping caps that would make it hard to port code between Windows, Xbox, and the phone. But we didn’t want to force a lowest common denominator approach: it would make no sense to limit Xbox 360 games to only those features which are also available on mobile hardware!
Our solution was to take a long, hard look at our graphics API, tweaking, polishing, and refactoring to increase consistency wherever possible, and relying on a coarse bucketing of features into Reach and HiDef profiles for things that just weren’t possible on the phone. I am tremendously proud of the results. This tuning is valuable even for developers who are not targeting the phone, as it fixes common causes of error on all platforms, and helps make your game compatible across different Windows graphics cards.
The phone supports full hardware accelerated 3D, but we are not exposing programmable shaders in this release. Charlie Kindel summed up the reason for that in a great article about focus and priorities:
“We will do a few things and do them very, very well; we are better off not having a capability than doing it poorly. There are always future versions.”
Instead of programmable shaders, we augmented the existing BasicEffect with four new configurable effects: SkinnedEffect, EnvironmentMapEffect, DualTextureEffect, and AlphaTestEffect. These are designed to run efficiently on the mobile GPU hardware, and I think do a good job of providing enough flexibility for developers to create awesome looking games, while also meeting our goals of being able to ship a robust and well tested product on schedule.
The phone features an image scaler which allows games to render to any size backbuffer they like, and have it automatically stretched to fill the display, with black bars along the edges if the backbuffer and display have different aspect ratios (an idea that will be familiar to Xbox developers). This scaling is handled by dedicated hardware, so does not consume any GPU resources, and it uses a high quality image filter that gives much better results than bilinear filtering like you would get if you did this yourself on the GPU. The scaler is important for two reasons:
We also implemented an automatic rotation feature, so (unlike Zune) you don’t have to write special code to handle portrait, landscape left, and landscape right modes. Just tell us which way up you want to be, and we’ll adjust your graphics rendering and touch input accordingly. This is implemented via special magic in the graphics driver, so there is no performance penalty from choosing a rotated orientation.
When I think about Game Studio on the phone, a recurring theme is that we did a lot of furious padding beneath the water, in order to ship an API that glides smoothly over the surface of the lake. Quoting Charlie Kindel again:
“We will build on the shoulders of giants; where possible integrate instead of create.”
(that’s XNA he is talking about there! He called XNA a giant!!! tee hee… :-)
In addition to the XNA Framework itself, we integrated existing pieces of awesomeness such as the Direct3D runtime from Windows. But there were also many places where we had to build large and complex things from scratch. For instance, in cooperation with our hardware partners we created an entirely new graphics driver stack, optimized from the ground up for mobile GPU hardware. The strange thing for me is that, while I plan on writing many articles about the API improvements and new features, I probably won’t be talking much about the hard implementation problems I have been working on this last year. Our goal was not only to solve these problems, but to make them go away so thoroughly our customers need never know they existed in the first place.
Did we succeed? Ultimately, you will be the judge of that.
I had a great experience yesterday, working on the demo for my GDC talk. I coded most of it last Thursday, using our Windows framework, with mouse input to switch between the five built-in effects. When I moved this code over to the phone, it “just worked” the first time I tried it on an actual device. Yesterday I found myself with a couple more spare hours, but I had the wrong build on my phone at the time, so I went back to the Windows version of the demo, blinging it up with rendertarget transition effects. Once again, this updated version ran exactly the same on the phone as it did on Windows, which made me feel pretty good!
I can’t wait to show my demo at GDC this week, and later on to show you all the things we have been building so you can try them out yourself.