Category: Managed DirectX

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 http://msdn.com/directx/sdk.

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).

Stacks!

So I have a buddy that recently embarked on a new adventure that could be quite thrilling.  Ok, so he got a new job.  Now, i’ve had friends get new jobs before, so what makes me go decide to talk about this one?  Simple, he is now working for the company doing Stacks Poker.

Oh, I guess it helps to mention that Stacks Poker uses Managed DirectX thus the reasoning behind my interest.  As a matter of fact, they’re still hiring a person to do some MDX work, assuming you don’t mind working in Toronto. 🙂

Myself, I have an avid interest in poker, have tried a few online poker sites before, but considering I have more than an avid interest in Managed DirectX, you can rest assured I’ll be keeping an eye out on this one as well.  I’d recommend you do as well!

Known issues with Whidbey Managed DirectX

So, how is it that I can get scooped by my own information?  (Just kidding ZMan, I appreciate it!)

Anyway, two main known issues with the Whidbey MDX Beta.  First, it requires VS2005 Beta2.  Nothing later.  Those of you using RC0 will get “FileNotFound” exceptions when trying to load the assemblies.

Two, there is a large ‘chunk’ of D3DX that is ‘missing’ from the assembly due to a mistake on my part.  It is most certainly unintentional.  (Oh, and MatrixStack is a D3DX component too, despite it being in the Microsoft.DirectX namespace).

We are working on getting these issues addressed as quickly as possible.  One of the benefits of releasing every other month though is no matter what, you don’t have *that* long to wait for updates.  Please keep the feedback coming, particularly on design issues, but on anything you feel the need to tell me about.

Whidbey Managed DirectX

The October SDK release is now available and (if you read ZMan’s blog, you already know) it includes the first beta of the Managed DirectX for the 2.0 CLR.  I’m extremely interested in your feedback on this, particularly design decisions that were made, what you think should have been done, etc.
Here is the information from our “announcement” internally:
The DirectX® Team is pleased to announce the next release of the DirectX 9.0 SDK Update (October 2005)
The October 2005 update includes the first release of XInput, beta releases of XACT, Managed DirectX for Whidbey, several new samples, as well as the usual slew of bug fixes and documentation updates.
XInput API
This new SDK optional component allows applications to use the Xbox 360 Controller for Windows.  Controller input, vibration effects, and voice input/output are supported.  Several samples are included that introduce the API and features of the controller.
Microsoft Cross-Platform Audio Creation Tool (XACT Beta)
XACT is an audio design tool and runtime that allows application developers and audio content designers to create vibrant sound in games.  Samples are included demonstrating features such as cues, streaming, and auditioning.
10-Foot Experience Updates
The article covering topics related to games on Windows XP Media Center Edition 2005 has been updated to help you make your game more accessible within the Media Center interface.  Two new samples, MCELauncher and MediaCenterGame, have been added to illustrate best practices as well.
Graphics Card Capabilities
A chart, in Adobe PDF and Microsoft Excel formats, containing a collection of capabilities exposed by current drivers on a wide range of graphics hardware is now available in the SDK.
Simple2D
This Managed DirectX sample demonstrates several basic 2D techniques including scrolling and sprites using Direct3D.
DxOps Batch Processing Tool
The DxOps tool is a command-line tool that allows you to do common mesh and texture processing using simple scripts.
Managed DirectX for Whidbey (Beta)
This is the first release of Managed DirectX with support for the Common Language Runtime (CLR) 2.0.  In addition to addressing issues related to using Managed DirectX with Microsoft Visual Studio 2005, it includes new features that take advantage of CLR 2.0.  Support for Direct3D, D3DX, DirectSound, DirectInput, and XInput are included in this release.
There have been no updates to D3DX or PIX for Windows in this release.

Way to go Aaron!

Saw this post on the newsgroups, and I got a kick out of both the story and the little game Aaron wrote.  Hopefully this post doesn’t give him ‘too much’ publicity.. =)

(Oh, and Aaron, my feedback is ‘nice job’ in the short time you worked on it.. I got a kick out of it.. I’ll add gamepad support to it because games like that are just too clunky on a keyboard. =)  I hope your girlfriend was proud. )

From his post:

Hey I just wanted to post a link to a 2D game I made using Managed
DirectX in C#. Its a side scroller like Super Mario brothers, comes
with the source and everything you need to run it minus of course
DirectX and the .NET framework.

I have to say it looks pretty sweet and runs very well on decent
graphics cards and computers. But I have seen problems on older cards
with some textures. Definitly its a bit of a hog since it was my first
attempt at Managed DirectX, and is probably a bit inefficent. So keep
in mind its not the best code. But it should get people started if
they are looking to do a 2D game.

I did this game for my girlfriends birthday so it isn’t something I am
really actively maintaining or anything, but I am hoping to hear
feedback, positive, negative, or otherwise. And if people learn from
my code, I figure thats all the better.

Aaron

Blog entry on this:
http://theshellandcactus.blogspot.com/2005/09/texas-quest.html

Link to download the game and source:
http://www.savefile.com/files/5349900

Managed DirectX Game Engine..

I just got an email from the folks @ Suva Interactive, and it seems they have a game engine using exclusively managed code and MDX in particular.

I haven’t had enough time to actually look at it in depth, but it looks promising from what I did see.  Seems they entered it into the CSD competition recently, hopefully they did well in that!

I’d recommend checking it out..

Professional Game Developers use Managed DirectX?

Check out the video that David Weller did with Steve Lacey, the graphics lead for Flight Simulator.

About 3/4 through the video his comments:

“The Managed DirectX stuff these days is a great starting point, and for a lot of people a great finishing point as well for shipping titles.”

and

“We internally in the flight sim team use Manage DirectX in a lot of our tools”

Always nice to see the professionals enjoying our stuff.  Now just wait until they see the upcoming Whidbey stuff. =)