Understanding the Content Pipeline, Part 3

Content Processors

In the last post, I talked about Content Imports and their role in opening an asset file and parsing its content.  Ultimately, the importer produced a managed object that represents the data in the file.  This managed object is then passed onto the Content Processor for further work.

Content Processors follow a similar design pattern to importers.  You write a class that derives from ContentProcessor<TInput, TOutput>.  TInput is the type of the managed object that the importer produced.  This will become the input to the Process() method that you will override.  The TOutput type is the return type that the processor will produce.  Many times, the input and output types will be identical (however the output will have been transformed in some manner as performed in the Process() method).

In my game, I wrote a processor that builds a direct acyclic word graph from a list of strings each representing a distinct word in a dictionary.  The process of building a word graph is a bit complicated and I’m not really going to go into it at this point (this is about the content pipeline after all).

The idea that the content processor processes content is very wide open.  You could write many processors that did as much pre-processing as possible of game assets.  The number of possibilities is limitless.

Here’s an example of a basic skeleton of the content processor I wrote:

[ContentProcessor(DisplayName = "Word Graph Content Processor")]
    public class WordGraphContentProcessor :
                   ContentProcessor<WordListContent, WordGraphContent>
    {
         public override WordGraphContent
              Process(WordListContent input, ContentProcessorContext context)
         {
               WordGraphContent output = new WordGraphContent();
               // do the processing...
               return output;
         }
    }

As you can see, you override the Process() method which takes the input type as a parameter.  You then perform whatever processing you need to do on your asset.  In the end, you return the transformed object either as a new type (as is in my case) or as the same type as the input type.

You must attach the ContentProcessorAttribute to the class so that XNA Game Studio will recognize the processor.  You can give it a pretty DisplayName that will appear in the properties window of Visual Studio.  When you open an asset and attach to your content project, you can select the custom processor from the drop down list by this friendly name you give to it.

Now is probably a good time to discuss something important.  If you are making an XBox 360 game, it is important to know that niether your ContentImporter or ContentProcessor that you custom build can ship with your game.  This is because the dependency assembly (Microsoft.Xna.Framework.Content.Pipeline.dll) is available on Windows only.  This makes sense because building your game and its assets only ever occurs on the development machine which is running Windows.  This is important to note because it means that your importers and processors must be contained in a separate class library project within your game solution.  You need to reference the content pipeline assembly to get access to the ContentImporter and ContentProcessor types.

This is another “gotcha” that I should explain.  If your assembly with the importer and processor references any XNA Framework code (like Texture2D for example), it must then reference the Windows version of the XNA Framework.  If you are writing a Windows-only game, this isn’t a problem, but if you are writing an XBox game, there is a separate framework version for the 360 and you cannot use it in this project.  Furthermore, your Content sub-project of your game must reference your custom assembly containing the importer and processor.  If it doesn’t, the content build system will not know about your custom importer or processor and will not present them as a choice to you to use.

I think this pretty much wraps up this very basic introduction to the content pipeline.  Read the XNA documentation to get more info and take the next step in your understanding.  Once you realize how powerful this build process is, you will start thinking of new and inventive ways of using content.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: