"The extremists are running the country because the moderates got shit to do."
- John Stewart
More pages: 1 ... 6 7 8 9 10 11 12 13 14 15 16 ... 21 ... 31 ... 41 ... 47
Mac as a gaming platform
Wednesday, March 10, 2010 | Permalink

Recently Valve announced that they will not just deliver Steam on Mac, but also a bunch of actual games for the Mac platform. Even though I'm a PC guy I find this to be excellent news. We need competition in the OS market, and one of the main reasons many people stay on the Windows platform is because it's the only viable platform for gaming. With a heavy-weighter like Valve giving Mac full attention, it could really change that. I don't think every developer will follow, but I think it will mean a substantial increase in games available on the Mac. Another side effect of this is that OpenGL will again become an important API. No bold new initiative from Khronos could ever make the same kind of impact as having Steam and popular games on the Mac platform. I think this is also good news for PC gamers, because it expands that gaming audience on computers. I wish Valve all the success on the Mac platform.

[ 15 comments | Last comment by mark (2010-04-12 23:03:29) ]

Just Cause 2 demo
Friday, March 5, 2010 | Permalink

I didn't get time to post this yesterday, because, well, I was busy playing the demo myself. But anyway, the demo is out for your favorite platform. Personally I like PC, so get it from Steam here.

Whether you already played the demo or not it's worth watching the new demo trailer.

If you're not tired of Just Cause 2 videos yet, the Nvidia added features for the PC version is a recommended view too.

[ 5 comments | Last comment by mark (2010-03-31 04:27:31) ]

Just Cause 2 is DX10 only
Friday, February 26, 2010 | Permalink

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.

In related news, the demo will be available on March 4 for all platforms.

[ 18 comments | Last comment by Xop (2010-03-21 15:03:41) ]

New gallery
Wednesday, February 24, 2010 | Permalink

I have added another gallery with pictures from early summer 2009. Back to my regular schedule of being about half a year behind with my pictures I guess.

[ 1 comments | Last comment by Josh -yosh64 (2010-02-26 01:12:20) ]

Whoha, I found a compiler bug
Thursday, February 18, 2010 | Permalink

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():

mov eax, dword ptr [ebx+9D0h]
push eax
push ecx
mov eax, esp
mov dword ptr [eax], 0
mov dword ptr [eax], 54h
mov dword ptr [eax], 541514h
mov dword ptr [eax], 29C53055h
mov dword ptr [eax], 77DBE55Eh
mov dword ptr [eax], 647B726Bh
mov dword ptr [eax], 2CCC28C8h
mov dword ptr [eax], 2F060985h
mov dword ptr [eax], 9C015834h
mov dword ptr [eax], 0BC88B513h
mov dword ptr [eax], 1AB79019h
mov dword ptr [eax], 23457696h
mov dword ptr [eax], 24AE2F4Ch
mov dword ptr [eax], 3629A415h
mov dword ptr [eax], 0F8546197h
mov dword ptr [eax], 7E5B047Ch
mov dword ptr [eax], 1CE21AF8h
mov dword ptr [eax], 369CA37Ah
mov dword ptr [eax], 14063B6Fh
mov dword ptr [eax], 28F7A0BFh
push esi
mov dword ptr [eax], 0B5AF8F68h
call Context::SetConstantBuffer (404750h)

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:

StringHash(const char (&str)[4])
    uint32 hash0 = 0;
    uint32 hash1 = hash0 * 65599 + str[0];
    uint32 hash2 = hash1 * 65599 + str[1];
    m_Hash = hash2 * 65599 + str[2];

[ 9 comments | Last comment by Aslan Dzodzikov (2010-05-14 18:43:42) ]

DirectX SDK February 2010 is out
Saturday, February 6, 2010 | Permalink

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.

[ 1 comments | Last comment by Seth (2010-02-08 04:06:37) ]

Vehicular Stunts Developer Diary HD
Sunday, December 6, 2009 | Permalink

More Just Cause 2 material has hit the web. Well worth checking out.

Also, the game also got an official release date recently. It will be available in March 23 in North American and March 26 elsewhere.

[ 7 comments | Last comment by john cooper (2010-01-25 14:51:35) ]

Framework4 update
Thursday, November 5, 2009 | Permalink

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:

StringHash(const char (&str)[2]);
StringHash(const char (&str)[3]);
StringHash(const char (&str)[4]);
StringHash(const char (&str)[5]);
StringHash(const char (&str)[21]);

This covers all strings up to 20 characters, which should be enough for resource names. Each constructor contains the unrolled code for generating the hash, for instance:

StringHash(const char (&str)[4])
    m_Hash = 0;
    m_Hash = m_Hash * 65599 + str[0];
    m_Hash = m_Hash * 65599 + str[1];
    m_Hash = m_Hash * 65599 + str[2];

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.

[ 27 comments | Last comment by Aslan Dzodzikov (2011-05-20 14:31:13) ]

More pages: 1 ... 6 7 8 9 10 11 12 13 14 15 16 ... 21 ... 31 ... 41 ... 47