December SDK Available.. Better late than never?

I blame my self-imposed umm.. isolation? while on vacation for the lack of a Dec SDK release announcement.  Since i’m so late and lazy now though, i’m just going to copy David’s post:

The Windows Graphics and Gaming Technology Team is proud to announce the latest version of the DirectX SDK, available for immediate download!

The latest SDK, as always, can be found at

So what’s new?  Well, some of the really cool additions and updates are:

– Direct3D 10 Technology Preview: That’s not a typo.  If you have Windows Vista, you’ll be thrilled to get your hands on this _very early_ preview of the new version of Direct3D.

– Microsoft Cross-Platform Audio Creation Tool (XACT Beta): Our audio geniuses are at it again.

– Managed DirectX for .NET Framework 2.0 (Beta): Much improved from October’s SDK, this new version includes support for the retail version of Visual Studio 2005 family of products.

– Windows Vista Game Explorer (Beta): “Getting your game on” takes on new meaning in Windows Vista.  Learn how to get your game integrated into the Game Explorer.

– DirectX Runtime: We’ve now created a cumulative redist to help you address some of the small (and not-so-small) annoyances with the runtime.  In addition, we now offer a web installer that will incrementally update your end user to the latest DirectX runtime libraries.

– XInput: New and improved, with an article included on how to use DirectInput and XInput together!

– Tools: PIX and DxErr have been improved

– Samples: New samples on HDR, as well as numerous additions to help you learn Direct3D 10, have been added.  Also returning by popular demand: the Pick sample.

– Technical Article Updates: We’ve added tons of new technical articles.  Find them all in the DirectX SDK Sample Browser.


Ok, I guess i’ll add a few of my own comments (specifically related to Managed DirectX 2.0 beta):

  • Now includes x64 ‘native’ support (for everything except XACT).
  • Now includes XACT
  • The majority of ‘missing’ API’s should no longer be ‘missing’.  (I don’t want to say all just in case i screwed up again)

Once again, please leave any feedback/questions/comments here on this post, contact me through this blog, or on the MSDN Forums. The forums will guarantee someone from MS (other than me) will also see it, and is probably the recommended place. Comments on missing APIs, bugs, confusion, etc are all welcome.

Oh, and while i’m thinking about it.. One of the more common pieces of feedback I’ve received is why the removal of taking a Windows Form control as the constructor for devices, etc.  Since this is something that most likely won’t be changing, i’ll speak briefly about it now.  Essentially, just by having that constructor in the code base, it forces System.Windows.Forms.dll to be loaded with our assembly (even if you don’t call it, due to more complicated reasons I won’t get into here).  Aside from the fact that this is a performance ‘burden’ on developers who aren’t using WinForms, a more pressing problem is that in the not too distant future, there will be components that we will need to work with that simply *will not work* if WinForms dependencies are found.  There are only two real ‘breaks’ with this change.  One, you can no longer simply use a form as your variable in the device constructor, and instead must use form.Handle.  This is extremely minor.  The other change which could cause more problems is the device will no longer reset on form resizes automagically when using the event model.  Since we recommend everyone use the DXMUT framework (which handles this ‘automatically’ anyway), we don’t consider this a major issue either.

Probably not quite what he intended..

I got an email recently from Phil Vaira about a new RPG he was working on.. So, like I normally do, I went and checked out the link.  What I found though was a new post detailing his ‘advice’ on native DX vs Managed DX.  Naturally, I read that as well.  What i’ve found is that it contains many misconceptions that seem to have been perpetuated throughout the last few years.

I agree with his sentiment that you use the right tool for the job.  It is (or should be) a no-brainer, but that goes well beyond game development, or even software development.  That should just be a ‘given’ in any facet of life.  I don’t agree with his implication that if you want game development to be a career you should stick to native code (while he didn’t directly say that, it was the implication I read with his ‘beneficial in the future’ comment).  The fact is, a large number of ‘professional’ game developers began their ‘career’ as a tools developer for a ‘real game’.  Care to guess what a large number of tools are written in?

He then goes on to ‘compare’ native Directx and Managed DirectX by using Call of Duty 2 (a brand new PC game) and Arena Wars (which doesn’t even use DirectX, much less Managed DirectX).  Now, the comparison here is wrong in so many ways, it’s hard to count.  First, the API’s aren’t even the same, which seems relatively important for comparing.. you know.. the APIs.  Second, he’s comparing a brand new game with one a couple years old.  Newer games invariably ‘look better’ as developers ‘mature’.  Thirdly, he’s comparing a game that has a multi-million dollar budget and a dedicated team of artists against one that was essentially done by a couple hobbyists (with no offense made to any hobbyists).  Lastly, he’s taken the assumption that because the one “looks better” it must “be better”.  Call of Duty 2 is a good game, I agree with that, but you know a game I think is better?  Katamari Damacy..  Find screenshots and I think most people will agree Call of Duty 2 “looks better”, but ‘looks’ doesn’t always mean better.

He then uses these assumptions to ascertain that Managed DirectX simply isn’t capable of creating something so ‘visually stunning’.  No basis for this conclusion other than the fact that he hasn’t seen it done.  He hasn’t seen a managed version of Call of Duty 2.  He then goes and mentions other games that have been released in the past, wondering why he’s never seen managed versions of those (nevermind the fact that Managed DX didn’t even *exist* when those games started development).  It should be plainly obvious that no development company who wants to make money would ‘waste’ so much resources by simultaneously developing two versions of their game *for the same platform*.  I also got a kick out of how he lets everyone know that you couldn’t make Morrowind in managed because “can’t get FPS where it should be” which implies that a) there is/was a managed version of Morrowind somewhere (how else would they know that) and b) he was involved in the development of that version.  Since I know a) isn’t true, i can infer that b) isn’t as well.

So anyway. For my conclusion, I’m not going to give any ‘advice’ on which is better.  Both native and managed versions of our API are fully capable of developing ‘modern’ games.  Both versions have pros and cons, and I agree with him that you should weigh these before making any decisions.  For myself?  I’d be happier if the majority of developers concentrated on making *good* games rather than ‘pretty’ games.. Regardless of what API they use.

BTW: I’ve been (am on) vacation for the holidays.  Thus my lack of activity here (even though there will be a series of posts today).