Share via

XNA Week 1 Summary : What we've learned

  • Article

There's been a flurry of activity on the XNA forums and websites. Here's a brief summary of what we've learned.

  • The XNA Framework is supported for C# only. No C++, no VB, nor any other langs. Some of the restrictions were for time contraints (they want to focus on one language so they can get the product out the door). Non-managed languages will probably never be supported (for security reasons). To create native games for the 360, your only route is to fork out the big bucks and become a registered developer. ( ref )
  • The XNA Framework will replace the Managed DirectX (MDX) API. MDX 1.1 will be the last official release - 2.0 will never get out of beta. ( ref )
  • On Windows, the XNA Framework uses the .NET 2.0 runtime. For the 360, it is a custom runtime based on the .NET Compact Framework (CF). So, while you can use the full .NET runtime when you're on Windows, you'll need to limit yourself to the something like the CF if you want to be cross-platform. Note that one difference between the two frameworks is in how the Garbage Collector (GC) is implemented - the standard framework is a generational collector whereas the CF does not use generations. Rico Mariani had a great talk at Gamefest that talked about the differences between these two models. The slides and video from his talk have not been made available yet, but they should be soon. ( ref )
  • To run games on your 360, you need to join the XNA Creators Club, which will give you access to a custom XNA runtime that will allow games to run on the 360. This will cost $99 per year. ( ref )
  • To share games that you've written, you need to do one of two things: on Windows you can simply share the binaries; on the 360 you need to share your source code and have the other person compile them (which means that you can only share with other XNA Creators Club members). The situation on the 360 is (hopefully) temporary and they are looking into ways to release games as binaries. ( ref ref )
  • Shaders: All D3D9 shader models (SM1.1 - SM3.0) are available on Windows. The Xbox supports SM2.0 and an Xbox-specific variant of SM3.0. Thus, SM2.0 is recommended and most samples will require a graphics card that suppors SM2.0. SM4.0 (which is part of D3D10) is not supported on either platform. ( ref ref ref )

Things that will not be part of the initial XNA release:

  • No Xbox Live on either platform. No network support on the 360. However, this is a common request so they are investigating what it would take to include it in a future release. ( ref ref )
  • No fixed function pipeline. You must use programmable shaders. Note that the 360 doesn't support a fixed function pipeline, so even if it was made available as part of the XNA Framework, it would be a Windows-only feature.
  • No Middleware (like physics). However, the XNA team is standardizing a component model that middleware vendors can plug-in to. ( ref )

Comments

  • Anonymous
    August 20, 2006
    "The XNA Framework will replace the Managed DirectX (MDX) API. MDX 1.1 will be the last official release - 2.0 will never get out of beta. ( ref )"

    So it looks like managed code developers who were using MDX to do things other than games (e.g. CAD or some other non-game 3D software), are now out of luck...?

  • Anonymous
    August 21, 2006
    There's nothing really stopping you from using XNA for non-game projects, although there may be a few things that seem odd because of the deliberate bias to support games.  System.Windows.Forms will still be available on the Windows side.

    See the following thread in the forums:

    "Window management and Alt-Tab"
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=645247&SiteID=1

    According to this thread, there is a work item to create samples to show how to use XNA in a Windows.Forms application, although it won't make it in time for the 30 August beta.

  • Anonymous
    August 21, 2006
    The comment has been removed

  • Anonymous
    August 21, 2006
    garykac,

    I read through that thread.
    However, it does not answer the question.
    XNA should be executing CIL.
    I assume that the XNA framework is a bunch of DLL compiled down to CIL as well.
    At the CIL level, there is no C# or other language.
    Perhaps when you say "support C#", you mean only from within the IDE. That is something that I can understand.
    However, if a user is determined to manually compile and reference the appropriate DLLs, then I assume that it could work for other (pure) CIL-targeted languages.
    If that is not the case, I am interested in a technical reason why it would not work.
    At the momemt, it is the very first thing that I plan on trying when the beta is released.

  • Anonymous
    August 21, 2006
    > Please let us know which languages you'd like to see!"

    All present and future pure CIL-targetted languages.
    (I do not expect non pure CIL to be supported as it would contain unmanaged code.)

    I do not care if that level of support is available in an IDE or not; of course you can not build an IDE for all languages. Text editors and manual compiling are absolutely fine with me.

    But since the CLR only executes CIL, that should be a given from the start.

  • Anonymous
    August 21, 2006
    PingBack from http://mdavey.wordpress.com/2006/08/17/more-grid/

  • Anonymous
    August 21, 2006
    Yes, when I say "XNA only supports C#", it would be more correct for me to say "XNA Game Studio Express is only supported in Visual C# Express Edition". The framework assemblies should be accessible from other languages and other editions of Visual Studio, but those are not scenarios that are officially supported (at least initially).

    What you'll lose by using a non-supported language or IDE is some of the fluff like the project templates and starter kits, but also some useful stuff like "F5 deploy to console" and remote debugging. However, these last two items apply only to 360 development which won't be available to anyone until Holiday 2006 anyway.

    The XNA Framework Content Pipeline (which uses VS to manage 3D assets) is also tied to the IDE and won't initially be supported outside of VC#EE.

    So good luck with your project - there are a lot of people interested in playing with XNA in languages other than C# (primarily VB, it seems).

    (BTW, sorry for not answering your question directly the first time. I meant to imply that there's nothing technically stopping it and it's something that the XNA team would like to support properly in a future release, but that wasn't clear.)

  • Anonymous
    August 21, 2006
    garykac,

    Thank you for the clear response.
    I am glad to hear that there is no technical reason preventing development in non-C# languages.
    I understand, and would expect, convenience features as you described to be available only via the IDE, which understandably currently only supports C#.
    As a developer, I often need to work outside VS to do things that it does not support (such as writing IL for things not exposed in C# etc.)

    As long as the developer is prepared to handle some of the manual tasks and lack of certain convenience features,  you do not seem to be locking us into a single language. And for that, I am grateful. Thanks.

  • Anonymous
    September 14, 2006
    Ironpython will rule! Implement your gamecomponents in C# and then use them from Ironpython. Would be great to be able to have a pythonconsole and change stuff on the fly.  

  • Anonymous
    January 26, 2008
    PingBack from http://softwareinformation.247blogging.info/xna-diaries-xna-week-1-summary-what-weve-learned/