This thread is obsolete. Please visit the SlimDX homepage instead. Why: Around fall of last year, there were a couple events involving the future of Managed DirectX. MDX 2.0 was discontinued, along with assistance from a surprise time bomb. MDX 1.1 is frozen and is essentially our only option for interfacing DX and .NET. XNA rose to "replace" MDX 2.0, but my work with XNA convinced me of two things. First, XNA is an Xbox API that happens to run on PC as a convenience. Second, XNA is a toy right now and will not be useful as a serious development tool for some time. This left MDX developers in an akward place. Yes, MDX 1.1 is supported for several years, but the current state of affairs is not exactly encouraging. Additionally, researching the loader lock problem yielded considerable explanation of why the problem exists, but I was unable to find evidence that the problem is a false positive. That is, every application built on MDX 1.1 may have a non-deterministic deadlock risk due to mistakes in the Managed C++ stuff in .NET 1.1. I'm not really sure if the problem exists or not, but I was not happy with the situation and I have yet to see a convincing technical description of why the loader lock warning isn't a danger. Lastly, there were some design things in MDX that I didn't like. Some were minor issues, some were bigger issues. It was the combination of these three factors that led me to build a replacement library in C++/CLI that would allow me to pull free of this whole mess. The library is somewhat tailored to my specific needs, so I can't reasonably claim that it is suitable for everyone else, or in fact anyone else. However, I felt that it was worth gauging initial interest in the codebase. Status: ALL non-D3D technologies are currently missing from this prototype. I would like to add them eventually, but they're not in right now. As far as the D3D stuff, this library was built by tearing MDX out from under my latest project and replacing it with SlimDX. As a result, I've essentially implemented the subset that I use. There are a few conspicuous omissions. First, the entire fixed function pipeline is missing. Very nearly all of the render states are missing. None of the Get* functions are implemented on the device, and honestly, most of the Set* functions are missing too. There are holes in the math library, particularly when dealing with quaternions and Vector2. There are two specific bits which were omitted by design. First, all of the event stuff is completely gone. Second, resources are not automatically released. If you do not dispose something, it will leak. I don't intend to introduce the event structure. However, I'm still examining the automatic release thing, so that's not nailed down yet. My thinking on this point is that automatic release disables D3D's leak detection and makes it harder to track code mistakes where things were not disposed. However, I do know that some people use automatic release as a crutch and are not disposing at all. One possibility is adding a flag to switch automatic release on and off, similar to how MDX allows you to enable or disable exceptions and events. This thing is a prototype, not a production library. If you need a stable, complete DX wrapper under you, switching to this thing now would be ill advised. Future: There are two possibilities here. One is that people simply don't care. I'm fine with that, and I'll simply continue using the library and filling in stuff as I see fit. The other is that there is substantial interest. In that case, I would like to license out the library under a non-restrictive open source license (possibly LGPL) and make it available at Sourceforge. The hope is that people will be willing to fill things in that they use, and the library will expand to fit people's needs as a result. This only works if people are actually willing to submit patches; otherwise, the library just stagnates. [Link Removed] Again, I originally wrote this for myself. If you don't think it's worth the bother of making it public, feel free to say so. Still, I have seen a lot of complaints about the current state of DirectX and managed code, so I'm curious how many people are actually dissatisfied with Microsoft's choices on the matter and would prefer to work with an open source library. [Edited by - Promit on June 19, 2009 10:04:23 AM]

Hmm..Ralf Kormann (Deimrug or Demirug on GDNet) is already working on an MDX replacement as well, integrating it into his MD3D10 project (MIT license). I was planning on joining him in development earlier, but I've been kept back by some delays in the Overlay library. Perhaps you two can join forces?

It doesn't really make much sense to me to have D3D9 and D3D10 as part of the same project. I'm also not sure where he plans on going with his, as there seems to be no particular talk on the codeplex page about it.

Also, is there any reason to choose codeplex over sourceforge?

Quote:Original post by Promit
It doesn't really make much sense to me to have D3D9 and D3D10 as part of the same project.

They could be separated. That's his call, though.

Quote:I'm also not sure where he plans on going with his, as there seems to be no particular talk on the codeplex page about it.

Yes, because it originated after a discussion in the private MVP newsgroup. Again, we should just wait for him to chime in.

Quote:Also, is there any reason to choose codeplex over sourceforge?

They use Team System for source control, which I prefer. Also, its integration with VStudio is much better than SVN. Their user interface is friendlier in my experience. Their "source code" page gives a much better review of changes to the code over time.

That's about it.

How deep are you into actually having the D3D 9 stuff?

Whilst it wouldn't be easy, I think there would be an enormous amount of value in getting any MD3D9 and MD3D10 interfaces similar.

Obviously they can't be identical - but to use the same design guidelines, rules and so on could smooth out transitions as well as help those cross-targetting 9 and 10 (or would that explode on dependencies?).

Jack

Quote:Original post by Demirug
As I am prefer not to move to far away from the original concepts of both APIs writing a multi API application would as complex as with C++.

I agree - just because .NET is a higher level language doesn't magically make this sort of thing easier.

It was difficult to make my idea clear, but basically I meant having the same design philosophy for MD3D9 and MD3D10 rather than making them source-code compatible or making some trivial "auto-porting" API.

Say a D3D9 developer picks up Promit's MD3D9 API and later wants to check out D3D10 so moves over to Ralf's MD3D10 implementation. If they were somehow 'aligned' then it'd make this transition a whole lot easier, rather than having to go back to square-1 and re-learn a whole different way of interacting with what is, under the covers, a fundamentally similar API.

Anyway... I'm going to stick this thread for a bit to encourage some further discussion. I get the distinct impression there are various members of the community who want to do something about Managed DirectX yet there seem to be a number of blocking factors involved in actually getting it moving forward. Maybe putting this topic in the spotlight will generate the right sort of interest to get things rolling...?

Cheers,
Jack