What would stop you from using Managed DirectX?

This is a question that is interesting in more ways than one.  One of the more common answers to this question i hear is naturally centered around performance, even though many times the person with the ‘fear’ of the performance hasn’t actually tried to see what types of performance they could get?  I would love to hear about specific areas where people have found the performance to be lacking, and the goals they’re trying to accomplish when hitting these ‘barriers’.

But above and beyond that, what other reasons would you have for not using Managed DirectX.  Do you think the working set is too high?  Do you not like the API design?  Do you just wish that feature ‘XYZ’ was supported, or supported in a different way? 

At the same time, what about the users who are using Managed DirectX currently.  What do you like, and why?

You can consider this my highly unscientific survey on the current state of the Managed DirectX runtime. =)

Comments (76)

  1. Chua Wen Ching says:

    I love managed directx. It save up my time rather to code unmanaged c++ directx.

    There is one problem. I do notice that in the Directx 9 sdk (latest one or the previous version), c++ had far more examples than c# or vb.net.

    Does it mean that c# or vb.net is lacking of something?

    Well at least it increase my curiousness over managed directx when i first used it!

    I do believe Directx 9 is far better than the previous older versions! Great job to Microsoft Directx Team.

    About performance, I can’t say much. I never done any huge 3d projects on managed directx, it looks okay to me on low scale 3d simulation.



    Chua Wen Ching :p

  2. LeighSword says:

    why we don’t using Managed DirectX?

    because the DirectX SDK help just for C++;

  3. Peter Koen says:


    We have tons of libraries build on C++ and 80×86 assembler, so we are kinda stuck with unmanaged DirectX.

    Although for new Apps with completly new design MDX is the way to go.

    I really like the clean layout of the Classes, it’s quite more appealing then the unmanaged version.

    And now that some really anoying bugs are cleared (remember the lock on DirectDrawSurface? ;)) it’s a good alternative to the unmanaged DirectX API.

    Performance can’t be an issue, coz the only part where I’m always missing some performance is the graphics card itself 🙂

    And if people keep some basic things in mind, like correct usage of VertexBuffers then there won’t be any performance problem with MDX at all…

    I’d say our apps (take a look at our webpage!) are one of the best proofs that DX is way better than any other graphics lib.

    Thanks for the good job, best regards


  4. John Li says:

    Well, it would be really good to have full-ish DirectShow support in MDX, instead of having to use COM.

  5. Paul Gielens says:

    To much focuss on C++.

  6. Joe game developer says:

    The API’s nice — my toy game got 200 lines shorter when I ported it from C++ / Direct3D to C# / Managed DirectX

    But my real goal is to write a console game, and there’s no C# or CLR for any console.

    Will Managed DirectX and C# ever work on Xbox? If not, why not?

  7. Thomas Decroyère says:

    I’m currently using Managed DirectX for my new engine and I have great performance but it is really necessary to use the CLR profiler so you can detect if your code is GC friendly in order to prevent 2 gen GC collections. But the api design is really nice and I have great productivity.

    For future Managed DirectX versions, it would be nice to have: a better help (because for the moment I only use the help of c++ directx), more samples, good example of how to do the main game loop in the samples (because using DoEvents() is not the optimal way), DirectShow support and more friendly exceptions.

    As Joe game developer said, meaby the think that can stop developers to use Managed DirectX is the portability of the .net framework (would be nice to use .net for the XBox 2).

  8. I second the entries regarding the documentation. While the API is delicious, it’s trial and error when learning how to use it.

  9. Jim Arnold says:

    +1 on bad documentation.

    Also, the error-handling is really really sucky. Why are we seeing HRESULTS from a managed API?

  10. jeff says:

    Agree with everyone on the poor documentation. It’s terrible, and like a lot of MS docs, leaves you with a "where do I start?" feeling. Your Sams book was pretty outstanding though, with the exception of your frequent use of the words "simply," "naturally" and "obviously," words one doesn’t like to see when they’re approaching game programming only as a hobbyist.

  11. Andrew says:

    The documentation is lacking in many areas, as others have pointed out. The one area that bit my project hard was the perceived abandonment, and general buginess of, the AudioVideoPlayback classes, especially the RenderToTexture system. In the end it killed the project and we ended up with a seriously non-optimal solution. However, your book is on my shelf along with Lynn Harrison’s, and I’m hoping that managed directx prospers.

    PS, a managed version of the Doughnuts application in the SDK would be nice.

  12. moo says:

    Because its not cross platform which is what the CLR and C# is trying to be.

    I want cross platform, show me DirectX on other platforms and then I will listen until then talk to the hand.

  13. Matthew Adams says:

    DirectShow capture support is really important for us, and that impedes our ability to use Managed DirectX!

    We’d also love to see some examples of using DirectDrawSurface with real-world-sized 2D bitmaps (e.g. the kind of things you’d get out of a consumer digital camera), that will work across common DX8-and-up supporting graphics cards.

  14. Mr. R says:

    I think the only thing that would stop me from using Managed DirectX is the fact that it’s managed. However, in recent experience, I do find that managed code can work quite well, and seeing as how DirectX is already more or less intertwined into Micorosoft, I would be up for it. The fact that the calls would be much more understandable, and the fact that you don’t have to handle a lot of garbage, makes it all the more inviting, IMO. In regards to previous posts, the documentation seems something to be desired as well as more examples.

  15. Rob Bigelow says:

    So far the biggest strike against Managed DirectX is the lack of DirectShow support. We had to roll our own C++ solution to support playing video on textures in our engine. It wasn’t trivial, and it is still lacking functionality that a true managed solution would provide, like being able to take a Stream instead of a filename for the AVI.

    Next, I would say documentation. This is second on the list and not first only because I’m starting to see some really good info that’s being disseminated via blogs. The docs need to go into more detail, with more samples illustrating how things are supposed to work together. I think you guys are making progress in this area, and realize that it’s a been priority.

    As an example of the level of detail required, I never would have known how to get the unmanaged device from a Device object if it hadn’t have been for Craig Andera, who in turn pointed me to XPLSV Dev Diary.

    Tom, you mentioned working on a book that would illustrate how to implement a game engine with Managed DirectX. If this were a full-blown engine that illustrated how to use the AnimationController, the EffectPool, and other high-level pieces, it would do wonders for Managed DirectX development.

    Thanks for the hard work!



  16. Dave says:

    ASP.NET (aka Managed Web Programming) had an excellent launch to the developer community..

    * Lots of documentation

    * QuickStart Tutorials

    * Large/real samples (i.e. Duwamish)

    * Best Practices

    * Architectural Guidelines for how to build a website

    Ok, so it would be great if the MDX team put together the kind of slam-bam documentation package that the ASP.NET team put together.


  17. Dave says:

    There ya go Rob, that’s exactly what I’d like to see as far as a complete/large/real sample – a legitamate engine that uses all/most of the major parts.

    AppWeek apps for the community, sort of.

  18. James says:

    Mesh.Box(…) doesn’t generate texcords 😉

    Seriously though, I’m a converted C++/OpenGL boy and the only thing I miss is the community – that’s more important to me than the docs thing.

    Bit of suckage as this is something the MDX team can’t really fix; but I’m sure things will improve as more people start using…

    Oh, and distribution – its a bit annoying that the assemblies aren’t installed by default (they’re not, right?) with the main directx end user installation.

    Other than that, I have nothing but fanboy praise to throw at the discussion.

  19. Noah says:

    Again. Documentation. Quoting an above comment: Look at the ASP.NET site. You aren’t going to get close to the same amount of traffic but people are only going to come if there’s something to see. And please: more beginner C# tutorials. I’m sure that you and your team know what they’re talking about and could put some killer in-depth novice articles. Craig Andera’s are good, but do’nt explain some design decisions in the C# samples from the SDK. (not his fault, nor yours).

  20. Adam Hill says:

    +1 on poor documentation too

    +1 on no DirectShow support (you gave us the AV namespace then took it away, no donut for you!)

    Fonts are another weakness of MDX it would be nice to resolve and make sure DirectMusic makes in in the Managed space.(I feel managed code will make DMusic more accessable to the programmers)

    Please give us some – best practices, patterns and sample apps (ala ShadowFax scale) I would love a VMR, Texture Management, AntiCheat or Sprite Building Blocks to show u at launch.

  21. Felixx says:

    I love c#. Coded 7 years using C++/DirectX, but c#/mdx charmed me 😀 The problem is that DOCUMENTATION SUCKS. Other problem is that is a very inmature "API". Look at http://www.santyesprogramadorynografista.com/MDXOcclusionQueryIsBugged.zip

    example … Occlusion queries are bad implemented…. Adn why in C++ are async and in c# pools sync? And there are TONS of broken features and clear bugs that I submited to directx@microsoft.com, and I am still waiting a response and that was year ago omg! I cant understand why Microsoft doesn’t release a small patch… grr

    Another thing that would be nice is to add the c++/dx examples that lacks the MDX ( for example, the HLSL example is implemented in C++ but not in c# ).

    And pls, force the install of /InstallManagedDX in the setup… intall it ALWAYS!!!

    Install it in the XBOX too iwth al full c#/MDX xdk!!!!

    But I am sure the future is c#/MDX. It is MUCH more CLEAR and EASY to use then the C++/DirectX approach, and the speed is GOOD!

  22. Forumaddict says:

    Have MDX a forum as complete as http://www.opengl.org? If not.. why not? 😀

  23. Bayern says:

    I cant understand why DirectInput doesn’t have a funciton like GiveMeTheUNICODECharOfTheKey(Key) … Imagine I am doing a q3-style console… and can’t use the GDI/WMQ/blah blah… how the hell a japanese can type kanji in the console without become crazy manual-mapping the console? pff… With this funcion GiveMeTheUNICODECharOfTheKey(Key) all will be better!

  24. Bubu says:

    finish that MDX book asap omgomg! We need more documentation, tutorials, books, training, forums about Managed DirectX!

    Thx to allow us to express our opinions and feedback in a forum!

  25. Debugger says:

    Have you tried to REMOTELY DEBUG a c# MDX program? SecurityException, SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException OMG!

  26. HLSL! says:

    l_fxcExe = Microsoft.DirectX.Direct3D.EffectCompiler.FromString ( l_xmlElem.InnerText, null,

    ShaderFlags.PartialPrecision|ShaderFlags.PackMatrixRowMajor, out l_strErrors );

    if ( l_strErrors!=null )


    l_fx.block = m_d3dDev.EndStateBlock();

    return new CError("PS Compilation Error",l_strErrors,eERROR.INVALIDARG);


    //I have no idea why, but if I specify shaderFlags!=none here, it fails….

    l_gsPS = l_fxcExe.CompileShader ( EffectHandle.FromString("main"), @"ps_1_1",


    out l_strErrors );

    BUGs, BUGS, BUGS! No info, no info! no examples, no examples! no comments, no comments! no support, no suppport, no support!

    That’s why I use C++/DX and not c#/MDX 😀

  27. Forum says:

    Agree with ForumAddict… we need a http://www.opengl.org-like forum to express or questions/feedback or suggestions. The current Microsoft DirectX Dev forums are not enough.

    And other thing… allow EVERYBODY to download the future c#/MDX betas! why to restrict it? no sense…. As more ppl try c#/MDX, better … look at openGL2.0 for example… PUBLIC forums allow you to download beta-whitepappers, SOURCE CODE for the HLSL compiler… And DX= no source code, no free-for-all betas and whitepappers, pff…

  28. koko says:

    The problem using c# is that is easy to decompile… I use the dotFuscator free edition with the vs2k3, but it is not enough to me….

    Another problem using shaders is that everybody can "look" your amazing shaders if you use a .fx or .vsh or you link it as resource. We need some kind of encryption for the shaders pls!

    I think future MDX should include more d3dx hight level functions, like lightmap generation for out editors, software clipper for portals, and some kind of new buffers to perform Order Independent Transparency


  29. moo says:

    If your product is so AMAZING, patent it otherwise you have copyright laws to help.

  30. Ernie Booth says:

    First off let me say the amount of work you produced Managed DirectX is very impressive as I understand you wrote the whole thing your self. Besides the lack of documentation that shipped with MDx9 the design of the API is not easy for many C# developers to use. The main reason being the lack of higher level classes, which may seem strange to put in a low level graphics API, but this is the .NET audience. The design of the API doesn’t fit with the rest of the .NET framework style. This is one of the best parts of the Framework, if you can program in one part, then you already understand how to program in a different part.

    I would still want all of the existing classes in MDx9, but I would love to see several additional classes added to help reduce the learning curve.

    Character Class to do stuff like: load character, collision detection, character control, state machine management and A.I. With a designer to handle the state machine generation code for a character, including user input and outside force reaction.

    Level Class: LoadLevel, Triggers, Spawn Points. With a designer to handle the level design.

    I am not going to go on and on here, but I hope I have gotten my point across that low level classes are great for those of us who have graphics backgrounds and should stay in MDx9, but higher level classes are needed with heavy designer support to really get a wider audience. And perhaps DirectX is not the location for these classes, but instead provide them as a framework addition in say System.Interactive.

    Good Luck with MDx10 and MDx for Longhorn.

  31. Better exception descriptions – things like "Error in application" leaves little clues to what is actually wrong.

  32. moo says:

    Err, DX isnt a game engine.

    Add more bloat like that and people will just move over to OGL even faster like people dont want MFC.

  33. Felixx says:

    I have other suggestion ( not sure if this is the place to comment it )… Is it possible that in the next DirectX SDK release we can download JUST ONLY the c#/MDX part without get the 300Mb of the entire SDK? I really want ONLY the c# part, not the C++ part….

    I look the GotDotNet forums.. but lacks. You should create some Feedback/Future Releases sugestions, hire ppl to "profesionally answer" ( like in some other MS forums ) que asks, download betas, HLSL shader contests, blah blah. Again, look http://www.opengl.org … that IS a community! And byw, i dooooont want a http://www.gotdotnet.com domain… I waaaaaant a http://www.manageddirectx.org domain 😀


  34. James Bellinger says:

    Hm, my thoughts on this..

    Managed DirectX, while neater than unmanaged, still has a very dirty feel to it, versus the rest of the Framework.

    Here’s a laundry list, if it’s of any use:

    At present my biggest objection is "Error in the application." The error messages DirectX gives off are beyond useless. In addition, even with the DirectX Debug Output setting at max, I don’t see any debug messages.

    Other than that, I’d have to say DirectX unloads a lot of unnecessary work onto the developer. For example, Dynamic and WriteOnly… why would a developer want to read from a dynamic vertex buffer? I can’t think of a single good reason why a developer should even be allowed to. And you can’t use WriteOnly with non-Dynamic buffers. Actually I don’t know why you’d want to read from a vertex buffer in the first place, since your program put the data there and it doesn’t change on its own. So WriteOnly isn’t even necessary. Thus isn’t a great example, but you see what I’m saying. 🙂

    And then we have method names… ‘Lerp’? Yes, it’s a commonly used term. It still looks goofy. ‘Interpolate’ seems more appropriate. ‘Hermite’ to ‘InterpolateHermite’ (‘HermiteInterpolate’ might be okay, or ‘HermitianInterpolate’, but the latter would be spelled wrong more often and neither of them would line up in IntelliSense, which is, I think, something that actually matters). Etc., etc. Then the quaternion could have ‘Interpolate’ also, and ‘InterpolateCubic’. There’s no good reason to name the method ‘Slerp’, aside from that being the term for it. Unify things like that. It’s all interpolation.

    I think it would be a lot better if there was a focus on letting developers be as lazy as is humanly possible while still offering a reasonable feature set. Even a 10-20% speed difference isn’t going to change whether someone buys a game. If the game is awful, the most amazing framerate in the world won’t help sales. If the game is good, eighty instead of a hundred frames per second won’t hurt sales (and this is becoming less of an issue every day). I *would* argue, though, that if the game is horribly buggy and crashes all the time, that *will* hurt sales and the reputation of the game. Crash bugs are very frustrating, and some can come out of misunderstanding of the API and/or weirdness that requires a lot of special contingency plans. Because those special cases may not bite during development, but they will bite.

    A clear API that allows a developer to build code that works as expected in all reasonable cases _easily_ is far better for that developer than one which can tantalize with a little extra performance in exchange for unexpected cases that will only pop up on nVidia EM-Force 7000s because they don’t support indexed hologram blending. :p

    What Mr. Booth is suggesting may be a bit high level, but I agree with the essence of his statement. Spawn Points are too game-specific in my opinion, but if there is anything that high in the food chain that could be generalized in a useful fashion it wouldn’t be unreasonable to offer an API. Of course AI and such do not belong in the current DirectX suite, but one could always add another module. 🙂 (though AI varies too much, I’d say, but there are some common patterns among games that could perhaps be shared) Save developers time. Let them be As Lazy As Possible.

    Anyhow that’s all. 🙂 I suppose this has become too philosophical. Sorry about that. 😉

  35. qpro says:

    * absence of DirectShow.Net

    * too few samples

    * documentation for C++ in C# SDK!!!

  36. I have been using Managed DX since the first Beta was available for my open source Axiom 3D Engine (http://axiomengine.sourceforge.net), which is a C# port of the C++ OGRE engine (http://www.ogre3d.org). It supports both Managed DirectX and OpenGL (via the Tao.OpenGl library, http://randyridge.com/Tao).

    I may have hit a few bumps along the way, but in general using Managed DX has been a great experience and much easier to use than it’s unmanaged counterpart. The Managed documentation could be better, but anyone doing a serious project should have the capability to experiment and figure things out for themselves if need be, or scan the C++ docs since the knowledge applies to both API’s.

    The DX features used by Axiom include (but are not limited to):

    – vertex buffers for static and dynamic (i.e. skeletal animation) geometry. To be as flexible as I needed, all vertex buffers are declared with bytes elements rather than using the CustomVertex structures, which fits better into the cross API design. I submitted a bug during the beta phase where a buffer created using the constructor for VertexBuffer that does not take a System.Type parameter will throw an exception during a Lock, but the other 2 overloads work fine.

    – low and high level shaders loaded from asm from file, asm as output from Cg, or as output from DX HLSL.

    – render to texture

    – cube and volume textures

    – spherical/cubic environment mapping

    – lighting, fog, and many other fixed function features

    To answer your question directly, the only thing that would probably stop people from using Managed DX is the lack of DirectMusic and DirectShow (AudioVideoPlayback is very cute, but falls a bit short 😉 ). Performance really isn’t a consideration in terms of the API itself, because for the most part it is just passing through to the Unmanaged version of DirectX, so any performance issues would be more likely found in other areas of the application such as floating point math, heavy loosely typed, collection use, wreckless "fire and forget" allocation, etc.

    I submitted several bugs during the beta period and most were acknowledged and resolved. I’m looking forward to seeing the next update!

  37. Bulma says:

    I hope to see Managed DirectX on Mobile devices soon. OpenGL ES is there already, we have .NET, but not DirectX…

    Something like http://www.manageddirectx.org (or http://www.mdx.org) would be very nice…

    I am very pleased with Managed DirectX at this time…

    I would stop using it only if it won`t be available for required platform (mobile devices, Mac, Linux, or some other OS I`ll have to code for…)

    My girfriend had to stop using Managed DirectX because people at her university don`t like Microsoft products 🙁

  38. I don’t know if it would stop me from using MDX, but not getting the ability (at some point) to run applications on X-Box would definately be a disappointment.

  39. Filip Strugar says:

    main 2 points:

    – c++ inertia – lack of c# code & community, not easy to do C++ reuse, untested, etc.

    – managed dx is not cross platform – no game console porting (what about new Xbox?)

    bad docs

    no .net linker

    "Error in the application." sux.

    otherwise is cool 🙂

  40. Needs DirectShow and WMFDSK support!

  41. Marauderz says:

    Definetly the documentation… I just LOVE the fact that the documentation page for an enumeration in Managed Direct X…is just a list of values….

    And yes… Direct Show and Direct Music support… definetly Direct Music support!

  42. Prashant says:

    Right now the only thing that’s stopping me from using MDX9 is the 230 MB download size of the SDK :-/

  43. Noel Wade says:

    I’m going to add my voice to the people screaming for more Docs… Especially on the C# end of things. I know this is a monumental task, considering the complexity of the API – but if you want people to use something, they HAVE to be able to make sense of it.

    DX9 is simpler and easier than ever (I started back with DX6) – but it still has a huge learning curve because you can’t figure out how to work it, just by looking at the classes and docs… You HAVE to find tutorials and buy books, to understand how the various parts "interconnect".

    If you want my ideal example of Documentation, check out the online/searchable docs at http://www.php.net. Every class and function has a paragraph or so describing its function and common usage. I learned the entire PHP language in a couple of days: I started reading a book, but once I had the basics I could just search the docs and find what I was looking for. I’ve worked with ASP, VB, Java, PHP, C++, and now C# – and PHP was by far the easiest to learn. Granted, its one of the simpler languages in that list (when taking into account the number of built-in classes and API-level functions)… But its documentation truly sets it apart from the others. With the Win32 API for C++, many Java APIs, and DirectX, one always has a feeling of groping in the dark for the proper Classes and Methods to accomplish something.

    Thanks for all your hard work, hope to see the MDX community grow and prosper! Take care,

    –Noel Wade


  44. Hmmm, Tough question. But I think from my own fooling around with dx I would suggest the fallowing improvements and or like there of …

    1: Perhaps some sort of advanced Direct3D device object. For example with my own dx library DX9Tools I have created a wrapper class for the d3d device object that simply tries to setup and use the best possible features available on the video card that the app is running on. I can’t imagine a situation where you would not want to use the best most powerful features available on a video card, accept when you want to work in software mode for testing features, the d3d device should do this automatically. Basically if the video card supports transform and lighting then what possible excuse would you have not to use it?

    2: Maybe a camera object? To simplify having to work with the projection and view matrices. But I would suggest making it a powerful camera object with built in features like say an arc ball or for example have a Position and LookAt properties on the camera but when you make a call to Camera.Rotate(X,Y,Z) That the Camera.LookAt position changes and is now positioned in the proper place because the Camera.Rotate rotated it into that position. Basically a full featured camera object you could could never live without.

    3: Can’t forget this little pain in the neck. d3d needs some way of automatically reloading texture/vertex data back onto video card after device is lost etc. Just writing this code alone is a real pain.

    4: I have often thought perhaps an api like dx is is not the way to go, and maybe re-structuring it to be more like a game engine would be more beneficial. In the sense that it would act as the core of a graphics engine. Providing all the features common to all 3D engines but generic enough to be able to extend it to your particular apps needs. (D3D engine core -> third-party extensions -> the actual game )

    5: Btw, Animation controller and affiliated objects = crap. That’s just my opinion. To me "AnimationController -> Tracks – > Track -> Keys -> Key" is much more logical. That would be the data store part, the interpolation between keys is another story. When I first came across the AnimationColtrolller I expected it to function similar to how I work and understand gMAX with position, rotation, scaling keys etc stored in separate tracks.

    6: Speed is never my concern, just getting an app to do what I want is. I know DX has always been an oop oriented language but there is something to be said about OpenGL and how it’s method based rather than object based.

    7: In terms of longhorn, Please tell me we will not have to deal with dx if we don’t want to. What I mean by that is I know the GUI for longhorn is D3D or DX driven so it is my hope that we developers can finally write games and not have to deal with a dx api if we don’t want to and yet will still be able to work/access DX oriented functionality. Kind of hard to describe what I mean not knowing what the final spec for the longhorn api and .NET framework is going to look and feel like. But basically the only reason I don’t write games in pure .NET Framework (no dx code) is because the .NET Framework can’t render a 3d object and multi texture it, let alone pixel/vertex shade it. If the .NET Framework provided that functionality I would have no need for dx.

    8: Hmmmm,… let me see. How bout an option to disable exceptions being thrown when a DirectInput or d3d device is lost etc. Or not throwing an exception at all? Just a simple property or method to do a check to see if a device is lost etc and if so try to re-acquire it.

    If <device lost method/property> then

    If <try to re-acquire device> = false then

    ‘ do nothing


    ‘ continue game loop etc

    end if

    end if

    In the above code "<try to re-acquire device>" would also do what I suggested in request 3 "… automatically reloading texture/vertex data back onto video card …"

    9: Abstraction, Abstraction, Abstraction! The closer to DOS/QBasic in terms of ease of use the better.



    1:Check what the video card supports and can do <crap>

    2:setup a presentation parameter object <aw come on!>

    3:create a device <crap> <more laziness>

    4:create line object foo <ughh>

    5:create vertexarray <yah ok I guess this part is necessary>

    6:do clear


    8:setup world/view/projection matrices <crap> <more hassle>

    9:foo.draw <finally! sheesh!>


    11:present <shouldn’t endscene have an option to do this?>



    1:screen 13 <yah baby>

    2:line (0,0)-(10,10) <wow! Now I have more time for a social life!>

    … You get the idea. And all the while you have to manage and store textures, device lost states, god awful combos of texturing parameters (thank you for pixel shaders), the user multitasking over to a different app. etc etc etc.

    10: I like the idea that I don’t have to know how to write pixel shader code. All I need to know is what the shader expects from me. For example a bump mapping shader that expects 3 textures in the streams 0 base,1 environment,2 bump respectively, all I have to do is load the shader from a file, pass it onto the device, Then pass the three textures to streams 0-2 and render my geometry. No fuss, No Mess. Beats all those texturing parameters. The more you can simplify dx like this the better.

    11: And finally on a theoretical note. With the advent of pixel and vertex shaders I find myself wondering how one could write a pixel shader like piece of code for doing physics calculations. (IE: getting the video card to off load physics calculations from the cpu)

    Hmmm, Tom Miller asking about how to improve dx. Can anyone say longhorn suggestions? heh heh. Longhorn is going to kick… err, umm,… Donkey butt! Ya! Donkey Butt! Whoot! At lest from a developers point of view. From a consumers point of view i’m sure it’s more like, "Oh man not another windows OS I’ll have to blow $200+ more dollars on!"

  45. Direct3D.Font needs to have some sort of equivalent "GraphicsMeasureString" method.

    Also an overloaded Direct3D.Font.DrawText method loke so DrawText(ByVal Text As String, ByVal Color As Color) having to specify a rect and textformat params all the time can be annoying.

    NOTE: Hope you are keeping an eye on these comments cause I will probubly post alot of suggestions…

  46. Im such a good speller. (See my prev post :p )

  47. Tom Miller says:

    I keep an eye on the comments definitely. I would encourage you to also email your suggestions to directx@microsoft.com just in case i happen to miss one here.


  48. I am hoping most developers are like my self and would rather there be an uber ammount of overloaded methods with every possible combo of parameters availible. ( Saves us from having to code them our selves :p ) Although there are those of us out there who would claim too many overloaded methods could cause a speed hit, I say Bah! The hit would be puny. Having said that I have provided a few "TextureLoader.FromFile" overload ideas…

    Public Function LoadTexture(ByVal File As String) As Direct3D.Texture

    Public Function LoadTexture(ByVal File As String, ByVal ColorKey As Color) As Direct3D.Texture

    Public Function LoadTexture(ByVal File As String, ByVal Filter As DirectX.Direct3D.Filter) As Direct3D.Texture

    Public Function LoadTexture(ByVal File As String, ByVal Filter As DirectX.Direct3D.Filter, ByVal ColorKey As Color) As Direct3D.Texture

    Public Function LoadTexture(ByVal File As String, ByRef Info As Direct3D.ImageInformation) As Direct3D.Texture

    Public Function LoadTexture(ByVal File As String, ByVal ColorKey As Color, ByRef Info As Direct3D.ImageInformation) As Direct3D.Texture

    Public Function LoadTexture(ByVal FIle As String, ByVal Filter As DirectX.Direct3D.Filter, ByRef Info As Direct3D.ImageInformation) As Direct3D.Texture

    Public Function LoadTexture(ByVal FIle As String, ByVal Filter As DirectX.Direct3D.Filter, ByVal ColorKey As Color, ByRef Info As Direct3D.ImageInformation) As Direct3D.Texture

  49. Flipper says:

    How about a way to flip a sprite

    Loading a sprite, there is no (easy) way to flip it horizontally/vertically.

    If you have a character on screen facing right, and only runs right, then yeah, great. If you want to make him run left? What now, load an entire new Texture of cells just for him to face the other way? Seems overkill.

  50. Loki says:

    Am I the ONLY person that still uses Direct Draw? Yes yes yes, I know it’s obsolete. This didn’t stop them including it in MDX. And now, I am using it. However,

    1) Primitive methods (line/rect/etc) do not work all that great / provide crap performance.

    2) Surface.Lock is ABOSLUTELY USELESS! For god sakes, there must have been a better way to do this? Locking a 1000×1000 pixel bitmap absolutely KILLS your application. Pointers anyone?

    3) Lack of Plot/Point methods for writing/reading pixels. (Would have been nice). You never know when you just want to read/write the odd pixel.

    4) Thought MDX-D3D docs were naff, take a look at the MDX-DD docs. Ouch!

    Ok, it’s obsolute. But if you are going to do it, PLEASE do it right. Seems D3D got a lot of nice new docs in summer update, DD did not. Also, where are the DD examples? ARGH Mind boggles.

    There are a lot of people still using DirectDraw, for multiple reasons. I doubt MS will ever be able to actually remove DirectDraw from the DX distro (based on the fact that would break compatibility with about a million existing applications), so you might as well support DD properly.

    (Also, yes I do know about the Sprite class).

    DIRECT DRAW…….. FOREVER! (Until it’s dropped!)

  51. John Nelson says:

    Direct Show? GIVE me DS Editing Services or give me death!!!!

  52. Hah! found another problem/hassle that could be fixed.

    Understand why you get a DriverInternalErrorException exception when rendering in windowed mode. I should also say that the details pertaining to what I think is going on behind the scenes with directx may be inaccurate so don’t quote me on them.

    First if you are rendering to a control that is either docked or anchored on your form that may be your first problem. As I understand it, DirectX automatically resizes the back buffer to the same size of the target control when the target control is resized. So the problem occurs when you resize or minimize your form the size of that control is set to 0,0. And there in lies the problem. You can’t have a back buffer with a width or height of 0! So to solve the problem You will need to position and size the control on your form manually to prevent the DriverInternalErrorException exception from being raised.

    It would be nice if we developers did not have to handle this exception but rather DirectX could do the check and ensure that the back buffer is never smaller then say 1×1.

  53. Robert Ludig says:

    I am really new to managed directx and I am working my way through the mdx kickstart book whenever I have time. So far I must say the only thing that could stop me from using mdx is the fact that the user has to go through quite a procedure, to get mdx-based applications to run on his machine. (if I do not provide a multimegabyte installer)

    The user has to first install the .NET framework. After that he has to install DirectX9.0b. BUT he can not use the webinstaller. He has to get the redist and then install it with that /installmanageddx flag. That’s too much for a normal user.

    Maybe I miss something here, but I would really love to say to my "customers":

    "All you need to install to get my code running is DirectX9.xx. Just download the dxwebsetup.exe and run it and you are all set (everything you need is included there). Directx is is also included in the latest games, so if you have installed that you can run my app."

  54. Nick Howell says:

    Vectors should be reference types; ie: class, not struct, or __gc and not __value. It’s a real pain having to make X, Y, and Z available explicitly as well as in a vector. I don’t know if reference types are faster than value types (I imagine they would be), but I don’t care. It’s so annoying I might spend the required time writing an encapsulation class.

    Just ensure the Clone() method works (I have no reason to suspect it doesn’t), and we won’t need value objects for anything but integral data types and maybe some basic ones like DateTime, TimeSpan, and Drawing.Color.

  55. Nick Howell says:

    Also, add more constructors to the Light class; I want to be able to make basic modifications to a light in one simple command.

    For example, cloning a light, changing it’s position, color, and all common changes should be available in constructor combinations.

    Aside from that, the API is really quite good; I found myself wanting to write wrapper classes for just about everything in DirectDraw, but just about everything in D3D is perfect; just minor niggles.

    Why the obsession with floats/singles as opposed to doubles?

  56. Spacehog says:

    – Lack of documentation. Everybody knows this

    sucks. I’m sick of wading thru google everytime I need to know how to do something. What would we do without Craig Andera?

    – Lack of double precision throughout the API. This makes it feel like a "toy" API, you know, not suitable for "serious" applications where precision matters.

    – Portability issues to non-MS platforms

    This isn’t a major issue at the moment, but it’s one of those things that would count against it when the time comes. We are keeping

    an eye on Mono/Dotgnu.

  57. F176 says:

    There is no documentation. Only just a few sample and guide.

    NO DSHOW is big problem. Don’t worry about performance of it.

    SLOW and IMPOSSIBLE cannot be compared.

  58. Dozman says:

    Documentation seems to have too much emphasis on developing games. (same with previous DX documentation). Full screen mode seems to have good performance, but windowed really doesn’t compare with OpenGL in windowed mode. – That was important for me.

    Some best practice documentation, with snippet style code samples (in VB,C#,C++) would have been nice. Not all developers want to use every feature. I wanted to use some features and get assistance on techniques that are likely to help me in developing an app with MDX.

  59. bsmile says:

    MDX should be able to be used in a semitrusted application without requiring any strong security permissions.. That really stops me from implementing the application I want.

    Maybe you could implement a safe subset of DirectX that would be callable without requiring any dangerous permission.

  60. Intuitioned says:

    Same reasons mentioned above.

    All I want to do is some high performance 2D bitmap stuff with C#.

    Lock sucks. You would think this type of feature would be invaluable. The documenation sucks. It looks like it has been improved for the 2004 summmer version. Guess what? Lock has some more documentation but it looks like it is being depricated! So what is the modern MS recomended replacement? Hah! Don’t expect the documentation to tell you this…

  61. [Xwire] says:

    The AudioVideoPlayback class is great in concept but once you start working with it numerous errors become evident. There are many but here are a few fo the more serious.

    1. The .fromfile and .open methods of both the audio and video classes cause the equivilent of a DoEvents which is very bad in a structured application, and causes unpredictable behaviour.

    2. The audio class of the video is readonly and you have to go through quite a workarround to access it.

    3. The media end of the video class does not fire, but the video.audio class does fir this event.

    3. The .stop method only pauses the media, the .stopwhenready method does stop it.

    4. the .stopwhenready of the video class brings the video window into focus.

    There are many others and it is things like these that would stop me from using mdx, it is not throughly tested, and this class is more of a toy and because of it’s numerous problems cannot be seriously implemented.

    5. The .dispose of the video class does not dispose it, you must do video.audio.dispose first.

  62. Dating says:

    This is a question that is interesting in more ways than one. One of the more common answers to this question i hear is naturally centered around performance, even though many times the person with the ‘fear’ of the performance hasn’t actually tried t

  63. Weddings says:

    This is a question that is interesting in more ways than one. One of the more common answers to this question i hear is naturally centered around performance, even though many times the person with the ‘fear’ of the performance hasn’t actually tried t