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.


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.

MSDN                           http://msdn.microsoft.com/directx/sdk/

MS Download Center http://www.microsoft.com/downloads/details.aspx?FamilyId=1C8DC451-2DBE-4ECC-8C57-C52EEA50C20A&displaylang=en

Comments (20)
  1. bubu says:

    Whats the equivalent of TextureLoader.SaveToStream(ImageFileFormat.Dds, l_tex) in the new SDK?

    I want to save a texture to a DDS file using the october SDK with MDX, but I don’t see any "save" method…


  2. Mario says:

    I have not yet downloaded the new update, does Managed DirectX now support 64bit? Until now i have to build 32bit assemblies to get it to work.



  3. Shildrak says:

    Hmm, is there a way to get it working under vs2005 RC1? Its my main developing platform, so downgrading to beta2 is not really an option. Otherwise its no big deal, I’ll probably just wait it out until next (final?) release, which hopefully isnt too far behind nov 7 🙂

  4. zz says:


    From the readme:


    Known Issues with Pre-Release Managed DirectX for Whidbey

    There is no 64-bit support in Managed DirectX for this release and the 32-bit pre-release Whidbey managed DirectX samples crash on 64-bit Windows.

  5. G says:

    Thanks for all your efforts related to Managed DirectX! Tremendous.

    The one dll approach is good, especially if we must redist the entire MDX CAB anyway

    GraphicsBuffer approach seems O.K.

    Where are the animiation/hierarchy-related classes (AllocateHierarchy, AnimationController, AnimationRootFrame, BoneCombination, Frame, KeyframedAnimationSet, LoadUserData, MeshContainer, MeshData, SkinInformation, etc.)?

    Where are the PRT-related classes (PrtEngine, PrtCompressedBuffer, etc.)?

    Where are the DirectInput action-related classes (Action/ActionAttributesFlag/ActionFormat/BufferedDataCollection/etc.)? Please do not remove any DirectInput support until something comparable is available. XInput is useful but definitely not equivalent.

    Where are the SurfaceLoader, TextureLoader, Mesh.FromFile, etc. classes?

    Where are the Microsoft.DirectX.Diagnostics classes?

    Please do not spend time trying to trim DirectX functionality or guessing what functions developers will use. Just wrap them all (as was pretty much already done in the previous releases).

    Will/can you please (perhaps informally) release work-in-progress, non-redist snapshots of your MDX beta ASAP (just the microsoft.directx.dll compressed down to ~400KB is fine) more frequently than bimonthly … daily 😉 This will allow us to actually compile and test performance, etc. We will provide timely feedback.

    You really should run FxCop on the MDX assembly.

    When will there be support for 64-bit? What is the main issue here?

    When do you plan MDX for .NET 2.0 to be available as an official redist? Hopefully well before February 15th, 2006 … December release would be good.

    Slightly Unrelated:

    Does the (eventual) MDX redist really need the XML files? Can’t these just be in the SDK? Is the (2MB+) dsetup32.exe approach really necessary? Can the size of the setup (overhead) files be reduced? This increases online download size. Please pay more attention to online distribution of (small) MDX apps. Can Microsoft please host (on their servers) a "Latest D3DX and MDX (only)" setup configuration that end-users could download if they already have 9.0c? While redistribution is not a big deal for CD-ROM based titles, online titles are somewhat different.

    Thanks again

  6. bubu says:

    oh and how can I create directInput device using

    new Microsoft.DirectX.DirectInput.Device(Guid)

    if you removed the SystemGuid.Keyboard/Mouse ???

  7. Fabrizio Cerasa says:

    Will the 64 bit version available for December?

  8. What happened to LightType enum in the .NET 2.0 beta MDX assemblies? It appears the enum type is empty, meaning there is no way to create a point light, spot light, etc.

    Tom, am I missing something?

  9. In addition to the LightType enum, it appears the MatrixStack class is gone. Is there a replacement?

  10. Andreas Jung says:

    Ok, maybe this is a better place to give some feedback about the new October release.

    First of all, I am glad that you clean up MDX. Now it feels less like DirectX and more like .NET. It’s really an important step with C++/CLI being lined up.

    In order to save time, I stop now stating the good things, and continue with the things, that could need improvements.

    1) Looks like the DirectX::Direct3D::LightType issue has arrived already. I have posted this in the NG, but there wasn’t much of a reply.

    2) I have also posted an issue in the NG, stating that a StateBlock disposes when resizing the device-window. This is now fixed with the October release. (just for information-purpose).

    3) I have severe problems writing to dynamic (vertex-)buffers on a per-loop base. I have compiled a simple demo-app to demonstrate this behavior: http://www.aj-productions.de/pub/D3DBug_DynamicVB.cpp .

    To make it short, the key-aspect is following:

    // –> THIS ONE DOES _NOT_ WORK <–

    //buffer->Write( a );

    // –> THIS ONE DOES _NOT_ WORK <–

    //for each( DirectX::Direct3D::CustomVertex::PositionOnly v in a )

    // buffer->Write( v );

    // –> THIS ONE WORKS! <–

    for( int n = 0; n < a->Length; n++ )

    buffer[n] = a[n];

    So it looks like the functions are broken, while the default-accessor is functional.

    I must admint – however – that I don’t know wether my way of using the Vertex-Buffers is correct, since there is no documentation.

    I can use the default-accessor as a workaround, however I’d like to send all the vertices with one function-call using Write( T[] ).

    4) Why did you remove (Resource)->SetData? It was so flawless to use :). I guess it was not the cleanest solution, but it’s really one of the points that p*sses me most when porting my project, because the lock-call is so uncomfortable.

    Ok, I have now ported all my SetData calls to locks, so you don’t need to re-introduce SetData for me ;).

    5) The Microsoft::DirectX::Generic::GraphicsBuffer namespace heavily interferes with System::Collections::Generic namespace.

    My personal way of using namespaces is mostly something like this:

    using namespace System;

    using namespace System::Collections;

    using namespace System::DirectX;

    So my code looks mostly like this:

    Direct3D::Device^ device = …

    Generic::List<CustomVertex::PositionOnly>^ vertices = …


    Now when I want to declare a generic GraphicsBuffer, the DX-Generic-namespace heavily collides with the Collections::Generic namespace. This leads to the fact, that I need to resolve the Graphics-Buffer-type-name down to the Microsoft-namespace, i.e. Microsoft::DirectX::Generic::GraphicsBuffer.

    This issue has really a potential for collisions within large projects, as both namespaces are really important in everyday’s programming-life.

    Could you maybe consider to rename the class to something like GenericGraphicsBuffer and move it out of the ::Generic-namespace? (Though this is possibly not the .NET-conformest solution).

    6) DirectInput was heavily changed, as the interface was pretty much screwed up before. Although I still fight to figure out the October-equivalents, this looks like a good move to a way more clean interface.

    7) Although this is a bunch of extra-work: Would you consider to leave the deprecated classes in the debug-runtime for one release-cycle, and mark them with the Obsolete-attribute, where the String-argument of the Obsolete-attribute points to the new class/member. This would really help to port existing MDX-apps.

    8) Please do not remove DirectInput from DX like you did it with DirectShow. "Moving to Platform-SDK" has a different meaning for us managed developers [, developers, developers] (sorry, couldn’t resist).

    These are my experiences so far with porting an existing 0.5f-yearOld fulltime-hobby-project to MDX-October. I think it’s a good (and necessary) job you did with MDX. It’s just the little issue that my project is entirely screwed up at the moment (mainly due to the dynamic-buffer problem), though I think I can solve this. More feedback eventually later on.

    Finally, let me say, that the DX-team does a great job for the Win32 developers community. This ugly August/October-porting-job is still better than taking three seperate APIs for Graphics, Sound and Input with three different licenses, eventual manufacturer-dependencies such as with OpenGL, and managed C#-wrappers to be used within C++/CLI with OpenSource-licenses. Didn’t want to begin a war about OpenSource, it’s just my way of feeling comfortable with MDX – that’s why I use it.

  11. bubu says:

    When I try to paint a triangle in Win64, generates exceptions. I know you mentioned something in the docs about win64 samples will crash , but I wanna know if can paint just a simple triangle in win64 or is this version absolutely incompatible with win64 pls?

  12. abi says:

    Little feedback:

    I agree with Andreas Jung, I think MDX looks and feels much cleaner now. However, there was a lot of confusion with all this VS2005 Beta2/RC incompatibilty stuff and with all the changes without any solid documentation. I personally don’t care about changing and refactoring a little on the lower level. I’m just sad MDX .NET 2.0 doesn’t run with VS2005 RC. The idea putting everything in one Dll is also great! Haven’t checked out XInput, but it sounds cool.

    Few things, I would like to have for the December 2005 MDX:

    – Document that stuff ^^

    – Mark or remove methods, that just don’t work [yet?], it’s no fun to find out stuff like 3) from Andreas Jung.

    – Make it freaking run on VS 2005 final.

    – More samples? Since it isn’t very hard to port samples if everything works, I’m sure it wouldn’t be too hard. Maybe the community can help? ^^

  13. bubu says:

    Oh btw, I dont like at all the new GraphicsBuffer approach… Simple arrays were much intuitive and fast because GraphicsBuffer implies "copy"… See what I mean with an example:

    Old style:

    sVERTEX[] l_arrV = new sVERTEX[2];

    l_arrV[0].x = 1.0f; //direct value put,optimal

    l_arrV[0].y = 2.0f;

    l_arrV[1].x = 3.0f;

    l_arrV[1].y = 4.0f;


    New style:

    GraphicsBuffer<sVERTEX> l_gb = new GraphicsBuffer<sVERTEX>(2);

    sVERTEX l_sV = new sVERTEX();

    l_sV.x = 1.0f;

    l_sV.y = 2.0f;

    l_gb[0] = l_sV; //copyes value, time is spent

    l_sV.x = 3.0f;

    l_sV.y = 4.0f;

    l_gb[1] = l_sV;


    So as you can see, new approach takes more lines, requires to "copy" values from one struct to another and is not better at all.

  14. Lars Middendorf says:

    The new generic GraphicsBuffer is nice. But can you please add the possibility to wrap an array without copying the content ?

    Something like this.

    int[] indices=new int[[]{…}

    GraphicsBuffer<int> buffer=new GraphicsBuffer(indices);

    I know that I can get an IntPtr of the array with a pinned GCHandle but I fear that it would be too slow.

  15. Brandon Bloom says:

    I see all the equality methods have disappeared. I presume this is to prevent very common floating point equality issues. If this is true, can we get these methods back, but with an epsilon comparison? Preferably with an adjustable epsilon value.


    struct Vector3


    public static float EqualityEpsilon = 0.001;

    public static bool Equals(Vector3 lhs, Vector3 rhs)


    Vector3 difference = lhs – rhs;

    return difference.X < EqualityEpsilon && difference.Y < EqualityEpsilon && difference.Z < EqualityEpsilon;


    // … rest of Vector 3 here


  16. Br says:

    Is the EffectInstance struct "damaged"?

    WaveFormat.BlackAlign -> WaveFormat.BlockAlign (typo?)

  17. Chris Muench says:

    I see that some of the Class names in DSound have changed:

    Listener3D => now just Listener

    Listener3DSettings => now just ListenerSetting

    SecondaryBuffer => now simple buffer

    Makes sense! But no docu anywhere:-(

    Otherwise GREAT JOB! I really like the unification and clean structure.

    Does that mean the 3DX library is gone again?

  18. Chris Muench says:


    I just looked a little deeper in the changes you made from MDX1 to MDX2…You have change WAY too many calls, parameters and other "little" things….

    Of course you will say "its much better readable now" BUT WHO CARES!!!!! You just messed up cross-platform Development with all you .NET Compact Framework ISVs!

    MD3DM (Managed D3D Mobile) is shipping with VS2005 and you bomb them one month before Release with a totally incompatible verison of MDX!

    Are you not talking to these guys?

    Are you not looking outside your office that there is another world out there?

    No wonder nobody has shipped MDX games yet…first the mess with the sample frameworks (changing them in every release with no backwards compatilibity) and than "fixing" the APIs to be more "Whidbey Conform".

    Well, so much for some christmas games…back to the drawing board and figure out how to manage the two codepath…and looking forward to DX10 I see another path coming…and no help from your side.

    I still love MDX but its time you learn that you cannot mess with the interfaces if you want ISVs to ship apps/games at some point in time

    Chris Muench


  19. Derek says:

    I agree fully with Chris Muench. You’re making our company have horrible transitions from our previous code to the newest versions. Our next meeting is discussing the use of OpenGL for our next project. The truth is simple: we like Microsoft, but we can’t keep up with them.

Comments are closed.

Skip to main content