[
this is an interview I originally conducted earlier this year on the prior Managed World]
Tom Miller Interview
by Jason Olson, 1/4/2005
It is no secret that I love game development. It is also no secret that
I love Managed DirectX (otherwise, this whole site wouldn't be here,
would it?). These are the reasons that I am proud to say that I've had
the pleasure over the last month or so to conduct an interview with
Microsoft's Tom Miller, the "father" of Managed DirectX.
In this interview, we will find out how Managed DirectX came to be, as
well as certain design decisions made while creating it. If you enjoy
this stuff as much as I do or you just wish to get an insight into the
man behind the scenes, I implore you to read on!!
JO: How long have you been working at Microsoft?
TM: I started working at Microsoft in May of 1997, although I
didn't join the DirectX team for a while after that. I worked on small
internal projects for MCS (Microsoft Consulting Services) for a few
months before joining the Visual Basic (6) team later that year. I
worked on various tools that shipped with the IDE. When VB6 shipped I
moved over to the Office 2000 team where I worked in the 'core' office
group (not specific to any one component, such as Word, but components
that were shared). I wasn't in the Office team very long though, and
moved over to the DirectX team in June of 1999.
JO: How did you manage to put yourself into a position to spearhead the development of Managed DirectX?
TM: When I was first hired into the DirectX team, my original
job was to help in the development of the samples for the 'new' DirectX
for Visual Basic (5/6) library we were shipping in the DirectX7 SDK.
That quickly led to writing components for the DXVB library itself,
which in turn led to 'owning' the entire DXVB development. While we
were finishing up the DirectX 8.1 SDK (mid 2001), I began looking at
this 'new .NET stuff' that was brewing over in the developer division.
I recognized relatively quickly the high 'potential' for this
technology and began working on a 'prototype' version of directx
running under this runtime in my 'spare time'. Back then, I was calling
this prototype "DirectX.NET" because everything was being called .NET.
Anyway, I worked feverishly on this prototype (the D3D portion) until I
had a working copy of one of the more complex D3D examples in the SDK
at the time. The performance of the sample was about on par with the
DXVB code we had before, but was still relatively 'slow' compared to
the C++ example it was based on. After showing the demo to multiple
people in the group and implementing the rest of the DirectX API, we
had our first 'public' showing of the technology at GDC in March of
2002.
So I guess a short answer to the original question would be: "I was like Nike. I just did it."
JO: What were your primary concerns when first architecting the Managed DirectX API?
TM: Anyone who saw the initial 'alpha' version of Managed
DirectX at GDC back then (I still have the CD!) would barely recognize
the code that Managed DirectX is today. The *very first* design
decision was basically "Make everything look exactly like it does in
the C++ world". The objects were all named just like the COM
interfaces, the structures were all the same (with all the caps like
D3DCAPS9), and there was essentially a 1:1 correspondence between the
managed function and the unmanaged function. The API itself was nothing
more than a simple passthrough between the 'managed world' and the
'unmanaged world'. It accomplished what it set out to do, but when
compared to the great API work going into the .NET Framework itself, it
looked outdated, and 'hard'..
We made a concious decision shortly after that release to focus on ease
of use, and api consistency with the rest of the framework. The API
matured, and many of the benefits it has built in now came from this
focus early on. That being said, speed was never disregarded. After
all, we're the DirectX team, games are the most common things created
with our API's and games need to be fast. If a situation arose and the
'ease of use' method was simply too slow to be used in 'real time' in a
game engine it wouldn't be used. In these scenarios we would provide a
'faster' alternative.
JO: As a developer, how much do you find yourself using Patterns and/or Refactorings, consciously or subconsciously?
TM: Sure, although I'd probably say it's more 'subconscious' now
than anything. It just comes naturally with the territory for me
nowadays.
JO: I notice that a lot of architectural designs with Managed
DirectX correlate to designs already established within the .NET
Framework. How much effort was put into leveraging the design decisions
already established in the .NET Framework?
TM: If you would have seen the original version we showed at GDC
in 2002 you would be surprised at how much it did *not* follow any of
the guidelines.. After that release though (I essentially now had
everything 'working') we spent a large portion of time updating the
assemblies to fall into the guidelines/designs that the rest of the
.NET Framework was using. The entirety of time spent between Beta1 and
Beta2 was this 'redesign' of the API. It was quite a challenging time
to say the least.
JO: Was a tool like FXCop used to verify the design of the Managed DirectX code base? If so, to what extent was it used?
TM: Yeah, we use all of the tools available to us at any given
time, including FxCop. The 'problem' we faced when using FxCop is the
enormously large number of 'false positives'.. Managed DirectX is
written entirely in Managed C++ and the code that the compiler
generators FxCop doesn't like. For example, when you declare an event
in MC++ it also generates some protected methods like
'raise_EventName'.. That one item breaks two FxCop 'rules' (no
underscores, protected methods in a sealed class). Multiply that by the
hundreds and you can easily have thousands of these 'false positives'.
We find these tools to be invaluable to the development though, even if
we possibly miss some of the 'real' issues amongst all of the false
positives.
JO: What type of testing takes place against the Managed DirectX API before each release?
TM: While I do have much contact with the test team for the
assemblies, I wouldn't be comfortable speaking for them. I will say
that they have quite a large 'sign off' sheet that they must complete
before each release that includes running all of the tests they have
written, all of the samples, etc..
JO: What are your three most favorite things about Managed DirectX?
TM: That could be interpreted a multitude of ways.. For example,
I consider people using (and enjoying) an API that I designed and built
to be quite awesome. It's definitely my favorite thing about Managed
DirectX by a long shot. However, when looking at the API itself, the
"ease of use" built into the API is another one of my favorite things.
Lastly, i suppose it would be the opportunities that doing that work
has afforded me. It's allowed me to write books, which is something
I've always wanted to do, and with game companies now releasing games
using the API, it's a whole other sense of accomplishment.
JO: What area do you feel has the most room for improvement in Managed DirectX?
TM: API clarity. While the API is already 'cleaner' than the
native API, and more inline with the guidelines that the rest of the
CLR uses, it's still not there. There's still quite a few of esoteric
items that could be improved on. That doesn't even consider the new
stuff coming out with Whidbey such as generics, etc.. These are all
things that I have plans on addressing in the near future.
JO: Any last things you would like to say about Managed DirectX for the readers out there?
TM: Well, not that I can think of right now.. =) Keep writing the games and apps.
JO: Thanks for taking the time to answer these questions!
If you would like to read more about Tom Miller, you can find his blog at http://weblogs.asp.net/tmiller.
As usual, if you have any suggestions for DirectX, you can go through
the normal channels either by using the newsgroups or emailing
directx@microsoft.com.