Back in February when Vista was first released, I installed it on my computer at the time thinking about the marvelous joy it would be to have such a sexy new OS after years upon years of using Windows XP. This system was an AMD 3500+ with a 256mb Geforce 6800GT equipped with a nice, round, 2GB of DDR400 RAM. My at-the-time system really did not play well with the new Vista friend which was forced upon it, and I was forced to uninstall Vista after my ol' buddy had finally said "Screw you" to the software upgrade. I was content to stay with Windows XP from that point forward. This stance did, as stances have a tendency to do, change when I upgraded my system to an Intel C2D E6600, 640mb 8800GTS, and 2GB of DDR2-800 RAM. So, a month or so ago, I finally bit the proverbial bullet and installed Vista Ultimate on to that machine, and it has been happy days ever since.
A few weeks ago, I decided that a good use of my free time would be to start playing with Direct3D 10 -- I mean, I had the hardware to support it and I was already running Vista, so why not use my time off of my game programming job to program more game-related things. So, over the course of the last couple weeks, I've been laying the basis for a Direct3D 9/10 demo/game framework so that, once it gets to a usable point, I can start working on short 48/72-hour games or something of the sort every now and again. But, that's a ways away.
Currently, the framework has temporary OS hooks through the DXUT, and let me put this following sentence very carefully: DXUT should burn in a fiery car wreck from which there is no possible recovery. My first experiments with it a few months ago were all centered around DirectX 9, but since the addition of DirectX 10 to the SDK and DXUT being primarily centered around the use of 10, the framework has gotten convoluted in a great deal of ways. The basic application setup and event managers are alright, and the camera is a nice addition for a quick-use solution to view management, but the documentation surrounding the DXUT is nothing short of abysmal. The DXUT tutorial documentation, at least for the DirectX 10-related tutorials, is out-of-date to the point where it refers to DXUT classes that haven't existed for months; the snippets of documentation where an argument or two has been added to a function call exist frequently, but those are far less of an issue. The odd thing, in my mind, is that the documentation remains out-of-date, yet the accompanying source files for the tutorials remain up-to-date.
DXUT woes on record and out of the way, I have nothing but positive things to say about Direct3D 10. The transition from DirectX 9 to DirectX 10 isn't exactly a smooth one due to the fact that the API has been heavily restructured (due in large part, no doubt, to the removal of the fixed-function pipeline), but once I got over the differences in the API syntax, things began to move a great deal smoother. For the last week I've been working on writing a series of input layout (vertex declarations, basically), vertex/index buffer, and effect wrappers so that, when I go back and start writing the Direct3D 9 fallback code routines, the actual API rendering code will be easily tweaked without having to change any of the code that actually relies on it -- pretty standard practice, except unlike the last time I worked on an API-independent abstraction layer I loaded in the specific API routines through a DLL, and I'd really like to avoid that approach this time around (though, practically, I think it may be one of the best ways to handle the necessary functionality).
To be fairly honest, the progress on this little framework was at a crawl up until I stumbled upon a random image in the GameDev.net IOTD gallery. I saw this image, which made some of the DOOM 3 models that I remembered so fondly from the game look absolutely spectacular, and suddenly I had more motivation to get to work on this framework than I had since I first started working on it. I was gone at my house up north all weekend but, as soon as I got back to Ann Arbor, I started work on an MD5 loader which, as of now, is about halfway finished. I've written so many mesh loaders over the course of the last six years that the idea of writing an MD5 loader was incredibly boring, so to make the whole endeavor slightly more interesting for me, I vowed to write the whole thing using nothing but C++-style I/O -- I had used the C-style of I/O for every loader I've written in the past that I figured I'd give the C++ method a shot. And, now that I have most of the MD5 mesh file (not the animation files yet) loaded in through use of std::ifstream I can only assume that I was completely high, drunk, exhausted, and delirious when I thought it would be a good exercise to use the C++ method. The code ended up being so ugly that I could only sit back and think "Damn." And then I laughed, because it looked so ugly and unnecessarily complicated that I could paste snippets to a code-paste somewhere and show it to people and laugh at their inability to understand it and thus feel better about myself.
So, really, a huge victory. I'll post some screenshots when I finish up the loader when I get some more spare time this week (most likely this weekend). In the meantime, here's a picture of a bunny from another mesh loader in the project (and then the rest of my home workspace):
I will, as per my usual course of action, release all of the source code to the framework and everything else related to this current project at some point, but that point won't be very soon, since I want things to be in a relatively decent state when I put them up somewhere. I was planning on putting more of my thoughts about Direct3D 10 in here, but I think that will warrant its own article at some future point in time.
He is currently shaded with "Snow White during a snowstorm" technology. Only supported in Shader Model 4.0.