Hi DirectX, It's Nice to See You Again

So I spent this weekend exploring SlimDX and DirectX in general. Why SlimDX and DirectX instead of XNA? XNA is cool and all, but if you've got no content to draw then it's not very interesting. So I thought I'd write myself some tools to start with, and brush up on my C# and DirectX knowledge along the way.

I started with the SlimDX tutorials (which are kind of oddly written, but easy enough to follow) and was happy to see my very first DirectX triangle in years. The last time I had played with DirectX was when DirectX 9 was shiny and new, and that was long before I understood the math that mapped that triangle to the screen. But now I do, and thus the next logical step was writting some camera class to manage that math for me.

In visualization, the most common tool for this is an arcball camera. Everyone uses an arcball camera, and conceptually it's pretty damn easy. Perfect first 'project' in C# and DirectX. Took about an hour (where in the DirectX docs can you find info on how constant buffers expect matrices to be laid out?) but after a lot of swearing and futzing, I had a nice, smooth arcball.

Of course, my cube (upgraded from the initial triangle) wasn't particularly interesting. Rather than do the most familiar thing and write a simple raycaster, I decided to try to do something more game related.and I wanted to draw a moel, but then I found out that Microsoft dropped model loading code in DirectX 10, and since I was targetting 11 for my tools, I was going to need to write my own.

But before that I would need some models to load. Thankfully, the DirectX 11 SDK comes with some, even if they're in the not-for-production-use SDKMesh format. I decided to write a loader for SDKMesh files anyway -- it'd be good C# practice.

First off, let me just say that the MSDN description of a SDKMesh file is useless. If they had listed the types and byte offsets of the members of their structures then it would have been easy, but alas I spent most of my time poking around SDK example projects and hitting F12. I also got a healty refresher on C/C++ struct layout guarentees -- the one where the compiler will lay them out as it pleases.

All in all, it took much longer than I had thought it would, but I did finally get it working. Granted, I did waste a bit of time by porting the DDS without D3DX example because I couldn't find where SlimDX had put the stuff, but hey, now I've got a separate DDS loader just in case. Next up is a crash course on HLSL I guess, then some ironing out of the actual Tactical RPG game design and data formats.

New Website and Plans! (Not April Fools)

Alright. Let's get this started. I've been long enough without a proper website, and without a proper log of my explorations. I can't guarentee that what will be written here will be interesting or useful, but I'm going to post here anyway!

While I think my previous layout and design was all well and good, it was still contained an undeniable amount of suck. The design was a (failed) attempt at being clever. This time, rather than spend an inordinate amount of time and its layout and looks, I'll let those who've done it better show me the way so I can focus on actually filling it.

Plans! Man do I have plans. I'm really going to work on that tactical RPG this time. Last try with Qt and C++, I got a dog to move across an ugly heightmap. It was rather poorly designed and thought out. Afterall, why start from scracth when an apparently new era has dawned: the era of game frameworks. I considered three: Unity, UDK, and XNA, and ended up choosing XNA. Why?

Mainly because XNA was the most barebones of the three. Unity and UDK are both full featured customizable engines that really only need some scripting and content before you've got a full-fledged game. They come with tools, their own pre-defined pipelines, and rendering systems. Granted, these can all be customized to your liking through their scripting interfaces, but the whole point of this exercise was to learn the inner workings of a game engine! With Unity and UDK, the engine is already there. You're just building a game around it.

XNA is a little different. It's a framework for building game engines, rather than being a framework for building games. All it really provides is a barebones game loop and a bunch of boilerplate utility classes. It's exactly what I'm looking for, really. Also it has the additional benefit that I get to learn some C#, which I've oooed and ahhed at in the past but never really gotten a chance to actually use. However, this also means I'll have to write my own toolset for my game, and that's a daunting task in its own right. But I've been toying with SlimDX, and so I get to do more C#! Ooos and Ahhs all around.

Of course, aside from that I still have to finish the rest of this site. And apply for more jobs. Weee.