What would stop you from using Managed DirectX?

Article
02/05/2004

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

Anonymous
February 05, 2004
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.

Thanks.

Regards,
Chua Wen Ching :p
Anonymous
February 05, 2004
why we don't using Managed DirectX?
because the DirectX SDK help just for C++;
Anonymous
February 05, 2004
Well,...
We have tons of libraries build on C++ and 80x86 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
Peter
Anonymous
February 05, 2004
Well, it would be really good to have full-ish DirectShow support in MDX, instead of having to use COM.
Anonymous
February 05, 2004
To much focuss on C++.
Anonymous
February 05, 2004
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?
Anonymous
February 05, 2004
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).
Anonymous
February 05, 2004
I second the entries regarding the documentation. While the API is delicious, it's trial and error when learning how to use it.
Anonymous
February 05, 2004
The comment has been removed
Anonymous
February 05, 2004
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.
Anonymous
February 05, 2004
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.
Anonymous
February 06, 2004
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.
Anonymous
February 06, 2004
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.
Anonymous
February 06, 2004
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.
Anonymous
February 06, 2004
The comment has been removed
Anonymous
February 06, 2004
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.

Please?
Anonymous
February 06, 2004
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.
Anonymous
February 06, 2004
The comment has been removed
Anonymous
February 06, 2004
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).
Anonymous
February 06, 2004
+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.
Anonymous
February 06, 2004
The comment has been removed
Anonymous
February 06, 2004
Have MDX a forum as complete as www.opengl.org? If not.. why not? :D
Anonymous
February 06, 2004
The comment has been removed
Anonymous
February 06, 2004
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!
Anonymous
February 06, 2004
Have you tried to REMOTELY DEBUG a c# MDX program? SecurityException, SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException,SecurityException OMG!
Anonymous
February 06, 2004
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",
ShaderFlags.None/.PartialPrecision|ShaderFlags.PackMatrixRowMajor/,
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 :D
Anonymous
February 06, 2004
Agree with ForumAddict... we need a 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...
Anonymous
February 06, 2004
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

thx
Anonymous
February 06, 2004
If your product is so AMAZING, patent it otherwise you have copyright laws to help.
Anonymous
February 06, 2004
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.
Anonymous
February 07, 2004
Better exception descriptions - things like "Error in application" leaves little clues to what is actually wrong.
Anonymous
February 07, 2004
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.
Anonymous
February 07, 2004
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 www.opengl.org ... that IS a community! And byw, i dooooont want a www.gotdotnet.com domain... I waaaaaant a www.manageddirectx.org domain :D

thx
Anonymous
February 07, 2004
The comment has been removed
Anonymous
February 07, 2004
absence of DirectShow.Net
* too few samples
* documentation for C++ in C# SDK!!!
Anonymous
February 07, 2004
The comment has been removed
Anonymous
February 07, 2004
I hope to see Managed DirectX on Mobile devices soon. OpenGL ES is there already, we have .NET, but not DirectX...
Something like www.manageddirectx.org (or 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 wont be available for required platform (mobile devices, Mac, Linux, or some other OS Ill have to code for...)

My girfriend had to stop using Managed DirectX because people at her university don`t like Microsoft products :(
Anonymous
February 09, 2004
The comment has been removed
Anonymous
February 11, 2004
The comment has been removed
Anonymous
February 11, 2004
Needs DirectShow and WMFDSK support!
Anonymous
February 15, 2004
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!
Anonymous
February 24, 2004
Right now the only thing that's stopping me from using MDX9 is the 230 MB download size of the SDK :-/
Anonymous
March 07, 2004
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 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
noel_wade@hotmail.com
Anonymous
March 12, 2004
The comment has been removed
Anonymous
March 13, 2004
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...
Anonymous
March 13, 2004
Im such a good speller. (See my prev post :p )
Anonymous
March 13, 2004
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.

Thanks!
Anonymous
March 18, 2004
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
Anonymous
March 24, 2004
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.
Anonymous
March 28, 2004
The comment has been removed
Anonymous
March 30, 2004
Direct Show? GIVE me DS Editing Services or give me death!!!!
Anonymous
April 10, 2004
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 1x1.
Anonymous
April 16, 2004
The comment has been removed
Anonymous
May 05, 2004
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.
Anonymous
May 05, 2004
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?
Anonymous
May 09, 2004
The comment has been removed
Anonymous
June 18, 2004
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.
Anonymous
July 14, 2004
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.
Anonymous
July 15, 2004
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.
Anonymous
August 01, 2004
The comment has been removed
Anonymous
August 01, 2004
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.
Anonymous
April 02, 2008
PingBack from http://copyrightrenewalsblog.info/tom-millers-blog-what-would-stop-you-from-using-managed-directx/
Anonymous
May 30, 2008
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
Anonymous
June 04, 2008
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
Anonymous
June 09, 2009
PingBack from http://jointpainreliefs.info/story.php?id=2334
Anonymous
June 13, 2009
PingBack from http://barstoolsite.info/story.php?id=7034
Anonymous
June 16, 2009
PingBack from http://topalternativedating.info/story.php?id=771
Anonymous
June 17, 2009
PingBack from http://pooltoysite.info/story.php?id=1130

Share via

What would stop you from using Managed DirectX?

Comments

Additional resources