The DirectX Box

Xbox founder’s award

While working on DirectX, I became friends with Ted H who was responsible for DirectX developer evangelism. His team was on the front lines with the game developer community and provided information, education, and hands-on support. Because of the team’s close relationships with game developers, they had a good sense of what the community wanted, and helped guide the evolution and prioritization of DirectX functionality.

Ted’s office was in Building 4, and at the time, the cafeteria there had a rare resource – an external food vendor called Pasta Ya Gotcha. They were a welcome change from the generic on-site institutional food fare, and Ted and I started having regular lunch meetings to discuss the state of the technology world and where things were headed. For me, it was always a toss-up between the Texas Tijuana, Tennessee Jack, and Thai Peanut entrees.

Although we were just starting work on DirectX 8, Ted and I both could squint and see the day of diminishing returns with Windows PC computer graphics. We were starting to ask “What’s next?” We had made significant strides legitimizing the PC as an entertainment-capable platform, but entertainment was not a natural destination for the PC. The PCs on the market were big and bulky, and engineered for productivity.

We were also keenly aware of the ongoing battle for supremacy in the living room between Sony, Sega, and Nintendo, with Sony in rapid ascendency. Where was Microsoft? Was it going to get into this fight, and if so, how?

At the time, Microsoft had a partnership with Sega to ship Windows CE on Sega’s platform. Sega already had their own development tools, infrastructure, and content development pipeline, though, so CE brought nothing fundamentally new or compelling for game developers. Windows CE had a very limited implementation of DirectX, so there was little incentive for a Sega developer to use anything other than Sega’s own tools. Windows CE checked the box in terms of having a Microsoft living room platform strategy, but it offered neither better economics nor higher quality of content.

DirectX was part of Microsoft’s Windows division, and Ted and I felt that Microsoft was missing an opportunity to lead with its strengths. We had a vibrant developer ecosystem, operating systems leadership, great relationships with silicon vendors, and a name-brand game API. Why not bring DirectX in the form or a platform to the living room?

With a kernel of an idea, we needed recruits. Ted brought in Kevin B from his team to help think through business models, and I drafted Seamus B, a recent PM hire for DirectX, to help plan and coordinate.

A handful of intrepid and talented developers on my team signed up to build the proof-of-concept of a Windows/DirectX-based living room device. Colin M led the effort to construct a prototype that would prove the idea: that a PC-based architecture could boot up in a few seconds and play games without input from a mouse or keyboard.

This was an all-volunteer effort, and our managers were not yet aware of what we were up to. We all had our regular jobs to do, and we didn’t want to jeopardize progress by asking for official support. We chose to stay in stealth mode knowing we could be punished with the dreaded 3.0 annual review score – or worse. But we believed we were onto something important.

Word was getting around. As we made progress, people came on board to help, advocate, and advance the cause of what Ted had named “Project Midway”. I no longer recall when my manager became aware of the effort.

At a critical point, Nat B offered to help build support in the right executive circles and to make the pitch. He was the technical assistant to the guy running Microsoft’s consumer version of Windows. I remember talking to Nat on my chunky, red Nokia on a typically horrific commute from Redmond to Seattle across the 520 floating bridge. Among other things, he was eager to have a more marketable name for our effort. At its essence, what we were proposing was a DirectX device – a box – in the living room. A DirectX box. I think it was Nat who suggested “X-box” for short.

At this point, X-box wasn’t about Microsoft building its own hardware; hardware is capital-intensive and Microsoft’s expertise was software. We thought partners could build the hardware and Microsoft would build the software ecosystem. Getting into the console hardware business was not yet a consideration.

Somehow, we got a billg meeting. We were expecting an intimate gathering in the usual windowless conference room with twelve or so chairs.  Colin wheeled in a small but sturdy cart with the prototype hardware. We passed out our printed Powerpoint slides and readied ourselves for the pitch and a lot of other people started showing up. By the time we were underway we found ourselves seated with two rows of people behind us, sitting, standing, leaning, and filling the space. Nat spoke. I went over the technical details. There was some other discussion. Colin pressed the power button. A few, anxious seconds later, he was playing a game on a TV with a game controller in his hand. Bill was convinced. There was also a very nice Powerpoint presentation about a future version of Windows CE for consoles, but it didn’t stand a chance next to a real game running on our own technology stack.

An expensive agency was later hired to come up with a real product name to replace “X-box”. They removed the hyphen, and came back with “Xbox”.

DirectX

This is part three; part one is OpenGL, part two is Early 3D hardware.

As the team continued to work on improving OpenGL’s capabilities, another graphics technology effort – DirectX – had also been moving forward in parallel. In this earlier era at Microsoft, it was not uncommon to have overlapping product efforts, or even efforts the competed directly against each other. The prevailing attitude about such cases was to let the market decide. DirectX was focused on enabling games on Microsoft’s Windows 95 consumer operating system. DirectX got its start as a 2D-based technology providing game developers direct access to the graphics card’s frame buffer. This was very useful functionality up to a certain point, but games like Doom and Quake made it clear that 3D graphics would play a dominant role in the future of interactive games.

Microsoft purchased one of the few available software-based 3D APIs – Rendermorphics’ Reality Lab – early in 1995. The goal was to jumpstart the addition of 3D graphics capabilities to DirectX by incorporating the Reality Lab technology. I was asked to do the technical due diligence of the Reality Lab stack.

Unlike OpenGL, Reality Lab was a scene graph API. This meant that the full geometric representation of a 3D environment was fed to the API. Based on the viewer’s position and other variables, the scene graph engine would compute the necessary details for rendering the objects in the 3D environment all the way down to the individual primitives rendered at the end of the pipeline. As a scene graph API, I thought Reality Lab was pretty good, but it seemed to me an odd match for the intended game developer audience.

Games like Doom and Quake built their own engines for rendering 3D environments, and these engines were highly optimized and specialized for the game’s specific characteristics. What most game developers were looking for was a lower-level immediate-mode 3D API that allowed them to plug their game engines at the stage of processing where primitives were ready to be rendered.

DirectX hoped to satisfy this need by providing a mechanism for developers to pre-construct lists of low-level graphics primitives that could then be handed to the graphics card driver to execute. In theory, this allowed direct hardware execution of 3D primitives. In practice, the interface was cumbersome and difficult to use, provided no performance benefit for all the extra trouble, and had limited functionality compared to OpenGL.

What game programmers like John Carmack were discovering was that OpenGL already provided a clean, efficient immediate-mode 3D API that could be used very effectively for game development as well as non-game applications. Whereas DirectX required adhering to overhead-inducing COM-based protocols, OpenGL was a clean, straightforward, well-documented C API.

The game developer community tends to be data-driven and immune to market-speak and spin; their bullshit detectors can be exceptionally good. They were being told to use DirectX for 3D games, but they wanted to use something proven that already existed and just worked. John Carmack’s observations on the topic is still a good read.

More and more developers were coming to Microsoft and demanding that it fully support OpenGL on both Windows NT and Windows 95. The technical work for Windows 95 had already been done, and hardware vendors work working with a pre-release version of the OpenGL MCD driver development kit anticipating final release. Developers wanted the OpenGL driver update for Windows 95 released as soon as possible.

An influential group of game developers even banded together and signed an open letter to Microsoft asking that OpenGL be fully supported on both Windows NT and Windows 95.

This was not how it was supposed to work out. DirectX was supposed to be Microsoft’s consumer graphics technology, and OpenGL was supposed to be “just” for high-end CAD for non-consumer markets. But the reality was that visualization technology didn’t care about somewhat arbitrary market segmentations: a good 3D API was a good 3D API. Many developers felt that OpenGL was the best 3D API at the time and wanted to use it for their games. This has been described as a religious issue, but game developers simply wanted tools that would help them get their work done.

Microsoft was in a tough spot. It now had two competing efforts on its hands, and it couldn’t simply kill either. OpenGL was necessary for continuing to compete in the workstation market, and DirectX was its high-profile brand and technology for enabling PC games. And while OpenGL was an external standard, Microsoft owned DirectX and was free to shape it on its own. Even though Direct3D had gotten off to a rough start, Microsoft couldn’t afford to retrench from DirectX.

The open letter had pushed things to a crisis point, and shortly after it went public I had a meeting with the senior manager in Windows whose task had recently become to clean up the OpenGL/Direct3D mess. I remember the central point of the conversation was that I was being asked to take responsibility for both OpenGL and DirectX graphics and to focus on ensuring that DirectX improved as quickly as possible while continuing to support OpenGL for non-game applications.

This would mean a number of things for me. I would have to leave programming as anything other than an occasional hobby since I would have my hands more than full with providing engineering leadership. I would never see my MCD driver work available in the much larger Windows 95/98 market. And I would also have to disappoint a large contingent of game developers who had hoped for a different outcome.

Of course I could have gone and worked on something else, but that would have served no constructive purpose. Microsoft was sticking with DirectX graphics, and the best thing for developers, users, graphics vendors, and Microsoft was to make DirectX as good as possible. Combining the OpenGL and DirectX graphics development efforts was probably the best way to achieve that; the OpenGL team had at this point a deep bench of 3D graphics talent.

So I said yes, and began the hard work of integrating and re-balancing the teams and getting people on board with a slightly awkward new mission and new priorities.

Over the course of the next three years we steadily improved DirectX. I felt we had finally accomplished our goal of building a world-class 3D API when we released DirectX 8.

The experience was a formative one for me. I had to step outside the emotions surrounding the situation to find a way to make the greatest positive contribution possible. I had to earn the trust of a new team that had viewed my team and me as the enemy. And I had to take something that I felt was technologically inferior and make it great.

But great challenges can provide great opportunities…