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.

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