Understanding the Content Pipeline

The Content Pipeline can be used to solve a very real
problem: The content we create for games is typically not
game ready. For example, 3D content is usually stored in a
proprietary format and there is a need to convert the data
before loading it into the game. This is where Content
Pipeline helps out. In general, it can take different files as
input, massage them to get them into a type that we can
work with, and then compile them into a format that can
easily be loaded when our game starts.
The XNA Framework Content Pipeline is made up of
several components. First is the Content Importer, which is
responsible for reading the data that is loaded into the
solution. If there is data in the file the Content Importer
does not know how to map to the content DOM, then the
data is not stored. It only keeps the data it cares about.
Once the importer is done reading in the data, it passes it
along to the Content DOM, which stores the strongly
typed data. It is then passed from the Content DOM to a
Content Processor, which then passes it to a Content
Compiler. If the compilation fails we get a nice message
inside of the IDE that tells us what happened: We do not
114 CHAPTER 6 Loading and Texturing 3D Objects
have to wait and see if it is going to load at runtime, and this is a huge improvement over
how things used to work. The compiler actually builds files that are read in at runtime.
These files typically have an .xnb file extension. Audio files actually create .xgs, .xwb, and
.xsb files for the actual sound project, wave bank, and sound bank content. We discuss
the sound and how it relates to the Content Pipeline in the next chapter. The Content
Pipeline is smart enough to not recompile any content that has not changed since the
last build. Finally, after all of the content is compiled into files, they are read in via the
Content Manager at runtime so our games can consume the content. We have been using
the Content Manager since our very first application in Chapter 2, “XNA and the Xbox
360.” We created an instance to the Content Manager in our game’s constructor like the
following:
content = new ContentManager(Services);
Fortunately, when we use the Content Manager we do not need to actually dispose of our
objects, as it handles disposing of our content itself. It does this in the following code,
which is always included in our new game projects:
protected override void UnloadGraphicsContent(bool unloadAllContent)
{
if (unloadAllContent == true)
{
content.Unload();
}
}
The code simply calls the Unload method on the instance of the content manager. This
then goes through each of the objects that have been loaded and disposes of them. We
discuss the counter part of this method in the next section. The LoadGraphicsContent
method does the actual loading of the data.
As we add content to our project that is recognizable as XNA Framework content, it goes
through the process just described. The Properties window inside of the Visual C# Express
IDE will show an asset name that we can modify. If we add content types that are not
recognized, we can change the XNA Framework Content boolean value to true. We would
then need to fill in the Content Importer and Content Processor properties, specifying
how to turn the unknown content type into a format that XNA can recognize. This
would require a custom importer and processor that we discuss building in Chapter 8,
“Extending the Content Pipeline,” where we will learn about extending the pipeline.