Alas, How Plans Change

My goodness it's been forever. Shortly after finishing my C# SDKMesh implementation, work picked up and I found myself without the time to do any SlimDX.

Since then, however, plans have changed. Instead of building from the ground up in C#, I've gone back to C++. I'm still sticking with DirectX and I've found that it really isn't very different from OpenGL. All the ideas are the same. It's just that D3D organizes things more in-line with how the pipeline works, and takes a more object-oriented approach.

But I haven't even gotten to DirectX yet, really. Instead, I've been working on the innards of the engine, such as the event system or the input system or job system or resource management. All the little things that you need in order to build yourself a nice, usable game. The basics are mostly working, I just need to finish up the base logic layer and implement a simple scene graph before I can draw myself a picture. I think it's better this way really -- I don't have much trouble in the drawing pictures area, but I don't have much practice mucking about in the other game engine subsystems.

Also C++11 is nice. Really nice. I really like lambdas and the new smart pointers. How did I used to live without shared_ptr and unique_ptr? Of course, shared_ptr and unique_ptr have their own set of problems, but it's certainly better than trying to keep track of everything on your own.

I've gotten to about 5,000 lines of code since May. That's pretty good I think, considering the fact that I only really get to work on this at night. I'm getting really close to where I can draw a picture and have some controlled model waltz about. But I'm still trying to decide which LUA/C++ binder to use, and how to best incorporate it into my engine. I definitely want scripting, but I'm not sure exactly where it should fit in. Also I need to re-evaluate my components system. I'd like it to be flexible without being a PITA to use, but right now it's neither flexible nor easy to use.

Also the idea of Tactical RPG has been shelved. I've decided it's just not a realistic goal for a first game. Instead, my goal is now....MARBLE MADNESS! I had completely forgotten about that game until I saw a speed-run linked on reddit. I remember trying for ages to beat that game as a kid, but apparently the game is only like 5 minutes long if you play correctly. I don't even know for sure if I beat it back then.

Anyway, Marble Madness would make a great showcase game. It's one of those games where you can make everything pretty for the hell of it. Marbles? Show off reflections, refractions, maybe even caustics. I can go crazy with the environments if I want, the original Marble Madness sure was. Marble Madness also has components that I would not really need to implement for a Tactical RPG, such as a physics system. All-in-all I think it's just a better choice for an initial goal.

Afterwards I can get back to trying to make a Tactical RPG. Until next time.

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.