XNA Game Studio on Windows Phone

XNA Game Studio on Windows Phone

  • Comments 25

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:

  • At launch, all phones will have a 480x800 (WVGA) display resolution, but we will add 320x480 (HVGA) in a future update. Of course you can detect the native resolution and program your game to adapt to this if you want, but the scaler allows games to pick just one resolution, always render at that fixed size, and still run correctly on phones with different native screen sizes. For bonus points, we automatically scale touch input to match your chosen resolution. 

  • 480x800 is a lot of pixels! This is a great resolution for displaying text, browsing the web, etc, but it can be a challenge for intensive 3D games to render so much data at a good framerate. To boost performance, some games may prefer to render at a lower resolution, then scale up to fill the display.

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.

  • Hey Shawn, great work. Really excited to build games using GS4.0 & XNA. Is there anything you can share with the actual size of your teams and how long it took for you to get to this point? Just interested is all!

  • Can you explain why Twitter app for ZuneHD has access to network, but you cannot access if you use .Net/XNA? Is this on purpose or .Net just doesn't support network connections? Zune is WinCE so can we use C++ to solve this problem of yours ourselves?

  • I've never been one for conferences, but all this great news is making me very grumpy about not being at the GDC right this instant :)

    Thanks for finding time to answer my question on your previous post, I'm glad I can continue my tinkering without worrying about it becoming obsolete. I was wondering, will the phone hardware actually be powerful enough to extensively use the typical skinned characters we'd use on the PC/XBox?

    I guess it just sounds to good to be true. Performance on my poor HTC Touch HD already crumbled when I tried alpha blending in GDI :)

  • Just want to say thanks for making all that complicated stuff "go away". Sometimes I like magic!

    Looking forward to making my next game for the wp7, XBox 360, and Windows.

    -Jeff Weber

  • "The phone supports full hardware accelerated 3D, but we are not exposing programmable shaders in this release." - Boo! :-(

  • this is very nice , but

    no programmable shaders , does this meen no custrom shaders

    and paraticle effect , like smoke , fire , explotions are not possible

    or not exposed at the moment , and will be exposed later,

    or do we have to have a Xbox Live contract with Microsoft to get acess to custrom shaders

    Best Regards

    Michael

  • @Michael: Just because there are no programmable shaders this release doesn't mean you can't do particle effects.  It's really no different than developing for the PC and using just BasicEffect (and the other new ones that have been added).  It's still quite possible to do particle systems using BasicEffect.

    By the sound of things, programmable shaders for the mobile devices could possibly come in a future release.

  • Hi Shawn, excellent stuff!

    I have a quick question though: has there been any work done on optimising the .NET CF CLR floating point operations for Windows Phone 7?

    Cheers!

  • > has there been any work done on optimising the .NET CF CLR floating point operations for Windows Phone 7?

    I think you'll be happy with the performance of managed code on the phone.

  • tanks JoelBennett for clear that up

    ,but i wood allso like to bloom the final renderscene in a post process

    or pehaps the new shaders will give acess to the depthbuffer so we can do some shadow mapping

    if the new api and the new shaders will give that and we only have to do post process at the end ,,this is a verry cool and easy framework,, now we can focus on high speed game developerment

  • "For bonus points, we automatically scale touch input to match your chosen resolution."

    Man, and those kind of things /are/ bonus points. This project really is a helpful API in the truest sense. :)

    I am very glad to hear that you have said no things like custom shaders on the phone for now with the intent of keeping a smaller feature set at a higher quality level. And, like everyone else, will be very excited to see them come into play in future versions! :)

  • Ugh.  I don't like saying this, but way to drop the ball on this one.  Custom shaders are a necessity to develop high performance 3d games, especially if you are on a resource limited platform like a phone.  It is something Apple realized fairly quickly, hence their addition to Apple's products.  Custom shaders allow us to optimize lighting calculations and only include the parts of the lighting model that we actually use (unlike BasicEffect), as well as implement lighting models that you did not include in BasicEffect and its new siblings.  We all know this is neither a hardware imposed limitation, nor a API design imposed limitation; after all, BasicEffect is itself a shader.  So, is it that all of the indies get stuck with an API that attempts to emulate a fixed function pipeline in shaders, while the big dollars get to write their own?  And the lack of full multiplayer is rather unfortunate.  If these capabilities were all brand new, that would be one thing.  However, these capabilities are in previous versions of XNA and on other mobile platforms.  I am disappointed; I was expecting XNA and what we have seen so far is "XNA Framework Compact Edition."

  • > We all know this is neither a hardware imposed limitation, nor a API design imposed limitation; after all, BasicEffect is itself a shader.

    It's primarily a time limitation, which has complex ramifications for how thoroughly we can test this brand new graphics stack and driver, how robust a product we are able to ship, and what sort of compatibility guarantees we will be able to offer as new hardware devices appear on the market.

    All things are possible given infinite time, but when time is finite, we have to make hard choices about priorities and where to focus our efforts to give developers the most possible bang for buck.

    > So, is it that all of the indies get stuck with an API that attempts to emulate a fixed function pipeline in shaders, while the big dollars get to write their own?

    The graphics feature set is identical for indies and pro developers.

  • > It's primarily a time limitation, which has complex ramifications for how thoroughly we can test this brand new graphics stack and driver, how robust a product we are able to ship, and what sort of compatibility guarantees we will be able to offer as new hardware devices appear on the market.

    I am trying to digest this.  Is the reason for this along the lines of you do not want to, at this early stage of the driver stack's lifetime, have to try to deal with recovering from buggy shader code?  I know shader code is not managed, but I am not aware of any specific way one can crash a system from bad shader code, beyond an invalid or unsupported operation.  Maybe I just have not tried hard enough.  Seriously though, I am trying to see this from your perspective, not just rant.

    I know you probably will talk about this more later, but is the goal to pick up missing features in future updates?  Or will this be impossible with the compatibility guarantees in the hardware platform?  Having clarity as to where the platform is going is just as important as knowing where the platform is now.  Maybe my ideas will not work on WP7S at release, but if it will 6 months after that, that would be a reasonable trade off (no, I am not asking for you to confirm a 6 month time frame :-).

    > The graphics feature set is identical for indies and pro developers.

    That is nice to hear.  You can understand how frustrating it would be if that was not the case, and when you see the hardware capability is available, it does tend to make one suspicious.  Hence the question.  My apologies if I was a little over the top.

  • > Is the reason for this along the lines of you do not want to, at this early stage of the driver stack's lifetime, have to try to deal with recovering from buggy shader code?

    It's more of a correctness thing than a security issue. Supporting arbitrary shaders adds a ton of complexity to the graphics stack. All of that code has to be written, and tested, and then compliance test suites created to make sure any future changes do not accidentally break compatibility. Fully testing an arbitrary programming language is several orders of magnitude harder than if we are able to constrain the problem space by limiting the possible input values.

    When presented with a schedule that does not fit the timeframe, there are really only a few options:

    - Cut features until it does fit. This is what we chose to do by not supporting programmable shaders in this first release.

    - Postpone or cancel the entire project. We could have decided not to support XNA at all for the first release of the phone, or to only support 2D SpriteBatch like on Zune. That would have made the schedule fit for sure, but seems much further from ideal than what we decided to do!

    - Ignore the fact that it is incomplete, and go ahead and ship something that is known to be buggy and not fully tested. In V1, you guys could no doubt work around whatever bugs there turned out to be. But what does this do to the longer term robustness of the platform? To keep V1 games running on future phones, we would have to forever maintain bug-for-bug compatibility with that first unfinished implementation. That's not a place I ever want to be.

    Better to do less stuff now, then more stuff in the future, making sure we have time to do it all properly and without silly mistakes.

    > is the goal to pick up missing features in future updates?

    Speaking personally, I would obviously love to add all the features I think are important. I definately think programmable shaders are useful and important.

    Officially, no comment. We don't have any concrete plans about future versions yet - we're more than busy enough trying to get this first release finished up!

Page 1 of 2 (25 items) 12
Leave a Comment
  • Please add 3 and 8 and type the answer here:
  • Post