Forging ahead into DX11 : Lessons Learned

It's a good thing I'm not feverishly attached to any of the code I write, as I've probably scrapped entire sub-frameworks three times over in the process of building, then learning, then rebuilding my graphics and content pipeline with the SharpDX libraries.  I can definitely say XNA makes things neat and tidy for development, and I think I'll stick with it if there's anything in the near future I just want to hash together to prototype something.  At any rate, the good news is I've gotten back to where I was with XNA, only now it's built on a much cleaner framework with a newer underlying graphics API, and a snazzy deferred-rendering pipeline with a handful of associated flexible utility classes for multiple-render-target functionality.

The main intent of this post is to try and help out those people trying to move from XNA into a lower-level yet still managed graphics library.  What follows after the jump is some of the things I had to replace and rebuild once I pulled the "using Microsoft.XNA" statements from my code.  It's mostly a high-level look, I'll go into more depth (and more code) on specific issues down the line.

Conversion Updates

Talk about a learning experience!

So I've mentioned that I want to port the current code over to a different graphics framework, and had originally mentioned SlimDX as the targetted library.  After doing some research around the net, I discovered (as in most cases with APIs) I was chasing the tail of a "dying" resource.  SlimDX is still fully functional and perfectly useful, but apparently the authors (all three of them) are turning away to focus on alternate projects or generally move on with their lives.  The project has been a lot of work over many years, as you can tell from the revision number (above 2200 last I checked), and you can't honestly begrudge the guys for wanting to focus on other things by now.

That being the case, I did want to work with something that had some more active support and development, and turned to SharpDX.  From what little I gleaned, the author of SharpDX actually used to work with the SlimDX team, then yadda yadda differences of opinion etc etc.  The end result is they both stick very close to the native DirectX libraries, with SharpDX continuing to be grown as new releases of DirectX come out.  Apparently he's even working on a SharpDX version of the new toolkit that will bring things like built-in Font and Sprite frameworks (something you currently have to home-brew in Direct3D11).  Color me excited :)

So with my API choice settled, I've been porting things over and building new framework elements where needed to replace things like XNA's content import pipeline and effect support system.  I've rebuilt my camera system and deferred rendering chain from the ground up to be cleaner, more organized, and legible, and with the new API paralleling the DirectX native libraries, I can use a host of references aimed at C++ development for solving any problems I run into.

This whole process has given me a much clearer view of the Direct3D11 rendering pipeline, and some of the fog of XNA's high-level interface has been cleared away to see what was being done with .fx files and techniques.

I've also brought in Assimp's .NET wrapper API, AssimpNET, for doing all my mesh loading.  Their scene objects and all-inclusive data parsing give me the best flexibility while not requiring me to write my own model parsers.

Once I get the game and level editor functioning at the same level they did originally, I'll post up some comparison code in case anyone else is wondering how you make the transition from XNA to a more future-friendly API.