Automatic .xnb serialization

John Doe has released a library that uses reflection to automatically serialize data to and from .xnb files, removing the need to manually implement a ContentTypeWriter / ContentTypeReader pair.

Two things I want to say about this:

  • It is really cool! The original Content Pipeline design actually included something similar to this, but we had to cut it in order to meet our ship date, and since then we've always had other higher priority things to work on. I would love it if we someday have time to build something along these lines directly into the framework.

  • Do you think his name really is John Doe? That would be soo cool 🙂

Comments (3)

Cancel reply

  1. snprbob86 says:

    I know someone mentioned earlier that there was a fear of reflection slowing loading, but I’d suspect that load times are predominately I/O bound. Just wanted to say that before anyone ruled out this idea without benchmarking it 🙂

  2. John.Doe says:

    Thanks for linking to the blog. Actually the real name is Alex, the blog is brand new, so there is a lot of info missing I guess.

    I don’t know if John Doe would be such a good name.

    … "What’s your name?" – "John Doe" – "Really?" – "Yes" – "No, Really?" …

    … and every second lawsuit would be either filed by me or against me 😉

  3. ShawnHargreaves says:

    Regarding perf, I suspect this depends on the type of data.

    If you have a large file that is mostly just individual vectors, floats, enums, etc, then using reflection could slow this down a lot compared to an explicit reader implementation.

    But I bet a lot of custom content types are actually just a couple of flags in the header, followed by a couple of megabytes of texture or vertex data. For such cases, using slow reflection to read the flags isn’t going to make any measurable difference, since the bulk of the work is going to be reading a big array, which does already have an optimized built-in reader implementation.

Skip to main content