What would stop you from using Managed DirectX?

Managed DirectX

Kent Sharkey's blog — Fri, 06 Feb 2004 05:08:00 GMT

re: What would stop you from using Managed DirectX?

Chua Wen Ching — Fri, 06 Feb 2004 02:50:00 GMT

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

re: What would stop you from using Managed DirectX?

LeighSword — Fri, 06 Feb 2004 03:33:00 GMT

why we don't using Managed DirectX?
because the DirectX SDK help just for C++;

re: What would stop you from using Managed DirectX?

Peter Koen — Fri, 06 Feb 2004 05:12:00 GMT

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

re: What would stop you from using Managed DirectX?

John Li — Fri, 06 Feb 2004 05:16:00 GMT

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

What would stop you from using Managed DirectX?

dwellerville — Fri, 06 Feb 2004 08:23:00 GMT

re: What would stop you from using Managed DirectX?

Paul Gielens — Fri, 06 Feb 2004 06:49:00 GMT

To much focuss on C++.

re: What would stop you from using Managed DirectX?

Joe game developer — Fri, 06 Feb 2004 07:29:00 GMT

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?

re: What would stop you from using Managed DirectX?

Thomas Decroyère — Fri, 06 Feb 2004 08:15:00 GMT

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

re: What would stop you from using Managed DirectX?

Micael Baerens — Fri, 06 Feb 2004 08:29:00 GMT

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

re: What would stop you from using Managed DirectX?

Jim Arnold — Fri, 06 Feb 2004 10:25:00 GMT

+1 on bad documentation.

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

re: What would stop you from using Managed DirectX?

jeff — Fri, 06 Feb 2004 15:05:00 GMT

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.

re: What would stop you from using Managed DirectX?

Andrew — Fri, 06 Feb 2004 15:11:00 GMT

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.

re: What would stop you from using Managed DirectX?

moo — Fri, 06 Feb 2004 16:28:00 GMT

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.

Managed DirectX

Kent Sharkey's blog — Fri, 06 Feb 2004 20:19:00 GMT

Managed DirectX

Kent Sharkey's blog — Fri, 06 Feb 2004 20:31:00 GMT

re: What would stop you from using Managed DirectX?

Matthew Adams — Fri, 06 Feb 2004 18:51:00 GMT

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.

re: What would stop you from using Managed DirectX?

Mr. R — Fri, 06 Feb 2004 19:15:00 GMT

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.

re: What would stop you from using Managed DirectX?

Rob Bigelow — Fri, 06 Feb 2004 19:58:00 GMT

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!

cheers,
Rob

re: What would stop you from using Managed DirectX?

Dave — Fri, 06 Feb 2004 20:00:00 GMT

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?

re: What would stop you from using Managed DirectX?

Dave — Fri, 06 Feb 2004 20:05:00 GMT

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.

re: What would stop you from using Managed DirectX?

James — Fri, 06 Feb 2004 20:29:00 GMT

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.

re: What would stop you from using Managed DirectX?

Noah — Sat, 07 Feb 2004 04:16:00 GMT

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

re: What would stop you from using Managed DirectX?

Adam Hill — Sat, 07 Feb 2004 04:31:00 GMT

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

re: What would stop you from using Managed DirectX?

Felixx — Sat, 07 Feb 2004 04:53:00 GMT

I love c#. Coded 7 years using C++/DirectX, but c#/mdx charmed me :D 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!

re: What would stop you from using Managed DirectX?

Forumaddict — Sat, 07 Feb 2004 05:00:00 GMT

Have MDX a forum as complete as www.opengl.org? If not.. why not? :D

re: What would stop you from using Managed DirectX?

Bayern — Sat, 07 Feb 2004 05:03:00 GMT

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!

re: What would stop you from using Managed DirectX?

Bubu — Sat, 07 Feb 2004 05:06:00 GMT

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!

re: What would stop you from using Managed DirectX?

Debugger — Sat, 07 Feb 2004 05:08:00 GMT

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

re: What would stop you from using Managed DirectX?

HLSL! — Sat, 07 Feb 2004 05:13:00 GMT

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

re: What would stop you from using Managed DirectX?

Forum — Sat, 07 Feb 2004 05:19:00 GMT

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

re: What would stop you from using Managed DirectX?

koko — Sat, 07 Feb 2004 05:33:00 GMT

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

re: What would stop you from using Managed DirectX?

moo — Sat, 07 Feb 2004 11:00:00 GMT

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

re: What would stop you from using Managed DirectX?

Ernie Booth — Sat, 07 Feb 2004 15:35:00 GMT

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.

re: What would stop you from using Managed DirectX?

Micael Baerens — Sat, 07 Feb 2004 17:08:00 GMT

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

re: What would stop you from using Managed DirectX?

moo — Sat, 07 Feb 2004 17:26:00 GMT

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.

re: What would stop you from using Managed DirectX?

Felixx — Sun, 08 Feb 2004 02:36:00 GMT

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

re: What would stop you from using Managed DirectX?

James Bellinger — Sun, 08 Feb 2004 02:46:00 GMT

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

re: What would stop you from using Managed DirectX?

qpro — Sun, 08 Feb 2004 04:50:00 GMT

* absence of DirectShow.Net
* too few samples
* documentation for C++ in C# SDK!!!

re: What would stop you from using Managed DirectX?

Chris McGuirk — Sun, 08 Feb 2004 06:05:00 GMT

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!

re: What would stop you from using Managed DirectX?

Bulma — Sun, 08 Feb 2004 11:22:00 GMT

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 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 :(

re: What would stop you from using Managed DirectX?

Micael Baerens — Tue, 10 Feb 2004 14:10:00 GMT

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.

re: What would stop you from using Managed DirectX?

Filip Strugar — Wed, 11 Feb 2004 17:57:00 GMT

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

re: What would stop you from using Managed DirectX?

Michael Teper — Thu, 12 Feb 2004 06:01:00 GMT

Needs DirectShow and WMFDSK support!

re: What would stop you from using Managed DirectX?

Marauderz — Mon, 16 Feb 2004 05:46:00 GMT

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!

What is the Future of DirectX

Jason Olson's Blog — Tue, 17 Feb 2004 07:28:00 GMT

What is the Future of DirectX

Jason Olson's Blog — Wed, 18 Feb 2004 05:08:00 GMT

re: What would stop you from using Managed DirectX?

Prashant — Tue, 24 Feb 2004 18:12:00 GMT

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

re: A little background material

Lori Pearce's WebLog — Wed, 03 Mar 2004 05:20:00 GMT

re: What would stop you from using Managed DirectX?

Noel Wade — Mon, 08 Mar 2004 08:59:00 GMT

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

re: What would stop you from using Managed DirectX?

Created by: X — Sat, 13 Mar 2004 08:21:00 GMT

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
else
' 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.

DirectX
-------
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
7:beginscene
8:setup world/view/projection matrices <crap> <more hassle>
9:foo.draw <finally! sheesh!>
10:endscene
11:present <shouldn't endscene have an option to do this?>

QBASIC
------
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!"

re: What would stop you from using Managed DirectX?

Created by: X — Sun, 14 Mar 2004 02:48:00 GMT

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

re: What would stop you from using Managed DirectX?

Created by: X — Sun, 14 Mar 2004 02:50:00 GMT

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

re: What would stop you from using Managed DirectX?

Tom Miller — Sun, 14 Mar 2004 02:51:00 GMT

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!

Can never have too many overloads!

Created by: X — Fri, 19 Mar 2004 04:18:00 GMT

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

re: What would stop you from using Managed DirectX?

Flipper — Wed, 24 Mar 2004 21:50:00 GMT

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.

re: What would stop you from using Managed DirectX?

Loki — Mon, 29 Mar 2004 01:45:00 GMT

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 1000x1000 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!)

re: What would stop you from using Managed DirectX?

John Nelson — Wed, 31 Mar 2004 03:23:00 GMT

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

Understand why you get a DriverInternalErrorException exception!

Created by: X — Sun, 11 Apr 2004 03:46:00 GMT

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.

Managed DirectX - Have you used it?

Tom Miller's Blog — Tue, 13 Apr 2004 01:42:00 GMT

re: What would stop you from using Managed DirectX?

Robert Ludig — Sat, 17 Apr 2004 11:55:00 GMT

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

re: What would stop you from using Managed DirectX?

Nick Howell — Thu, 06 May 2004 04:50:00 GMT

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.

re: What would stop you from using Managed DirectX?

Nick Howell — Thu, 06 May 2004 04:54:00 GMT

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?

re: What would stop you from using Managed DirectX?

Spacehog — Mon, 10 May 2004 09:21:00 GMT

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

NO DOC and NO DSHOW.

F176 — Sat, 19 Jun 2004 09:39:00 GMT

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.

re: What would stop you from using Managed DirectX?

Dozman — Thu, 15 Jul 2004 00:38:00 GMT

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.

re: What would stop you from using Managed DirectX?

bsmile — Thu, 15 Jul 2004 23:04:00 GMT

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.

re: What would stop you from using Managed DirectX?

Intuitioned — Sun, 01 Aug 2004 18:56:00 GMT

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

re: What would stop you from using Managed DirectX?

[Xwire] — Mon, 02 Aug 2004 05:51:00 GMT

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.

Copyright Revewals » Tom Miller’s Blog : What would stop you from using Managed DirectX?

Thu, 03 Apr 2008 02:27:06 GMT

PingBack from http://copyrightrenewalsblog.info/tom-millers-blog-what-would-stop-you-from-using-managed-directx/

Tom Miller's Blog : What would stop you from using Managed DirectX?

Dating — Sat, 31 May 2008 00:30:00 GMT

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

Tom Miller's Blog : What would stop you from using Managed DirectX?

Weddings — Thu, 05 Jun 2008 14:08:46 GMT

Tom Miller s Blog What would stop you from using Managed DirectX | Joint Pain Relief

Wed, 10 Jun 2009 03:02:38 GMT

PingBack from http://jointpainreliefs.info/story.php?id=2334

Tom Miller s Blog What would stop you from using Managed DirectX | bar stools

Tom Miller s Blog What would stop you from using Managed DirectX | bar stools — Sun, 14 Jun 2009 08:40:16 GMT

PingBack from http://barstoolsite.info/story.php?id=7034

Tom Miller s Blog What would stop you from using Managed DirectX | alternative dating

Wed, 17 Jun 2009 10:38:50 GMT

PingBack from http://topalternativedating.info/story.php?id=771

Tom Miller s Blog What would stop you from using Managed DirectX | pool toys

Tom Miller s Blog What would stop you from using Managed DirectX | pool toys — Thu, 18 Jun 2009 11:35:54 GMT

PingBack from http://pooltoysite.info/story.php?id=1130