This article documents the format of the compiled data files (.xnb) produced by the XNA Game Studio 4.0 Content Pipeline build process. This information may be useful if you wish to write your own code to load .xnb files into a programming environment other than XNA / .NET, or if you wish to create .xnb files independently of the usual Content Pipeline build process.

It also includes an example .xnb parser, written in native C++, which demonstrates how to parse a compiled XNB file by printing its contents to the screen. This can be used as a reference to help you understand how to write your own XNB loader, and also as a debugging tool for investigating exactly what data is contained within an XNB file.

What if you want to use the Content Pipeline build process and the same constructors you guys use for built-in content? Some of the latter are not public, like Song class for instance. And what about the compression class?

The only way to access those are via refletion but it only works on a safe environment (not useful on WP).

Say you re-write the content pipeline build process, you still have to deal with the fact that the constructors you use are internal (like in the Song class), like many other content.

Until last year, and for almost two years, I had been working in my own Content Manager class using XNA v3, inter alia, solving the problem with Dispose and improving loading times a lot in many use/test cases for the PC, the XBox 360 and Zune platforms (this even taking into account the fact that I had to use reflection to avoid writing my own Content Pipeline process).

With XNA v4, my CM still works the same for the PC and the XBox 360 (Zune is no longer supported), but reflection is not feasible for the WP. So, loading assets like Song is not straightforward for that platform. Thus, I stopped working on it any further.

So, my question is, will you guys ever make those constructors public (as opportunely suggested through connect)? (I mean, for all content and the compressor).

This is really great, it would have been helpful if a content builder not based on msbuild and able to handle caching/minimal rebuilds/multi threading etc had been created(before I ported to D3D11/SlimDX for the enhanced feature set, hint, hint:-).

I was wondering why you didnt store the runtime type in the reader table to support ReadRawObject<>(). That was the only structural dofference I noticed from the doc for my semi code compatable replacement(minus compression).

You can always query the reader for the name of the type it reads (although not the other way around) so just the table of reader names is enough to determine both pieces of information. No need to waste space storing both if one can be derived from the other…

We store the name of the reader, rather than the type being read, in order to support extension scenarios where you provide a reader for a type you do not directly own (eg. XNA provides readers for System.String, but mscorlib knows nothing about XNA Content Pipeline).

> Then why does the writer have a GetRuntimeType() in addition to GetRuntimeReader()

To handle generic types such as collections.

When you serialize eg. a List<Texture2DContent>, the resulting reader class should be ListReader`1[[Texture2D]], which requires knowledge of both the fact that List is loaded by ListReader (ie. GetRuntimeReader) and also that Texture2DContent loads into a Texture2D (ie. GetRuntimeType).

The thing in the XNB header is always a reader type name, but if this is a generic reader type, that reader name includes the type of thing being read as its generic specialization.

Ultrahead: your question was about a different issue to the topic of this post. I'm sure you know by now that we don't announce or discuss hypothetical future features in informal venues such as blog post comments, forums etc 🙂

But actually it's not different, it could refer to "or if you wish to create .xnb files independently of the usual Content Pipeline build process.". Even if you do it, you cannot call internal constructors either directly or at all, depending on the platform.

> But actually it's not different, it could refer to "or if you wish to create .xnb files independently of the usual Content Pipeline build process.". Even if you do it, you cannot call internal constructors either directly or at all, depending on the platform.

Huh?

Creating .xnb files doesn't require any access to internal XNA methods. They're just a sequence of bytes, in a format described by this document. You don't need any XNA code to create such a thing, which was the main point of documenting the format…

Yes, but loading them using XNA is the remaining vital part to close the rationale. I.E: you can create an xnb file for a SONG without XNA, but what's the point if you cannot load them as an instance of a built-in SONG using XNA?

Armed with this format information, you can also now write code load .xnb files using any other non-XNA technology, and/or create .xnb files not using XNA.

What you cannot do is replace just parts of the XNA implementation (at least for the types which are not publically constructable), eg. writing your own loader but still targetting our runtime types such as Song. If you want to use our implementation of these types, you must also use our loader. Or if you want to write your own loader, it must load into some other type of your own.

Making all XNA types publically constructable is a totally separate issue to enabling non-XNA code to create or consume .xnb format data.

> Something important that doesnt seem to be provided is a description for the format of an XNA effect

Correct. The effect bytecode format is not considered part of the .xnb format, and not something it would really be feasible to create other than by using our compiler. It's a highly platform and version specific format, not something you could really mix&match to create or consume using different toolsets.

And, I guess the only way to access your compiler is by calling into the XNA effects processor?

A public C++ API for your compiler dll(which I guess is native and derived from the windows+XDK effects compilers for those platforms) would make it a lot easier for anyone to create tools to output a full range of XNA content…