Tag Archives: directx 10

Fire Walk With Me

Over the last week I’ve been carefully balancing working on adding HDR rendering to Rawr along with watching the first and only two seasons of Twin Peaks. It’s hard to judge a show like that, on the whole, because while the first, say, sixteen-seventeen episodes are absolutely remarkable in just about every sense, the episodes leading up to the series finale ping pong back-and-forth between awful and passable. What is even more interesting, as an enormous fan of David Lynch, is the pure, focused power that he can have on any episode which he takes a part in. His abilities as a writer are second only to his numerous abilities as a director. There are instances where Lynch clearly conveys an emotion in the scenes he directs to remarkable effect. The viewer reaction to his work are generally polarized in the sense that people either thoroughly dislike or completely love it, but it’s hard to deny the man’s auteur-like status as a filmmaker.

I believe that it’s pretty clear that I take an interest in storytelling in both games, literature, and film, but something that I generally don’t discuss all that much is my interest in the power that a visually well-constructed scene can have on a viewer or gamer. One of the reasons that I enjoy the things that directors like Steven Spielberg and David Lynch is that they both possess a very clear and thorough knowledge of what “looks good” for a given scene. For Spielberg, I think this concept is best presented recently in Minority Report and Saving Private Ryan. The use of color is so ingrained into David Lynch’s work that it’s difficult not to spot it in any given title; he frames a scene using a very specific and carefully-chosen color palette generally set against a very contrasting backdrop to provoke a subtle emotion in the viewers without any action taken on the part of the actors. Just take a look at the image below for an idea:

There is a very definite, consistent color palette that the entire scene draws from all set against a crimson red background atop a very jarring floor pattern. The entirety of the composition, especially in context, has absolutely no soothing qualities about it. Even without the presence of the midget who, for those that haven’t seen the show, consistently dances and talks in a spoken-backwards-but-processed-so-it-comes-out-forward-spoken kind of way.

I actually meant to discuss the HDR rendering, but I’ll save those details for another post. In the meantime here’s a screenshot:

Of DirectX and D3DX

I’m certain that I’ve written about this back in the days of yore but, slowly, as time went on, I actually began to trust and even like using the Direct D3DX utilities in my own codebase. I have generally only relied on the matrix, vector, and quaternion functionality early on in developing a codebase simply to the reliability of knowing that the D3DX math routines are fool-proof as opposed to the routines I could write on my own that may do something stupid like CVector::CVector( float x, float y, float z ) { x = x; y = y; z = z; } or something along those lines. Early on in the development of any engine or framework the kind of functionality that D3DX grants to programmers is incredibly useful as a launching point.

In the past my complaints about D3DX were that it was an unnecessarily bloated aspect of the DirectX SDK that contained some features which, really, should have been part of the core SDK from the beginning. For the most part, this complaint has been rendered completely invalid as of DirectX 10. The most notable inclusion in the core SDK from D3DX is that the shader compiler has been moved to the core runtime from its previous position in D3DX. In fact, as of now, it seems that the D3DX functionality in DirectX 10 has been vastly trimmed down from DirectX 9. The most-frequently used functionality is still present such as file importers (mesh and image) and math routines but, other than that (unless the documentation is just lacking), the D3DX library seems to be far more skeletal than it was under DX9.

The functionality migration from D3DX9 to D3DX10 is a cause for great happiness for me. Some of the routines that were present in D3DX9 do still exist in some capacity, as it has now been moved over to the DirectX Utility Toolkit (DXUT), but, most importantly, they’re not in D3DX or the core API. This move seems to indicate that D3DX has become more of a staple of the SDK than it was originally intended to be. When I started doing research on the file specifications for the X format the frequent reliance on D3DX became more apparent then I’d ever realized. Most of the code snippet or article that I found focused solely on using the format alongside the D3DX9 functionality that existed. The resources that didn’t use D3DX, instead, used IDirectXFile to parse the data as-necessary (this interface has now been deprecated). What’s more unfortunate is that some of these resources were actual published books and the contents of these articles are, as of DX10, fairly useless.

My disdain for prolific use of D3DX in any setting outside test cases for new codebases is most likely a result of my preference as a programmer to always use code that I don’t have to treat as a mystical black box. I like knowing not only what is going on underneath the hood of functions or classes but, also, to be have the option to optimize the code or erase extraneous functionality which is of no use to me. I have always been of this mindset as a programmer and, despite my recent tendency to actually rely on the D3DX math utilities, I don’t see that changing of my own volition.

TL;DR – I don’t like the frequent use of D3DX and I like the changes DirectX 10 introduces in relation to it.

Skin and Bones

It’s no coincidence that I haven’t made a real dev journal entry since September 7 since that is about when class (my last class evar, even) started up. Since then my weekdays have been pretty filled with a combination of class, work, and homework so I haven’t been able to make much progress on my hobby project (Rawr). With the class winding down now, though, I’m starting to make progress on the framework again and, along with that, I’m getting back into the habit of updating this little fella more often.

My first task upon opening up the Rawr solution in Visual Studio 2008 (yay upgrade) was to try and fix the issues that were plaguing poor Boney. My main problem with fixing the skeletal animation code is that, for one thing, my understanding of skeletal animation is pretty barren. The other thing is that, to the best of my understanding, I adhered to the MD5 format specs that I was going off of through the code-writing process very closely. I couldn’t figure out what would be causing the animation to look so wonky. So I did what I always do when I need to fix something that I’m clueless about: I play with things until I hit a segment of code that seems to directly impact what I’m trying to change. This process led to Boney as envisioned by Picasso:

For a bit of a break from those precious thirty minutes of work I spent on Boney spread across five days I figured I’d write up an X format file importer since that seems like a neat thing to do at the time. This format is a complete and utter pain in the ass to load in outside of D3DX and IDirectXFile. If I’m feeling particularly verbose and bored at some point the future I’ll probably write up an article about my experiences with it, but I’m not really expecting such a time to ever exist. Here some screenshots from the rendering experiences with tiny.x after I had the file reading in correctly:

As far as I can tell, I have a serious case of long-term ADD. After a couple of days of working with the X format and getting the basic mesh rendering correctly I jumped back to getting Boney’s skeletal animation to a workable state. Following a suggestion from jpetrie I added some code to render mesh bones/joints along with the mesh itself and it seems fairly obvious now what I’ll have to fix when I get home later tonight:

Of Bioshock and MxM Blocks

Well, it’s been a couple weeks, but I’m now fairly established in the new apartment and it’s absolutely fantastic. Though, aside from the move, the main other reason for the lack updates has, of course, been Bioshock, which is far and away the best game I’ve played in recent months

The Bioshock thing brings me to my first point. I think that the one of the reasons that the game is as good as it is and is getting such a massive number of glowing reviews is that Bioshock has such a well-defined atmosphere. Sure, the graphics are great, the audio is fantastic, and the gameplay is good, but the thing that puts Bioshock ahead of the competition is that Irrational2k Boston has used the engine to really flesh out the world of Rapture. The stuck-in-time mood in Bioshock is handled well; the music that plays on jukeboxes and in bars throughout the game has a very 40′s-50′s scratchy record sound to it, the basic weapons are a six-shooter, a Tommy gun, and a big, bulky shotgun, the monitors throughout Rapture are all fuzzy black-and-white, and the list of things goes on. The atmosphere created in-game is, in my opinion, the reason for the game’s critical success thus far.

Anyway, that was my little bit about Bioshock in, what I have no doubt is, a completely incomprehensible little paragraph. This is what happens when I try writing things in between build times.

As far as the progress on Rawr, things are going slowly — I started up development again a couple days ago and have just been working on the framework for the terrain implementation that I started a couple weeks ago. Once I’m done with the terrain implementation, which I assume I will be able to make some very nice headway on over the course of the extended weekend, I think I’m going to resume work on some more framework-critical components; the terrain implementation is primarily a way to get a good visual representation of what a full scene should look like (as opposed to basing my visual results on nothing but an anorexic mesh). So far, this idea has already proven useful when I got the basic MxM vertex block rendering in-game (below); I realized that the reason my camera had been giving me such time had nothing to do with the actual camera code, but the fact that the model that I thought was positioned up-right was, in fact, titled 90 degrees along the X-plane. So, yeah, I went through four camera code iterations thinking that it wasn’t handling FPS-like movement the way I wanted when, in fact, it was doing fine, my sense of orientation was just screwy. Yay.

Still With the Every Dev-Day Thing

I’m still going with the dev journal entry for every day of actual development I do on this little project affectionately titled Rawr. Today was a sad day. Why was today a sad day, you may ask. Well, today was a sad day because I spent three hours struggling with that goddamn mouse. At first, the goal was to capture the mouse/stylus for the window (::SetCapture( HWND )), because it seemed like the right way to go about dealing with continuous movement. The beginning of this capture was set off whenever the left mouse button was held down and then released whenever the left mouse button was caught in a non-down state.

If you’ve ever actually tried organizing this inside of a message handler in the scheme of what seems like a “Good Design,” then I’m sure you understand the problem here. The problem being that, at least in my case, the actual code which processed (relied on, dealt with, so on) was not, in fact, in the message handler. So there was this flood of input being gathered and the app had nothing much to do with it. It was around this point, which took far longer than it really should have to arrive at, that I realized I might have to violate the original design a bit to include some functionality for capturing the mouse in a window and holding the cursor to the center of the screen. I ended up with a “fake capture” — so I’ll still send the framework-wide flag that the mouse had been captured and various components could do their thing, the cursor graphic would be hidden by the OS, and the cursor position would continually be set to the center of the window after I nabbed the delta position from the frame prior.

I know I’ve done all this stuff before. At least, I think I have. In retrospect, I may have just looked at example programs and thought “Oh. Hey. This works. I’ll just liberate this snippet.” Such a course of action is, of course, not acceptable under my current coding laws for Rawr.

None of this stuff makes for a good screenshot and the camera code I’m working on isn’t to the point where I can actually move around a scene in a “correct” free-fly first-person camera fashion, so here’s a comparison shot between an MD5 mesh from DOOM 3 being lit by vertex normals (on the left) and by a normal map (on the non-left):

The Beginnings of the Rawr Framework

On Friday night I made the decision that I would stop using the DXUT routines for my little Direct3D 10 sandbox that was beginning to evolve into a legitimate code toolset for me. And any legitimate code toolset — well, even a lot of the illegitimate code bases — does not touch DXUT with a ten-foot electrified pole. DXUT is like an e-mail from an a spammer claiming to be an ex-girlfriend which, upon opening of this byteified letter, actually gives you, the user, a sexually transmitted disease.

Anyway, it took a couple of days, but I coded up and rewrote sections of the code base which I had been working off of lately. As of now, on Sunday night, I am a tweaked camera-class away from being exactly where I was on Thursday. So whoo. It’s called Rawr (a name spawned from Drilian‘s fantastic suggestion). And this is the first thing I was greeted with after I finished a draft of the camera class (greatly influenced by the DXUT first-person class).

Did I mention that I can’t manipulate any aspect of the camera yet for some reason? Because I can’t. So thanks for the visuals, id. I hate you.

On Direct3D10 vs. Direct3D9

Confused Direct3D 10 Menfolks.

So, I’ve seen a whole bunch of posts railing against Direct3D 10 – specifically in regards with skepticism to the difference in visual quality between DirectX 9 and DirectX 10. So here’s a bit of information from what little tidbits I’ve gathered here and there in my little Direct3D 10 experiments.

First of all, I believe John Carmack is completely correct when he believes that the potential in Direct3D 9 has yet to be maxed out. Also, I believe that the current belief amongst developers is that there is, at this point in time, very little Direct3D 10 can do that Direct3d 9 can not do. I fully believe that the kinds of DirectX 10-only features that you’ll be seeing in games like Company of Heroes, World in Conflict, Crysis, Hellgate: London, and other games are completely do-able in Direct3D 9.

This all said, Direct3D 10 is an API that has been completely overhauled from its predecessor. As a developer, it is taking me a bit more time than I’d care to admit to adapt the syntactical differences present in the DirectX 10 SDK. The TL;DR version of the differences between the two APIs are as follows: DirectX 10 has, for all intents and purposes, completely ditches the fixed-function pipeline. In lay man’s terms, this means that Shaders Are King. Instead of having a fairly strict graphic pipeline (think a “one size fits all” approach to graphics rendering), things are now completely programmable. A slightly inaccurate, though simplistic, look at things is that geometry first goes through a Vertex Shader (which performs operations on a per-vertex basis), then through a Geometry Shader (a DirectX 10/Shader Model 4.0 exclusive feature) which performs operations on a polygon/triangle level. Then, the data is rasterized to a pixel form where Pixel Shader performs its operations (things like bloom, depth of field, blurring are done here). After those major three steps, you see the result on your monitor. With Direct3D 10 (and, to a lesser and not guaranteed extent, Direct3D 9) the developer has complete control over what occurs during these steps, as opposed to it being dictated by the API.

Another couple important consideration is that, with D3D10, the graphics device is viewed as a shared system resource — Direct3D does not have a monopoly over its use. The best example of this point is the Windows Vista Aero theme, which relies on DirectX for its rendering. When you launch a game, you may see the game disable the “pretty Aero” (because it has that capability) through the duration of its lifetime; when the game ends, the “pretty Aero” will pop back up, and this all occurs through the API. The game isn’t doing anything dirty like modifying your OS settings or anything.

My personal favorite feature of Direct3D 10, though, is that there is a guaranteed set of functionality which the programmer can exploit so long as the end user’s computer is capable of using D3D10. With previous versions of Direct3D, the programmer had to query various aspects of the graphics card through the D3DCAPS system. The CAPS system would tell the developer if, say, the graphics card supported dynamic textures, if it could create shareable resources, if it could automatically generate mipmaps, and so on. It was a pain in the ass. With D3D10, though, there’s always that guaranteed layer of functionality.

So, basically, while the difference in visual quality difference between DirectX 9 and DirectX 10 may be near-nothing right now — and I believe that the games which heavily market the differences in their 9/10 renderers is pure hypespeak — the point to remember is that D3D10 is an overhauled API from DX9 for a reason. This reason is that it brings a far more powerful, safe, and guaranteed set of features to the developer for the developer to go nuts with.

Carmacks Quakecon 2007 Keynote: http://www.quakeunity.com/file=2513
For More: An Overview of Microsoft’s Direct3D 10 API.