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.