Posts in category .net - page 28

Piecing together Microsoft’s XNA gaming platform

I’ve briefly covered Microsoft’s XNA gaming platform before but have been trying to piece together what it is actually going to mean to developers.

Major update!</p>

Sorry, had to clarify the whole commercial/non-commercial parts. XNA Framework is just a portion of XNA… that won’t apply to the big guys.


Microsoft have made it clear they want to open up XNA to interested parties which should mean home-brew software.

These guys will be using C# in conjunction with XNA Build, XNA Studio, XNA Framework and managed libraries.

Licensed developers

Licensed 360 developers get a whole set of tools and technologies that are under tight NDA just like those Sony and Nintendo insist on for their licensed developers.

These guys will be using C++ in conjunction with XNA Build, XNA Studio and no doubt 360-optimized unmanaged libraries based on Direct3D, Xinput and XACL.

Whether XNA lets Microsoft get the 360 and Windows XNA gaming platforms a little closer is anyone’s guess. Being under NDA I doubt the general public would even know.


C# for home-brew developers, C++ for licensed studios.

There’s no way the licensed studio’s are going to change and C# lets the new guys get up to speed quicker.

Licensed studios will have full control, full speed and continue to use their existing libraries and middle-ware.

Core framework – .NET 2.0 BCL

.NET 2.0 Base Class Library – well a modified version of it for those using the XNA Framework and C#.

Seeing as C# is the only managed language on the menu and games are rather performance sensitive expect CLS compliance to disappear and plenty of under-the-hood optimizations now that they don’t have to support other languages.

Graphics framework – MDX2

The graphics framework is based on the graphic assemblies of Managed Direct X 2.0 (MDX2) which currently ships as part of the DirectX SDK.

MDX2 is currently beta and will never hit a final release now all attention is now focused on the “XNA Graphics API” version that will see the weight drop and aim to be more cross-platform – no doubt hiding away all the platform-specific optimizations inside the libraries themselves.

There will be no System.Drawing and no System.Windows.Form name spaces so forget about them.

Audio framework – XACT

Microsoft Cross-Platform Audio Creation Tool (XACT). Grab it from the latest DirectX SDK and forget about DirectSound and DirectMusic. They won’t make it.

Input framework – Xinput

XInput kicks DirectInput off the scene with it’s easier-to-use API and support for vibration and varied controller types and voice headset.

Grab the XInput Driver for Microsoft Common Controller, plug in the 360 controller on your PC and start messing round.

Build tools – XNA Build

XNA Build is based on MS Build but adds asset (textures, samples, music etc) tracking to the mix to ensure you don’t do like Microsoft and ship almost an entire CD’s worth of unknowingly unused assets with your Mech Commander. It also lists incremental and distributed builds on the feature list.

A March 2006 technology preview is available that integrates with Visual Studio 2005.

IDE – XNA Studio

Once again Microsoft takes from it’s existing .NET tool-set and makes an XNA version – in this case Visual Studio 2005 Team System..

Whether the cheaper home-brew/XNA Framework/C# version will have all the C++ features stripped is anyone’s guess.

Live Anywhere!

Microsoft have already announced their plan to take online gaming from the Xbox 360 (gamertags, achievements, friends, chat) and make it cross-platform across to Windows and mobile gaming.

It would make of sense then that the Live Anywhere! system is .NET framework for use with XNA – even if it doesn’t officially make up part of the package.

Have to sit and wait for this one to pan out.


Microsoft will be supporting:

  • Xbox 360
  • Windows XP 32-bit/64-bit*
  • Windows Vista 32-bit/64-bit*

Mac OS X?

Apple should really be negotiating to get XNA on Mac OS X. It already internally supports PowerPC (360, G3, G4, G5) and Intel (Windows, IntelMac) as what they offer developers seems rather weak – about the only reusable element is OpenGL.

This would allow existing XNA games to be ported with ease although would be of little use to existing Apple developers who use Objective-C/C++ and wouldn’t want to interop with C#.


Linux already has Mono & DotGnu which could provide the basis for a .NET based gaming platform but I can’t see Microsoft wanting to open up the source for a successful Linux port.

The only obvious route here would be for Linux developers to either implement it themselves or wrap around existing technologies – Wine/OpenGL etc.

Sources & info


Substitutability of generic types in .NET

The “is” operator

Anyone using object orientated programming soon finds themselves wanting to perform some action only if an object is of some type or implements some interface.

The easiest way is to do this is to use the “is” operator. Typically it will appear something like;

object objA = FunctionToGetAnObject();
if (obj is SomeClassOrInterface)
    ((SomeClassOrInterface) obj).SomeMethod();

Here if obj_A is of a type that implements SomeClassOrInterface anywhere in its inheritence tree then SomeMethod of SomeClassOrInterface will be called.

Test substitution with generic types

Now lets say we have our own generic type – here’s one to illustrate a point;

public class DamoClass<T> {
    public T GetProperty { get { ... } }
    public T SetProperty { set { ... } }
    public bool IsValid { return true; }

If we want to check obj_A supports DamoClass<T> but we don’t care what type T is you might expect to be able to perform;

if (objA is DamoClass)

But that results in a compilation error – you can’t reference a generic class without specifying the type parameters regardless of whether you care about them or not. You might then try;

if (objA is DamoClass<object>)

After all every class inherits from object. This compiles fine but at runtime if objA is of any type other than object, e.g. DamoClass<string> it will return false.


The following might be what you had in mind;

if (objA is DamoClass<object>) {
    ((DamoClass<object>) objA).IsValid();
    object test = ((DamoClass<object>) objA).GetProperty;

Which looks fine but if .NET allowed that then how would it prevent;

if (objA is DamoClass<object>)
    ((DamoClass<object>) objA).SetProperty = 11;

When objA.AssociatedObject might well be something other than an integer? It can’t – so it doesn’t.


The solution is to split your generic class into two classes.

The first contains your non-generic methods and properties and the second inherits from the first adding all the generic specialisation. The good news is that they can even have the same name.

public class DamoClass {
    public object GetProperty { get { ... } }
    public bool IsValid { return true; }

public class DamoClass<T> : DamoClass {
    public T SetProperty { set { ... } }

Then you are free to do;

if (objA is DamoClass) {
    ((DamoClass) objA).IsValid();
    object test = ((DamoClass) objA).GetProperty;

Indeed .NET itself uses this technique for IEnumerable and IEnumerable

One drawback with this technique is that you can’t redefine the type of a member in the subclass – maybe that’ll make C# 3.0.


Handling nullable value types in .NET 1.x

One of the great new features in .NET 2.0 is support for nullable types – especially important when dealing with value types such as Int or DateTime values coming from a database. Previously you were forced to either set and track another binary flag or to use a “special” value to represent null that sooner or later would turn up in real data.

In C# 2.0 thanks to a bit of syntactic sugar we can do this;

int? nullable1 = 1;
if (nullable1 == null) nullable1 = 2;

Which the C# compiler actually turns into the following:

Nullable<int> nullable1 = new Nullable<int>(1);
if (!nullable1.HasValue) nullable1 = new Nullable<int>(2);

This makes use of the new Nullable generic structure to wrap the value with an additional boolean HasValue property.

That looks surprisingly similar to the syntax of the open-source NullableTypes project you can use with .NET 1.1 (or 2.0):

NullableInt32 nullable1 = new NullableInt32(1);
if (nullable1.IsNull) nullable1 = new NullableInt(2);

Disclaimer: I’ve worked on the NullableTypes project specifically implementing the IXmlSerializable, NullableGuid & NullableTimeSpan.


Bad programming advice – don’t use exceptions

Kristian Dupont Knudsen has written a top 10 of programming advice not to follow with his rationalisation for each one. Being a programmer I thought I’d chip in with my 2 bits.

Joel recommends not using exceptions because they are “invisible in the source code” and that they create “too many possible exit points”.

His recommendation is to return error values when thing go wrong just like C does. This solves neither of the two problems he mentions and creates some new ones;

  • Passing an extra ‘error’ parameter to a function or use part of its return value
  • Keep track of the various error codes and what they mean
  • Newer libraries may return new errors that your code wasn’t written to handle and so your code will continue ignorantly
  • Forget an error and you’ll continue as if nothing went wrong…

I have to agree with Kristian on this one – Joel’s advice just makes no sense. Exceptions are a much superior solution to a difficult problem.

While I think Java went overboard in each method declaring what it might throw and needing to ensure you accept that C#’s balance seems just right.

Throw exceptions when your method can’t do what it says on the tin but exceptions should be just that – the exception. Don’t ever throw them to signify some additional or inconsequential condition.