SlimDX vs. SharpDX

Phew! Been very busy around here. The Holofunk Jam, mentioned last post, went very well — met a few talented local loopers who gave me invaluable hands-on advice. Demoed to the Kinect for Windows team and got some good feedback there. My sister has requested a Holofunk performance at her wedding in Boston near the end of August, and before that, the Microsoft Garage team has twisted my arm to give another public demo on August 16th. Plus I had my tenth wedding anniversary with my wife last weekend. Life is full, full, FULL! And I’m in no way whatsoever complaining.

Time To Put Up, Or Else To Shut Up

One piece of feedback I’ve gotten consistently is that darn near everyone is skeptical that this thing can really be useful for full-on performance. “It’s a fun Kinect-y toy,” many say, “but it needs a lot of work before you can take it on stage.” This is emerging as the central challenge of this project: can I get it to the point where I can credibly rock a room with it? If I personally can’t use it to funk out in an undeniable and audience-connected manner, it’s for damn sure no one else will be able to either.

So it’s time to focus on performance features for the software, and improved beatboxing and looping skills for me!

The number one performance feature it needs is dual monitor support. Right now, when you’re using Holofunk, you’re facing a screen on which your image is projected. The Kinect is under the screen, facing you, and the screen shows what the Kinect sees.

This is standard Kinect videogame setup — you are effectively looking at your mirrored video image, which moves as you do. It’s great… if you’re the only one playing.

But if you have an audience, then the audience is looking at your back, and you’re all (you and the audience) looking at the projected screen.

Like this — and BEHOLD MY PROGRAMMER ART!

No solo performer wants their back to the audience.

So what I need is dual screen support. I should be able to have Holofunk on my laptop. I face the audience; the laptop is between me and the audience, facing me; I’m watching the laptop screen and Holofunking on it. The Kinect is sitting by the laptop, and the laptop is putting out a mirror-reversed image for the projection screen behind me, which the audience is watching.

Like this:

With that setup, I can make eye contact with the audience while still driving Holofunk, and the audience can still see what I’m doing with Holofunk.

So, that’s the number one feature… probably the only major feature I’ll be adding before next month’s demos.

The question is, how?

XNA No More

Right now Holofunk uses the XNA C# graphics library from Microsoft. Problem is, this seems defunct; it is stuck on DirectX 9 (a several-year-old graphics API at this point), and there is no indication it will ever be made available for Windows 8 Metro.

I looked into porting Holofunk to C++. It was terrifying. I’ll be sticking with C#, thanks. But not only is XNA a dead end, it doesn’t support multiple displays! You get only one game window.

So I’ve got to switch sooner rather than later. The two big contenders in the C# world are SlimDX and SharpDX.

In a nutshell: SlimDX has been around for longer, and has significantly better documentation. SharpDX is more up-to-date (it already has Windows 8 support, unlike SlimDX), and is “closer to the metal” (it’s more consistently generated directly from the DirectX C++ API definitions).

As always in the open source world, one of the first things to check — beyond “do the samples compile?” and “is there any API documentation?” — is how many commits have been made recently to the projects’ source trees.

In the SlimDX case, there was a flurry of activity back in March, and since then there has been very little activity at all. In the SharpDX case, the developer is an animal and is frenetically committing almost every day.

SharpDX’s most recent release is from last month. SlimDX’s is from January.

Two of the main SlimDX developers have moved on (as explicitly stated in theirblogs), and the third seems AWOL.

Finally, I found this thread about possible directions for SlimDX 2, and it doesn’t seem that anyone is actively carrying the torch.

So, SharpDX wins from a support perspective. The problem for me is, it looks like a lot of DirectX boilerplate compared to XNA.

I just, though, turned up a reference to this other project ANX — an XNA-compatible API wrapper around SharpDX. That looks just about perfect for me. So I will be investigating ANX on top of SharpDX first; if that falls through, I’ll go just with SharpDX alone.

This is daunting simply because it’s always a bit of a drag to switch to a new framework — they all have learning curves, and XNA’s was easy, but SharpDX’s won’t be. So I have to psych myself up for it a bit. The good news, though, is once I have a more modern API under the hood, I can start doing crazy things like realtime video recording and video texture playback… that’s a 2013 feature at the earliest, by the way :-)

11 Responses

If you are looking for a higher level API, you should better look at MonoGame (on developer3d branch), as ANX seems to be pretty dead.Though current support for Windows DirectX is only available for Win8 Metro App.

The toolkit looks great. Does it already support the equivalent of SpriteBatch and PNG loading? My entire app ONLY uses SpriteBatch for rendering, so if that works, I’m an immediate toolkit customer :-)

Alexandre – I don’t see how the ANX project is dead. It seems very much alive. It may be that their binary distribution is not very frequently updated, but the source code seems to get commits quite often.

I looked at them both recently and came to the same conclusion. So I started using SharpDX and had a problem, and got really great support by one of the main authors. It ended up being my dumb mistake of course, but he was very helpful in helping me figure it out.

As a past XNA user, and a current SlimDX user, and quite possibly a future SharpDX user, I can assure you that although it seems like these DX wrappers lack a lot of the higher level ease of XNA, in practice, I find that they are very similar, except that they are more powerful, and with more power comes more responsibility. So for me it is a very acceptable cost, and I’m not a super-programmer by any stretch. You’ll be fine with the switch, if you choose that path. And once you have written you’re engine and your support classes, you’ll be working in a similar way as you are now. Maybe I’m missing something, but I find SlimDX superior to XNA and would never consider moving (back) to such a nerfed Direct X.

I agree that SharpDX has a more active developer. But SlimDX does work perfectly well. I love it. But without active development, it’s not very attractive to new adopters. I’ll keep using SlimDX until after I finish my current project, and then consider moving to SharpDX.

I have an old app that I’m working to update and it is still using DirectX 9 so I would like to update it. I was looking at SlimDX and was wondering if it is a good update or, since I will need to change most of the code can I just go for the SharpDX directly?

Is it simpler to update from DirectX to SlimDX and then move up to SharpDX or this will get fussy? Can I go directly from DirectX to SharpDX?

Sorry for this questions but I am not very informed on how both SlimDX and SharpDX work or if they have strong points that differ from one to another.

I'm a programmer, dad, and general geek living in the Seattle area. Currently I am a senior software development engineer at Microsoft.

My coding interests run towards language design, parallel and asynchronous development, operating systems, and metaprogramming.
I expect the world of software to be challenging, inspiring, and fascinating for the rest of my life; in few other pursuits is there such great possibility.
Email me here.