But I never really understood why Microsoft wanted it’s own 3d api anyway. When they introduced direct3d, they pretty much had control of the market for desktop computer. So the obvious target platform for games was obviously win9x. Why did they care that what 3d api was being used? I can’t really believe they were shaking in fear that people would move to another plaform just because you could easely recompile an application on it.
It’s a question of control.
D3D isn’t the preferred API because Microsoft didn’t adiquately support OpenGL. It is this way because of Direct3D 8.
This was the first API release that could be considered both good and superior to OpenGL (7 was nice, but it wasn’t as solid as 8). No longer could GL users point at D3D and say that it is categorically worse. More than that, however, it had shaders out of the box ready to use. Cross-platform (even though nVidia supported them from the beginning). They had decent performance with their vertex buffers, and they had the advanced features to be useful in the future.
OpenGL relied on nVidia’s extensions. This answer functioned right up until the Radeon 8500 came out. It had programmability, but it used its own set of instructions. It took another year after the 8500, beyond the 9 months or so it was between the 8500 and the GeForce 3, before we would see ARB_vertex_program. We still don’t have a cross-platform API for using NV20/R200 level hardware fragment programs.
Why did this happen? Because the ARB is a committee, and Microsoft is one entity. As a single entity, they can make decisions rapidly. The ARB meets 4 times a year to decide on ARB extensions; Microsoft Direct3D people can walk down the hall and talk to each other. Sure, Microsoft listens to hardware vendors and takes their needs seriously, but a single entity is ultimately responsible for the end result.
This has pros and cons. The obvious pro is speed-to-implementation. D3D can rapidly evolve. The obvious con is that, if the one entity gets it wrong, it’s bad for everyone who has to use it(see DirectX3, 5, and 6).
By creating D3D, it allowed Microsoft the speed-to-implementation that allows them to be in the best position to help game developers make games using hardware. OpenGL simply doesn’t move fast enough.
Quite frankly, I wish either someone would step forward to become the overlord of OpenGL, or a small group of IHV’s on the ARB would form a cabal. In either case, the purpose of this individual/group would be to create quick EXT extensions to add appropriate functionality in a platform-neutral way. Look how long we sufferred without VBO; that’s just rediculous.
EXT_render_target is exactly the kind of thing I’m talking about. No ARB involvement; just a few IHV’s getting together and pumping out a highly useful extension. The ARB can decide on its own time what to do with it.
Also, in many ways, the function of OpenGL (as a graphics standard) is somewhat incompatible with game development. Game developers need quick access to powerful hardware; if the API is horrible, they can work around it. Sure, they would prefer a good API, but they can get that in the next revision of the library. Constant API change doesn’t hurt them too much.
However, OpenGL is supposed to be a standard for graphics rendering. This means that it must be well-thought out because it may last for 10+ years. The audience for standardized graphics rendering can’t handle constant API changes or other things of that nature. They want the right thing, and are willing/able to wait for it. Their customers don’t need bleeding-edge hardware interfaces, so the committee approach is just fine. You add to standards or create new ones; you don’t modify them.