The Vodka Content Management System is a service based, multitier setup with the clients getting access to all content and member information via services. In turn, the services communicate with each other as well as their respective data stores. One of the goals of designing Vodka is to implement objects in a way that is easily extendable. To accomplish this, all content is managed in terms of the text data (XML) and its meta data (title, author, date stamps, et al).

The problem is how this data is transformed into its two main uses: HTML and .NET Objects. The question is where these transformations take place. In order to transform an XML file into HTML, the code needs access to an XSL file. The problem with this is that it too, is treated as a piece of content. It is regulated in exactly the same way with the same level of security. Thus it can be seen that this service should remain on the server. This is where it currently sits, so what is the problem?

The problem remains that it shouldn’t be a server side operation! That is slow! It requires more implementations than necessary and furthermore it builds a bad dependency on the server for specific implementation.

Scott Hanselman has been on a roll lately with his posts and twits. Today he writes “Question to .NET Programmers: what is the difference between the System.* and Microsoft.* namespaces?”

This is an important question and one that I can’t say I truly know the answer too. I had always assumed it was based on either the idea that System.* was part of the core framework where as Microsoft.* was for Microsoft specific functionality. For instance, it would be expected that much or all of the System.* functionality would be replicated on many other platforms where as Microsoft.* would not.

Certainly this is true for the very basic feature set such as the common types but it is not true for System.Windows.Forms. Which begs the question that I always wondered: why is Windows.Forms where it is? I always expected it to be in Microsoft.Windows.Forms as it is a Windows specific implementation based on many of the Win32 controls.

This is a fundamental topic in C# and if you plan to do any development at all with the language you need to know this. Override is used for changing the behavior of the original type’s method or property. The new keyword, in this case, is used for scratching the existing behavior but only in the current type. To better explain this, consider the following code.

1
2
3
4
5
6
7
8
9
10
11

public class Foo{
     public virtual void Print(){
          Console.WriteLine("I am a Foo!");
     }
}
 
public class Bar : Foo{
     public override void Print(){
          Console.WriteLine("I am a Bar!");
     }
}

If we declare a Bar and cast it to a Foo in the above code, we will still get “I am a Bar!” when we invoke the Print method. However, if we change the code to the following things will get messed up a bit.

1
2
3
4
5
6
7
8
9
10
11

public class Foo{
     public void Print(){
          Console.WriteLine("I am a Foo!");
     }
}
 
public class Bar : Foo{
     public new void Print(){
          Console.WriteLine("I am a Bar!");
     }
}

If we instantiate a Bar, we will get the new functionality. However, if we cast that Bar object into a Foo, we will get the implementation provided by the Foo. So be sure of what you are using and why!

Today, while coding Galactic Wars v2.0, I stumbled upon a problem I have been having with content since I started working with XNA. The following diagram shows how easy it is to create the problem and how devastating it can be to any application. In my case, I have two (or more) menus that are referencing a piece of content.

Each menu references the same managed object which is really a wrapper for a second managed object (Texture2D in this case). The second object is a managed wrapper for the underlying unmanaged data, again in this case it is texture data. The problem is when one menu is being phased out (unloaded) and another is being phased in (loaded). The menu being loaded grabs a reference to the content before the other menu can unload it. The ordering is done this way to ensure that a menu actually loads its content before the current menu is unloaded.

After the menu is done loading content, the second menu is unloaded which drops the content and releases the unmanaged memory. Aha! The problem stems from the last point: I am trying to manage unmanaged memory when I should just let the GC take care of it. The reason I do this is for performance reasons, primarily on the Zune. Instead of letting textures just sit around, I release them when they are no longer needed to avoid piling up the garbage.

So what is the solution?

1. Dereference the Managed Object
   

   I would love to do this but unfortunately it introduces a second problem. If every menu (object using the content) dereferences the asset, it still will not be collected by the GC. The AssetManager still holds a reference which is now being unused and thus memory is wasted. The upside to this is that I do not need to implement the second option…

2. Reference Counting!
   

   By implementing a counter on the asset itself and asking developers to always call Unload or Unload(ILoadable) on the AssetManager, I can guarantee that no Asset will be disposed while another object is using it. The downside is that it is an ugly implementation of something that is done in the GC anyways. The major upside is that even if developers use the previous method, the GC will still eventually catch the wasted memory.

So now Thrust’s AssetManager and IAsset require (and implement) reference counting to avoid the problem described above. And it works wonderfully.

The provider model’s goal is to allow for the abstraction of implementation to the n^th degree by allowing for the choice between separate implementations of the same functionality. This design pattern is incredibly common in Microsoft’s ASP.NET, especially in the realm of security. Developers can choose between different providers for membership, roles and authentication for a single site. The point is that the core functionality of the site does not change, only the implementation. Below is a quick snapshot of how such a model is used in Vodka.

The driving force behind the provider model is the abstraction of the implementation. This is done via an interface.

1
2
3

public interface IAuthenticationProvider{
	bool Authenticate(string username, string password);
}

What gives the provider model its meat and bones is the different implementations of the above interface. The two implementations below represent two authentication backends: an ActiveDirectory installation and an Sql database. Although the meat has been stripped from these two classes, it is clear that their implementations would differ enough to have the two separate classes. Read the rest of this entry »

With the arrival of .NET 3.5 and consequently WPF applications, Microsoft has done away with the old Application WinForms class. No longer can you call Application.LocalUserAppDataPath to get where the user’s files are stored. To restore this functionality as well as add a bit more, I have tapped into an uncommon resource: extension methods. Let’s dig a little deeper, shall we?

Read the rest of this entry »

In this fourth [page, second post] installment of the MGS: Pong article series, I am going to cover how to draw a background for the game. Before I start, I should tell you that there will be two more articles: one for creating the menu system and one for pulling all the classes together. Okay, let’s begin! The background class (Background.cs) is incredibly easy to create. First we need some private members to draw the background.

Read the rest of this entry »

In part one of the mini game article series, I am going to show you how to create a very simple Pong game from scratch. The tools you will need include Photoshop (or any other painting program such as Paint.NET or even MSPaint), Visual C# 2005 Express, and of course the Xna framework.

First we need to create our project, to give us a home base for all of our work. Go ahead and fire up C# Express and create an empty windows project. I am going to call mine MGSPong for lack of any imagination or any better title. Once the project has been created, add a folder called “Content” and then another underneath that called “Textures.” This is where we will store out art, no matter how bad it may be!

Read the rest of this entry »

Hardware Instancing is an interesting topic that has quite a few uses. The idea of instancing is to use the hardware to generate transformed vertices to reduce draw call overhead. Now I know that sounded like a bunch of senseless technical jargon, and it was. In plain English, sometimes it is faster to let the GPU do all the work for us so the CPU can go off and do other work; and this is what Hardware Instancing does. This article covers how to setup a simple program that uses instancing to render a few rotating squares.

Read the rest of this entry »

The Parallel Extensions for .NET was released yesterday. Parallel Extensions provides an easy way to develop software on multicore and multiple CPU hardware with a managed programming model.

We’re very excited to announce our 2nd Community Technology Preview (CTP) for Parallel Extensions to the .NET Framework 3.5. We released the Dec07 CTP on 11/29/2007, and from that we have received a lot of feedback from the community and customers. While you have been using our bits, participating in our forums, sharing your insights and experiences, and following along on our blog, we have been hard at work preparing this CTP, incorporating your feedback into it.