The History of Managed DirectX

The first public release of Managed DirectX happened on December 20, 2002, with the release of DirectX 9; however, the project had been in development for quite some time. Late in the development cycle for DirectX 8.1, while I was working on DirectX for Visual Basic, I started playing with the first beta of Visual Studio.NET and the .NET runtime, and it was obvious to me that this was the future of development. I began working on a prototype of "DirectX.NET," which would eventually become Managed DirectX, during this time.

From the beginning, Managed DirectX was designed to be just as powerful as the "core" API, with little to no overhead. In the past, Visual Basic users of DirectX lacked the ability to develop applications of similar quality when compared to the core DirectX API. Some of this was due to the Visual Basic runtime itself, while some was due to the overhead of the wrapper DLLs. In DirectX 8, we tried to eliminate some of these performance bottlenecks by removing the wrapping layer for the most performance critical API, Direct3D. Instead of having a proxy DLL that did data marshalling, we moved the Direct3D API directly into a type library. While this did improve performance slightly, in many cases all it did was overly complicate the API, particularly for the Visual Basic developers we were targeting.

After the release of DirectX 8, it was apparent that the API was not very easy to use. The samples were hard to follow and the code didn't look like "normal" Visual Basic applications. Most Visual Basic developers found the API too complicated to use; C++ developers had no reason to switch since there was no benefit in it for them. We were popular with the home enthusiasts, but game studios weren't even aware we existed. Our new API needed to address these issues. It needed to be fast, it needed to be easy to use, and it needed to have a reason for developers to switch from the C++ code they had been writing. The concept for Managed DirectX was born; now we just needed to implement it.

At the Game Developers Conference (GDC) in San Jose in 2002, the first alpha of Managed DirectX was released. It was based on the DirectX 8.1 runtime, and written exclusively in C#. We had most of the core DirectX components in this release, including DirectMusic, which was excluded in the final Managed DirectX release. The only DirectX components not represented in this first alpha were DirectDraw and DirectShow, mainly due to the fact that we hadn't decided whether or not we really would include these components or not. Looking back at that first release, it still amazes me how far it's come. I hadn't really addressed any of the problems that the Visual Basic DLLs exposed yet; all I had really done was expose the DirectX API to C#. There was a one-to-one mapping of every function, constant, and structure in DirectX.

This release was immensely helpful to us. It demonstrated the feasibility of the Managed DirectX runtime, and the feedback we got was surprisingly positive. One of the first things this release showed us was that the performance of this layer was lacking immensely. In best-case scenarios, we could get performance matching the native API, but in even a simple scenario (such as the Cube Map sample), the managed version would run at about 40% of the frame rate that the C++ version did. We had our work cut out for us.

We spent the next few months getting ready for our next release, the first beta of DirectX 9. We addressed all the major performance bottlenecks, added DirectDraw support, removed DirectMusic support, and had begun our ease-of-use improvements. We also made sure we had developers familiar with C# and managed code on the beta list. They would actually use the API to gauge how much we really had made the API simpler. The feedback we received was quick, and unanimous. Performance was fine; the API design, on the other hand, left much to be desired. Managed DirectX looked nothing like other managed APIs; it looked like a COM API. All of the components in the .NET runtime had a similar look and feel, while the Managed DirectX DLLs were completely different. We had two goals for this project: Make it fast, and make it easy to use. While we had delivered on the former, it was evident we hadn't delivered the latter.

A total redesign of the API commenced directly after Beta1. We talked with the .NET runtime team, we talked to the beta users, we gathered feedback from any place we could think of to find out the things that were wrong with our current design, and went about fixing it. I wrote a set of design guidelines that all components would need to adhere to, and the task of actually making our current API follow these guidelines started. Some of the changes were simple to implement, such as casing changes. In DirectX (and COM in general), constants and structure names were normally described in all caps, in the .NET runtime, things were cased properly. Other changes were more in depth in nature, such as adding enumeration support to classes. We released Beta2 and anxiously awaited the feedback from our users.

Much to our relief, the feedback was much more positive. We had taken steps in the right direction, and the API was well on its way to fulfilling our goals. We had more tweaks here and there for the remainder of the beta cycle, further refining our guidelines, and our API. About a month before the final release of DirectX 9, one of the beta releases was posted publicly. This was only the DirectX runtime, not the complete SDK, but did include the Managed DirectX API as well. The buzz for Managed DirectX had been building for some time now, and this was most developers' first exposure to the API. Without any samples or documentation, would people still be able to use it? This was a litmus test for us. Not only did people figure out how to use it, people started using it then. The feedback we received was nothing but positive. People posted articles on Web sites describing how to use the API. When the final release was posted in December, we had done what we set out to do.