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.

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.