Posts in category .net - page 29

Microsoft XNA

Microsoft have announced their XNA platform for game development.

The platform is based around C# and the .NET 2.0 CLR and frameworks, specifically tailored for the requirements of game developers. This might possibly mean much of the common language specification (CLS) elements are removed for performance.

Initially the platform will target both Windows machines and the Xbox 360 although Microsoft have touted cross-platform compatibility and with the recent shared-source version of the .NET 2.0 CLR source code ROTOR release there are hopes for Mac OS X, FreeBSD and Linux.

XNA Studio is the central IDE for the platform and is based around a modified version of Visual Studio 2005 Team Services.

Currently the only tool available is XNA Build which is a modified version of MS Build with additional tracking features to ensure obsolete game assets are suitably pruned. Microsoft have modified their MechWarrior 2 game source code to build using XNA Build and were surprised to realize that around 40% of the textures they shipped on the CD were in fact no longer used having been artifacts from previous builds.

In my opinion there’s a few reasons why Microsoft is going this route..


Microsoft want developers to get away from Flash – at least on the Xbox 360. Some of the Live titles, notably Hexic, are Flash games. Flash is okay for 2D games and their run-time has been modified to utilize the Live! and 360 controller but adding 3D would be non-trivial and it’s still a non-MS platform.

Isolation of home-brew code

It’s no secret that developers at home love to get code running on their favorite console platform be it to port existing games or emulators (such as ScummVM) or simply to hack around.

The problem with letting developers run your own code is that it becomes quite easy for other people to use this to boot pirated “warez” versions of games professional developers just spent a few million dollars developing.

By giving developers a byte code based language such as Java or .NET you can control what they do. Specifically you can give them no mechanism to launch native code such as that comprising a commercially developed Xbox 360 game…

Flesh out Xbox Live!

Xbox Live! seems to be a hit and Microsoft have put up titles from smaller indie development studios. This is all well and good as both the studio and Microsoft make money from the purchase but the Xbox 360 dev kits aren’t cheap. This probably explains why a number of those games are Flash…

With Sony’s announced PSP Live serving up highlights from the original PlayStation back-catalog and Nintendo hinting at emulation of older systems on the Revolution the 360’s catalog is going to look a slim by comparison.

If Microsoft get XNA out there and let developers write and distribute Windows versions how they see fit they can grab the cream of the crop for publishing on Xbox Live.

Either way it looks like good news for Xbox 360 owners and small developers. Microsoft have already stated back-bedroom coders will be able to get in. :)


Web applications in Visual Studio 2005

One of the things that annoyed me with Visual Studio.NET 2003 and Visual Studio 2005 is the web “project” type.

The main problem is that these projects are not treated as traditional applications, but in order to please the ad-hoc web developer crowd they are treated as collections of files with no specific project options or compilation process – instead compiled on-the-fly by the web server.

Now for managing day-to-day web sites I can understand this. You don’t want a small change to one page bringing down the whole site because of a compilation error.

But there are other scenarios whereby you are developing a web application, perhaps as a front-end to your main system and you want that compile error to show up here and now. You want compilation options because you’re not intending on shipping the source out to other people.

Thankfully I’m not alone in this scenario and Microsoft have released a second beta of the VS 2005 Web Application Project. They have also updated the beta of the VS 2005 Web Deployment Project to work with it.

The Web Deployment Project lets you right click and built to remote and test servers…. Nice.

You can keep an eye on the developments over at ScottGu’s excellent blog.


Do not expose the implementation

One of the things we are taught in object oriented design is that the outside world should not be exposed to the complexities of how our object achieves their goals. Other developers are busy, don’t care and really don’t need to know. It is a sound idea and goes hand-in-hand with ease of use.

Televisions used to expose the implementation with a single tuning knob that had to be adjusted every time you wanted to watch another broadcast. With time engineers replaced this with an interface that hid the implementation, specifically the concept of channels where each one could be individually tuned and switched between on a whim. Implementation no longer exposed.

Technology brings complexity but only good technology makes it look simple.

One thing that has always annoyed me here in the UK is an every day object that doesn’t hide the implementation.


That’s right taps. I don’t care that water is delivered to my sink through two pipes, hot and cold. I don’t ever want scolding hot water and just as rarely require it uncomfortably cold. Most of the time I want the same warm temperature as last time.

Sure, there are taps that do this and indeed in many other countries it seems to be the norm but here in the UK builders keep putting in separate hot and cold taps in. Until either the public wise up or I actually buy my own house and can replace this sort of annoyance I’m stuck with it.

While taps have annoyed me for a while it was .NET 2.0 that reminded me of the whole issue again and a brief discussion with GrinGod that caused a similarly titled post of his own. Specifically the Hashtable class is now called Dictionary when used with generics which once again prevents the implementation details leaking out into your code. Important in this case because most people wanted a fast dictionary and didn’t care too much how it was achieved and also because that algorithm changed in .NET 2.0 and they realized they shouldn’t have specified the implementation in the class name…

If you previously generated strongly-typed collections in .NET 1.1 using the many tools around such as CodeSmith then you might be interested in this little tip. If you have a strongly typed class such as:

public class MyObjectCollection : Hashtable {
  public MyObject this[object key] {
    get { return (MyObject) pHashtable[key]; }
    set { pHashtable[key] = value; }

Then instead of replacing every single instance of

var theseObjects = new MyObjectCollection();


var theseObjects = new Dictionary<object, MyObject>;

you can in fact simple change MyObjectCollection and leave the rest of your code alone:

public class MyObjectCollection : Dictionary<object, MyObject> { }

Which will also mean that you can still have the additional properties and functions on MyObjectCollection if you had them previously. It’s rather obvious you can do this but many samples I’ve seen just create raw generic collections everywhere rather than inheriting from them.


NullableTypes 1.3.1 beta

In my early .NET days I ran into a problem many developers integrating with other systems do. Unlike XML with it’s xsl:nil or database fields with <null> the standard .NET value-types don’t support the concept of null for missing values. It’s such an important omission that Microsoft implemented it in .NET 2.0 (now gone RTM and up on MSDN) with a generics class named [Nullable](,vs.80%29.aspx) and a little syntactic sugar to help it go down smoothly.

For those of us still working with .NET 1.1 the NullableTypes project provides null-capable versions of all your favorite .NET types and unlike the SqlTypes included in .NET these match the System types for precision and provide support for .NET remoting and web services.

Yesterday NullableTypes 1.3.1 beta was release which adds (since the last 1.2 stable release):

  • New types (NullableGuid and NullableTimeSpan)
  • DateTime.Add method returns new instance in keeping with the the other immutable classes
  • Security enhancement (reduced needed permissions/attack surface)
  • NullableInt16.GetHashCode now returns hash codes identical to Int16
  • Improvements and additions to the unit tests

With my contributions now including NullableGuid, NullableTimeSpan and implementing IXmlSerializable I am finally feeling like an open source/free software contributor.

I’ve got a few more ideas for NullableTypes that I’ll be working through with LuKa around unit testing and .NET 2.0 source compatibility.