Recently the min spec for Just Cause 2 was published and there has been quite a lot of attention to the fact that the game does not support Windows XP, which is simply due to the fact that it's a DX10 exclusive. The reaction has been everything from "awesome" to "stupid", depending on how you see it. Certainly it's a quite bold move given that not everyone has moved over to Vista/Win 7 yet. On the other hand, if you want something that's not just a simple console port, this is clearly the way to go. Going DX10 simply allowed us to a make a better game.

Anyway, I have seen some opinions of the sort "way to cut your potential customer base in half", often quoting the most recent Steam survey, which I wanted to address. If you look at the Steam survey more closely you'll see that it's not quite as bad. Currently 49% have DX10 systems. That doesn't mean a DX9 version would have brought the other 51% on-board. In the bottom end we have people on DX8 and earlier (5.66%). If there would be a DX9 version then for sure it would require at the very least shader model 3.0, so that cuts all 2.0 cards (3.84%). The Steam survey for some reason puts 2.0b and 3.0 in the same category, so some fraction of those would not be able to run the game either. So let's say that about 15% maybe in the bottom end would not be able to run the game anyway. So that makes it more like 49 percentage points vs. 36. So the cuts about 40% of the market. However, those numbers are still January numbers, and the trend with people migrating to Windows 7 is strong, so interpolate two months and another 4 percentage points will have moved up from Xp by the time the game is released. Another thing to consider is that people wanting to buy JC2 probably tend to be more likely to have made the switch to DX10 system anyway. Then there's of course all those people who will buy the game because it's a DX10 exclusive who might not have bought the game otherwise. Whether it all plays out favorable in the end will be interesting to see, but my gut feeling is that a great experience for a smaller audience is better than a medicore experience for the masses.

I gave Visual Studio 2010 RC a few quick runs and while doing so I noticed that it doesn't always generate optimal code with the StringHash code I mentioned recently. Often it behaves just like you expect and outputs the constant directly, but it happens that it generates some clearly suboptimal results. This is a call to Context::SetConstantBuffer():

Clearly there's a lot of superfluous writes that should have been optimized away. At first I thought this was a new bug in Visual Studio 2010, so I tried it in Visual Studio 2008 and it did the same thing. It's unclear why this happens, or what triggers this behavior, but I just noticed it happening in a certain location in my program.

So I rewrote the StringHash() constructor in this way, which appears to fix the problem:

The biggest news is that they have made some very nice improvements to PIX, such as much improved support for DX11, but also that we can finally view depth-stencil buffers in DX10/DX11 apps, a features that has been sorely missing for a long time. Also, compressed sRGB textures can now be viewed, which is something I have wished for very much during development of Just Cause 2 since we use these formats a lot.

Being able to switch to REF device is a very cool feature too. It's very good for debugging if you've been able to capture a graphical artifact that you suspect is a driver bug. By switching to REF and comparing you can see if it's due to the driver or something wrong with your code. Running your whole game through REF is usually not an option, but playing back a captured frame on the other hand is much more manageable.

I haven't mentioned the new framework I'm working on in a while, mostly because progress has been slow and I've been occupied with other things. Just wanted to give a brief mention of a neat trick I've implemented recently. In my framework I try to strike some kind of balance between ease of use and readability versus performance. Most of the time my demos are not very CPU heavy at all, so the CPU-side performance part isn't all that relevant, but it's always nice to have low overhead, just because it feels good. In Framework4 I've taken some steps to keep the overhead down. Something I usually do for readability is to set textures and other resources by name using strings, like so:

context->SetTexture("Tex", m_Texture);

This makes the code very readable and it's easy to see the mapping from the code to the shader. Unfortunately, lookups by a bunch of strcmp() is not the fastest way to find the corresponding texture unit index, even though it doesn't have to be terribly slow. A faster way is to use a precomputed hash value and do a lookup with that instead. I still want to use the same syntax though. What I ended up doing was changing const char * to StringHash, which is a class containing only a uint32 value, so for all practical purposes, it's a uint32 when compiled with optimizations. StringHash has loads of constructors. One for each length of the string I need, like so:

The hash function itself is not very important, I chose this one because it came up early on a google search. So when I make a SetTexture() call, I can call it with a constant string directly, which in C++ means it'll look for a way to convert the const char array to a StringHash, and finding a matching constructor it will use that to construct the StringHash object for me. Given the compile-time constant string and the simple unrolled code, any decent compiler will boil all this down to the resulting hash code when compiled with optimizations, and the runtime cost is essentially the same as if I would have written it like this:

context->SetTexture(0x29C22FA7, m_Texture);

A sneak peek at the assembly code we find the resulting hash inlined as an intermediate constant:

mov dword ptr [eax], 29C22FA7h
call Context::SetTexture

It will of course still be faster to just call SetTexture() with an index directly instead of the name, but this should narrow the gap somewhat.

Sorry for the lack of updates here lately, I haven't had much time to work on any of my personal projects or comment on the news flow. But another trailer from the game I'm working on has hit the web, so check it out.