Once more unto the chopping block

So some great news for me, the SharpDX Toolkit was released at the end of October, providing a clean high-level interface with DirectX11 similar to the XNA model, only not reliant on XNA support.  I'm especially excited because it allows me to fall back on what is most assuredly a better-structured library than what I cobbled together while learning how to program a DirectX pipeline.

While this doesn't break my current code, it does give me a great foundation to make one final sweeping overhaul to the main engine/library to focus on a data-centric model.  My existing code wraps a lot of data objects with personality and functions that really should just belong to an authoritative "Renderer" object, so I've started moving towards a design that simplifies my camera classes, effect libraries, and other infrastructure entities and makes them components of a primary Renderer.  That renderer will work with a single source of world data and state data to render the entire scene (from world geometry to actors, UI, etc) appropriately for the gamestate.

The other impetus for cleaning up and officializing (is that a word?) my data components is interoperability with other sub-systems.  My physics and AI managers are going to need to access subsets of the world data to do things like calculate navigation meshes and collision hulls based on a dynamic worldspace, as the players will be creating (and destroying) walls, buildings, nests, resources, and so on.  Moving data management and world change responses into a singular "world manager" that can handle manipulation and access to a geometry and materials heirarchy will keep that organized and clean behind some simple interface calls.

So aside from the (I promised myself, final) design overhaul, I've been off in right-brain land honing my art chops before I start cranking out assets I actually want to use in the game.  I'm pleased with the practice and progress, and should have some character sheets of the main characters (in their designer-blessed officialdome) available shortly, with environment shots to follow.  Everybody loves some good concept art.

New and Improved Editor

I've banged my XNA-based level editor into shape with the new SharpDX-based graphics engine, and now have prop manipulation implemented!


click to enlarge

On the bottom there are two differently scaled copies of the same rock prop, and the (incredibly low-detail) rock bridge is another stand-in prop.  (It will still be in later, I just exported it from Blender as soon as it had a basic shape and texture coordinates.  I'm continuing to refiine it and create a proper texture for the mesh)  You can see the debug views of the deferred rendering targets across the top.  A rough cut of my ink-style outline shader is in use as well, though it could use some blur passes and tweaks to really be more what I was intending.

I've wanted to get this functionality in place ever since I first watched someone demoing the Hero Engine level editor a few years ago and realized how varied you can make a scene just by rotating and scaling a handful of props.

Someday soon I'll get the rest of my editor buttons in place :)

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.