I want to talk about the XNA Framework Content Pipeline! I do, I
do, I do!
But apparently Michael is working on an overview post, so I'm going
to wait for that before diving into any details. In the meantime, I
decided to talk about some of the background assumptions that went into
our design.
Game content (by which
I mean graphics, sounds, physics settings, AI data – basically
everything that isn't your actual code) is created in a DCC (Digital
Content Creation) tool. This could be Photoshop, 3D Studio Max, Maya,
Milkshape, Paintshop Pro, MSPaint, the Visual Studio XML editor,
Notepad, or perhaps even a custom editor written just for your game.
After it has been
created, this content is then used by your game.
So where's the
problem? Why do we need a pipeline here at all? In fact what even is a
"pipeline"? Should environmentalists be worried about potential impacts
on the Alaskan wilderness?
The fundamental issue
here is that DCC tools tend not to create content in the right format
for games. For instance:
-
2D paint programs
usually create images with a 32 bit color depth. But for efficient
rendering on a graphics card, most textures should be using the
compressed DXT format.
- Intel processors are little-endian. The Xbox CPU is big-endian. This
means data created on an Intel PC needs to have the byte order swapped
before it can be used in an Xbox game.
Those examples are
just off the top of my head: there are many more. I'm sure you get the
point that lots of conversion work is needed before a game can use data
out of a DCC tool.
So tell me, I hear you
cry, how and where should this work be done?
There are really only
three possible options.
-
We could do the
conversion inside the editing tool, by writing a custom exporter that
saves directly into a game format. The Photoshop plugin that exports to
DirectX .dds files is a good example of this approach. The disadvantage
is that you'd have to re-export all your data any time the conversion
requirements changed. For instance if you were making a game for more
than one platform, you'd have to export everything several times using
different options for each target platform.
-
We could do the
conversion directly inside your game, as a side effect of loading
content. The D3DX Mesh class and CreateTextureFromFile methods are good
examples of this approach. The disadvantage is that we'd have to repeat
the same conversion work every time you loaded content, and if the
processing was at all complicated, this would slow down your game
loading. A pet peeve of mine is games with long load times. I don't like
having to wait around before I get to play!
-
We could do the
conversion in between the editing tool and the game, using an
independent program. The dxops utility (part of the DirectX SDK) is a
good example of this approach. The disadvantage is that if you aren't
careful, it can be pretty confusing remembering which converter
utilities you have to run on each file, and it is easy to forget to
re-convert something after you change the source asset.
Anyone care to venture
a guess which approach we chose for XNA?