XNB file format documentation

XNB file format documentation

  • Comments 23

Recent silence notwithstanding, I'm still here, and will have more to say about aliasing as soon as I find myself less busy!

In the meantime, check out this latest App Hub release:  http://create.msdn.com/en-US/sample/xnb_format

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.

  • Thanks a lot for documenting the XNB file format. It's really helpful!

  • 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).

  • Never mind, I guess it gets it from the <T> for the content reader.

  • Never mind indeed, guess the first comment got lost somehow.

    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:-).

  • David: now I'm curious what your original (missing) comment was :-)

  • 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(), since it seams it is never needed?

  • Looking back at my code... For converting generic writer arguments I guess.

  • > 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.

  • Ok, thanks for ignoring me; that's also an answer ;)

  • 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 :-)

  • Fair enough.

    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 as I said, fair enough. No more public questions ;)

  • > 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?

Page 1 of 2 (23 items) 12
Leave a Comment
  • Please add 6 and 4 and type the answer here:
  • Post