SlimDX -- A Prototype MDX Replacement Library

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.

The Direct3D 9 and 10 elements life in two namespaces and share only some general things like rectangles, boxes, …

As all referenced DLLs (DXGI, D3D10, D3D9, …) are marked as delay load it would work without problems on Windows XP.

If someone doesn’t need the D3D10 part it could simply be ignored.

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

The core (D3D9) is nearly complete but D3D9X is still mostly missed.

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

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++.
Normally I want keep this secret until I can show you something but I want to add a third Direct3D namespace. “Universal Direct3D” (work name) would be an API that maps to Direct3D 9 and 10 at the same time. If anything works out right it should be possible to write applications that use the same source code for 9 and 10. But before I can add this to the managed Layer I need a native C++ implementation first. It will mostly based on the new Direct3D 10 concept but adding some element from D3D9 like the caps, device resets, …

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

This is almost the exact thing that I was considering doing, and I still have come to no definite conclusion. I haven't liked the look of XNA, particularly the lack of freedom when doing things in Windows, as you have said, XNA is an XBox library with Windows tacked on.

I think that providing a library for this is a great idea, and I just need something that I can focus my attention on. Basically, I am looking for some sort of stability in the world of managed games, and so far I am not getting it from Microsoft. Perhaps a community developed library on top of the more stable DirectX 9 and the forthcoming DirectX 10 would be the sort of stability needed for more developers to get on board with managed languages for games.

I would definitely also love to help out in any way possible. I think, however, that someone should sit down and think things through, before you start doing anything more substantial. There is, of course, no good reason to have both of you developing independent libraries, when everyone working on one would yield much better results, and a lot less wasted code and time. The two APIs for DirectX 9 and DirectX 10 should definitely by combined, but the core components should be separate from each other, with only the supporting classes merged together for code reuse as well as to facilitate the usability of the library.

Frankly, I think it is a great idea, and for some reason I trust members of this community to get it right more than I trust Microsoft. Their actions lately have shaken my faith in anything they put out as far as managed game libraries go. Hopefully this can grow into something that will become the DirectX of the managed world: stable, easily used, widely documented, and fully featured.

Quote:

Original post by jollyjeffers 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. Cheers, Jack

Whenever is it possible I try to use the same approaches for both APIs. Like the rules for the object ownership.

For anybody watching, SlimDX is being hosted over at Google Code here. You can follow the development and grab the latest (still very much "in progress") code there.

Any particular classes which people find important? All the really popular stuff like textures, surfaces, buffers, graphics stream, font, and sprite are in. Also the math library is progressing nicely, though Vector2 and Vector4 are missing bits, as is Quaternion.

We also wrapped up XInput completely. There's little bits of DirectInput, but not a lot yet.

By the way, the "slim" in "SlimDX" is serious. We're stripping out a lot of unnecessary cruft. No CustomVertex stuff. No ToString() overloads. That sort of thing. There's also a big emphasis on improving orthogonality, which was a huge problem in MDX. The math library is heavily simplified (and will probably be performance tweaked later, thanks to research Washu has been doing -- check his blog). Consider loading textures in MDX -- do you want new Texture, Texture.FromSomething, or TextureLoader.FromSomething? SlimDX makes it simpler. No more texture loader. If you want to load from a source, you use Texture.FromSomething, and you use new texture to create a blank texture. Also, you can load directly from memory now. You couldn't do this in MDX; the best you could do was to use a MemoryStream, which caused an extra copy internally.

Anyway, just wanted to give an update.

I like this project and I love that you deviate slightly from the original API to make it all a little more obvious.

Classes/structs that I'd like to see are the obvious ones, I am not working with anything out of the ordinary (yet). Oh, please don't lack device/displaymode/capabilities enumeration.

Mesh support?

Some of it is there, it isn't quite fleshed out. I'll go ahead and put that in soon, probably another day or two.

Shaders / Effects?

Effect is very close to complete, metadata/reflection and all. The stuff that's missing is include/macro/pool/state manager. The lower level shader stuff hasn't been written in, since I have yet to encounter code that is actually using it. (Same story for the missing effect helper junk.)

As of now I am soley a c# programmer. If I'm reading right then SlimDX is a wrapper for Unmanaged DirectX. Is this correct?

Anyways, I think it's a super idea. I can see that it could actually become better than the original?

-Devin