I know that there are a number of members here who were or are active developers of SlimDX. I've spent quite a deal of time using SlimDX over the last few years, learning both the library and 3D graphics in general (although not nearly as much as I'd have liked in the past year or so). I originally learned DirectX 9 using C++ and dabbling in XNA, but after finishing college and getting a job doing less sexy, more enterprisey .NET development, when I came back around to wanting to do game programming again as a hobby, I was very happy to come upon SlimDX, and all of the work that its team had done. After a couple of years of using C#, NuGet, LINQ, and ReSharper, being able to leverage that experience and tooling, rather than having to go back and dust off my out-of-date C++ skills was great. Huge productivity enhancer. While I haven't managed to do anything wildly successful yet with SlimDX, I did write up a series of tutorials based on Frank Luna's DirectX 11 book as I worked through it, which get a fair amount of traffic.

I was originally a history major, and I have an odd impulse to learn the history of things that I work on and am interested in. Some of my favorite programming books are those that tell the stories of the people and events related to software, like Hackers, Masters of Doom, Console Wars, and Stay Awhile and Listen. Also Raymond Chen's blog, which is littered with little pieces of history about the development of Windows.

With that in mind, would anyone involved in SlimDX be interested in sharing any stories about the project?

• Motivations for starting the project? (From what I vaguely recall, lurking here years ago, it sort of took off after Managed DirectX was deprecated, as a more direct alternative to XNA)
• How was the project organized, and the work divided up?
• Any interesting technical challenges along the way?
• Where there any interesting dynamics when 3rd party game studios used SlimDX in their games?
• What's the story with SharpDX?
• How have the rise of other .NET based game engines (mostly Unity, it would appear) affected interest in SlimDX?
• Plans for the future? I believe I had seen earlier this year, when the DX12 previews and docs were coming out, that Promit was looking at a DX12 version.

Thanks, looking forward to any responses

I don't have time right this minute but I'll give you a full rundown soon.

[Edit] And here it is. WIP to be expanded as I go.

1) Why was SlimDX started?

In 2006, I had a class which required us to do a sizable project in a 'pure OO' language. We wrote a game in C#, using the Managed DirectX 2.0 library. At this time, .NET 2.0 was still relatively recent having been introduced in VS 2005, and MDX 2.0 was still a 'beta' library with 1.1 being the stable branch. It worked well enough though. That spring/summer, it was announced that MDX 2.0 would never become a production library, and the first public previews of XNA were published. (Aside: I was working at Microsoft that summer, and managed to briefly visit with Tom Miller, who mysteriously had an Xbox 360 dev kit in his office. I was asked not to mention it.)

I felt that XNA was technically deficient and filed a couple of early high profile bugs/feature requests. It became clear that I did not see eye to eye with the MS team on how a managed wrapper should look, and I went back to using MDX 2.0. Unfortunately the MS guys had neglected to mention that all of the MDX beta releases were time bombed: you could see in the decompiled source that it checked the current date against a hard coded value and generated an exception, but no one had noticed. So it wasn't just that the beta library was deprecated or not recommended, but that the whole thing literally stopped working overnight. MS refused to release a usable build of MDX, existing code didn't necessarily translate well, and the existing userbase was rightly pissed off.

Remember I'd just written a game? I had a bunch of engine code which was relatively lean and simple in its DX API usage but had some sophisticated tricks that weren't XNA friendly. I figured that it might actually be easier to rewrite MDX than rework the engine. Maybe a week of learning C++/CLI and wrapping work later in December 2006, I had a library that was now source compatible with MDX 2.0, as far as my engine was concerned. I spent the next couple months refining both engine and wrapper to suit my own interests and thought nothing more of it.

Probably some time around March 07, I was discussing the work with a friend of mine, Josh Petrie, who convinced me that people other than me might be interested in seeing and using the library, and signed on to help me out. The name was chosen to sound similar to MDX, while conveying that it was meant to be a simplified minimalist replacement, not a total coverage DX wrapper. I initially published it right here:

http://www.gamedev.net/topic/445970-slimdx----a-prototype-mdx-replacement-library/

That thread has a pretty good run down of what the library looked like at the time, and offers something of a window into my own mindset. It also highlights that I wasn't the first to do this, as Ralf Kormann was working on a (initially) D3D 10 wrapper, which ultimately fell by the wayside. I don't know why. The original source code continues to live on at the beginning of the SVN history:

https://code.google.com/p/slimdx/source/detail?r=2

Check out how many render states were implemented, and how much the Device class was capable of. That was slim. Anyway, Washu joined in to contribute some code within a couple days, and you can see Mike Popoloski's early interest. He eventually starts contributing code in early August, and that's been the core team ever since. You can also see that we start making breaking code changes from MDX almost immediately, and it's a torrent of activity in general.

Aside: In summer 2007 I was working at NVIDIA on the DX9 driver team, which gave me incredible visibility into how the core graphics subsystems actually worked. While not directly relevant to SlimDX work, it did make it clear that worrying about overhead from managed<->unmanaged transitions is pointless. Between working at both MS and NV, I think it helped me build something of a reputation as being uniquely suited to run such a project. That itself is something that still follows me in surprising ways.

2) How was the project organized and managed?

Things needed to get done, people went in and did them. The primary collaboration was and always has been via IRC. Broadly speaking we were working on different subsystems: I was heading up the D3D 9 work, Josh convinced me that D3D 10 should be included and was busy building it, Mike volunteered to deal with the DirectInput code. Washu wrote XInput and was also dealing with math library and architectural stuff, as he had the strongest understanding of the .NET Framework/runtime underpinnings. Later on we'd either use the bug tracker to manage tasks, or just discuss in IRC and do the work.

Ultimately, Mike probably did the heaviest lifting in terms of overall code volume, and dealt with a lot of the really tedious stuff, D3DX in particular. He did a lot of the samples, too. Josh did D3D 10 and I think all of the 11 code. Washu wrote random bits and pieces and addressed a variety of architectural and performance problems. I did D3D 9, D3DX, core library design, developed the main wrapping techniques that we used, etc. I also did documentation, installer, releases, that sort of thing. There were a few other contributors over the years, usually for specific goals.

I would like to note at this point that the site was hosted for many years free of charge by Rim van Wersch, first as a subdomain of mdxinfo.com (which is amazingly still up) and later as its own site. We moved to our own hosting much, much later.

I wrote about some of the technical issues we ran into on my old blog. One of the longer-reaching problems we had, in my opinion, was with object lifetime. We used IDisposable as a convenient way to wrap the COM reference counting semantics, but this ended up being a bad idea because the concepts did not map 1:1, even after we implemented an object table holding all the SlimDX object references to ensure we kept only a single reference count.

3) Interesting technical challenges

Lifetimes and object identity existed together as a vexing headache. We wanted the library to behave like a sane managed library would. Simple IDisposable interface, predictable object identities, etc. One of the big motivating problems was something that I think we called the Get == Get problem. Essentially it looks something like this:

var bb1 = device.GetBackBuffer();
var bb2 = device.GetBackBuffer();
Debug.Assert(bb1 == bb2);
bb1.Dispose();

There are two behavioral goals for this snippet. One, the assert should pass. Two, that Dispose call should destroy the underlying object. (And this should be true for all CLR languages.) Neither is true in the naive implementation of the library used early on. Each call gets a native pointer, wraps a new managed object around it, calls an AddRef on the underlying COM object, and returns it. The reference equality fails (the object identities are not the same) and both need to be Disposed separately. I ultimately solved the problem through the aforementioned object table, a tool that in retrospect I still have extremely mixed feelings about. In the vast majority of cases, it actually does its job quietly and magnificently, as well as enabling some very useful debugging techniques. But in the bad cases, it gets really problematic. As Josh noted, we had not planned on using that design again if we were going to take another crack at rearchitecting the whole library.

Building documentation was oddly a real pain. MS went to a lot of trouble to build this comment documentation stuff into VS, but apparently it never ever occurred to them that, gee, maybe somebody else would want to be able to publish miniature forms of MSDN for their work. Eventually Sandcastle appeared and I used that with many custom patches. In conjunction with SHFB, it works really well to make CHM documentation. It is (was?) however entirely useless for building websites. I eventually did some more custom patches and homebrewed a site with JQuery and that's what drives the current documentation.

4) Future plans

When SlimDX was built, we all had a lot more time on our hands. I want to simply hand implement (not auto gen) the SlimDX 2 design for D3D 12, roll the math library in, and call it a day. This is somewhat complicated by a few things. First, life. I have a lot of it nowadays and that's getting inconvenient. Second, at a personal level I have a lot of doubts about D3D 12's near-term viability and a lot of optimism about Vulkan, which is complicating things. I still want to do it, but I'm not in that big a hurry.

Building documentation was oddly a real pain. MS went to a lot of trouble to build this comment documentation stuff into VS, but apparently it never ever occurred to them that, gee, maybe somebody else would want to be able to publish miniature forms of MSDN for their work. Eventually Sandcastle appeared and I used that with many custom patches. In conjunction with SHFB, it works really well to make CHM documentation. It is (was?) however entirely useless for building websites. I eventually did some more custom patches and homebrewed a site with JQuery and that's what drives the current documentation.

4) Future plans
When SlimDX was built, we all had a lot more time on our hands. I want to simply hand implement (not auto gen) the SlimDX 2 design for D3D 12, roll the math library in, and call it a day. This is somewhat complicated by a few things. First, life. I have a lot of it nowadays and that's getting inconvenient. Second, at a personal level I have a lot of doubts about D3D 12's near-term viability and a lot of optimism about Vulkan, which is complicating things. I still want to do it, but I'm not in that big a hurry.

I ultimately solved the problem through the aforementioned object table, a tool that in retrospect I still have extremely mixed feelings about. In the vast majority of cases, it actually does its job quietly and magnificently, as well as enabling some very useful debugging techniques. But in the bad cases, it gets really problematic. As Josh noted, we had not planned on using that design again if we were going to take another crack at rearchitecting the whole library.

Thanks Promit, Josh and Washu, for taking the time to respond.

Seeing it again, I definitely do remember seeing that initial announcement thread, back in the days of the old site.

I'm continually amazed at how often, when you get down to it, a small team of talented people can produce very high quality results. Software is so incredibly nonlinear - throwing more bodies at code gives diminishing or even negative results.

I'll have to go look at the source again soon and go find the object table implementation. Using IDisposable in SlimDX does sort of propagate up through any code that uses it; on the other hand, SlimDX was the reason I learned about the IDisposable pattern and how to implement it correctly in C#. What are some of the bad cases where using the object table falls down?

On another note, what kind of qualifications does it take to be recognized as a Microsoft MVP? I'm sort of curious, because in my day job, I work with a MS technology stack that literally three people ever blog about. Are having Microsoft connections a big deal there?

It's been almost 8 years exactly since my first commit. I was 17 at the time, still in high school, and therefore had a ton of free time on my hands. You can see in that initial announcement thread that I found myself interested (I had only recently gotten into C# and was playing with MDX). I PMed Promit, offered to work on DirectInput and got commit access (suspiciously easily actually. I think the idea of avoiding DirectInput work outweighed the fact that he didn't know me very well).

I didn't know C++/CLI at the time. It's an incredibly bizarre language and I'll do anything in my power to avoid using it on any project I ever work on again. I dug up an old journal entry where I list a few random quirks and then this one where I talk about the insanity of friend assemblies in C++/CLI. Fun times.

The fact that I had so much free time first in high school and then in college after that meant that I ended up doing the bulk of the tedious wrapping code. Poor Promit and jpetrie already had day jobs and had to come home and put in more work at night. From looking at the repo, I was responsible for Direct3D11, DirectInput, DirectSound, XAudio2, RawInput, X3DAudio, XAPO, D3DCompiler, Direct2D, and DirectWrite. Also lots of other random junk; the D3DX animation stuff is still a distant nightmare for example. We also ended up with a collection of neat little tools; one for counting lines, another for generating release notes, documentation, and website junk. There's one in there I remember writing to work around a crash in Microsoft's PIX tool where you couldn't run it on managed x64 assemblies.

At some point I made us an icon; it's been set as my avatar image ever since.

As Josh alluded to earlier, we had a great persistent bug in our memory allocator that we eventually tracked down. It's one of those ones that will stick with us probably forever. I eventually went back and replaced that whole system with the one that's still in use today. We very often need temporary space when marshaling parameters, so stack allocating that space is key to good performance. Unrelated: when wrapping some of the hairier parts of DirectInput I took a look at what MDX used to do and discovered some hilarity.

Right around the end of 2009 / beginning of 2010 development started to slow down. The library was stable, fast, and covered almost everything in DirectX, and a good deal more on top of that. Shortly after that MS released the June 2010 SDK, which was the last DirectX SDK drop. We worked for another year or so polishing things up, at which point MS announced Windows 8 and discontinued the SDK. Nobody on the team was interested in Windows 8, so we went into what was essentially maintenance mode.

Working on SlimDX was a ton of fun. It felt good to be working on a project lots of other people would actually find useful, and probably cemented in me my love of developing libraries and middleware. Every once in a while we'd discover some game or project was using our library. That SlimDX.dll would pop up in very surprising places over the years.

Working on the project was also a great way to network; I joined the #gamedev IRC around that time and got to know jpetrie, Promit, and Washu pretty well. Later on jpetrie recommended me for a job at ArenaNet out in Washington, so SlimDX was essentially my ramp into the games industry. The number of people I'd randomly meet who knew of the project was surprising. When I was at ArenaNet, we'd occasionally interview people who had used the library and had listed it on their resume. When we interviewed our audio programmer he started talking about how he had used it for his own personal audio projects he was working on. Going back further, one day I was in class at school, and the kid in front of me had the SimpleTriangle tutorial open and running on his laptop. We ended up becoming friends and roommates for the rest of my three years there based on that.

The SlimDX team has since moved on to different things, but I think we all still look back fondly on the project. We stepped up at the right time and provided a good product for people who needed it. The last binary release we did, in January of 2012, has over 500,000 combined downloads. I don't know if we'll ever take it further or even if we'll work on something different together; Josh is off in OSX land these days and Promit is swamped with shipping indie-ish games for mobile. I've been helping out with improving and wrapping a low-level graphics library developed by a former ArenaNet colleague. I feel like this is probably the way to go for any future game projects I work on.

Thanks for the interest; it's always fun to take a trip down memory lane.

Thanks, Mike, I'll have to go looking through your journal

Going back further, one day I was in class at school, and the kid in front of me had the SimpleTriangle tutorial open and running on his laptop. We ended up becoming friends and roommates for the rest of my three years there based on that.

That is pretty cool

As a user of SlimDX, I'd like to thank you all for your hard work.