There's no doubt about it, SlimDX has finally caught up to DirectX in terms of features. Sure, there are still little things here and there, but for the most part we cover every major part of the DirectX SDK, as well as several secondary libraries deemed beneficial for multimedia and game development. Once our next release hits (probably around February, if our covert intel is correct), things should be pretty stable in D3D11 land as well. Of course there is still plenty of bug fixing, documenting, and sample writing to do, but you don't plan future library development based upon maintenance tasks like that.

So we started postulating as to future plans for our little brainchild which is now all growed up. We've gathered up a list of changes we'd like to make, big ones that mean breaking changes for just about all our users, which we had held off on before in favor of library stability. These changes will be part of what we are internally referring to as our "2.0" release. The SlimDX version number is already higher than that, but this will be the first major shift in the library since we came out beta several years ago.

What might this "2.0" release entail? Well for starters, Josh has been chomping at the bit to switch us over to using interfaces instead of concrete classes as much as possible. This facilitates unit testing not only for ourselves but for our clients as well. While this requires a huge set of changes across the library, users will face only mild breaking changes where we end up returning an interface where previously we had a concrete class, which will require an additional cast to fix.

Ever since things slowed down on SlimDX, the team has been branching out to other side projects. Promit started SlimTune, a free profiler for managed applications. Josh started an overhaul of the sample framework, and has only recently started work on SlimBuffer, which will contain a refactored version of the DataStream functionality currently in SlimDX. "2.0" will depend on this new library for its native memory management needs.

Washu and I started work on SlimGen, which is a tool that injects ASM into a managed assembly at runtime, allowing us to use hand-optimized SIMD instructions directly from managed code with no interop overhead. This will play hand-in-hand with SlimMath, which is an all-managed implementation of the math functionality currently living within SlimDX. SlimDX "2.0" will rely on this library, and external projects can make use of the math functionality without needing the rest of SlimDX, or indeed even needing to be on Windows at all.

Finally, mesh and model handling is a common complaint I see across many different APIs, so I started work on SlimMesh, which will handle the loading of 3D models from several different formats in an API agnostic manner. This will include D3D9, D3D10, and D3D11 renderers via SlimDX to make it usable out of the box, but I suspect users of libraries like OpenTK might find it useful as well.

So yes, we're all still hard at work. The SlimDX group is rapidly becoming a multimedia middle-ware group [grin] SlimDX might be all growed up, but the rest of us are just getting started.

PS. Promit was a genius picking out the "Slim" name for SlimDX. It's a great branding tool and easy to slap on to almost any project.