Because OpenGL is ugly as hell. DirectX is rewritten often (with new versions) to accommodate new ideas, whereas OpenGL new features/ideas are just "tacked" onto the existing code base.
OpenGL also has a huge barrier to entry compared to DirectX.
MSND DirectX resources are fantastic, whereas resources on OpenGL are often out-dated and generally pretty crap.
DirectX requires the DirectX SDK, whereas OpenGL requires GLUT, or GLEW? I think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them? What? Exactly.
I wouldn't say OpenGL is ugly as hell. Modern OpenGL (using vertex buffers and such) isn't too bad. But politics, platform-compatibility and corporate hating aside, Direct3D is the better API.
OpenGL suffers from a lot of the same issues as HTML -- designed by a committee of mostly competitors. It should surprise no one that while systems that come out of such arrangements can be vital for the industry, they are very slow moving when compared to an SDK defined by a dictator (benevolent or otherwise) and much more hesitant to allow for the massive changes that new technology would otherwise allow.
I've heard this same sentiment from numerous programmers, including many who prefer Linux. I'm thinking this is probably an informed opinion, not an uninformed one, and should probably not be in the negative in votes.
Frankly, complaining that developing for Direct3D requires just the DirectX SDK, and that developing for OpenGL requires some combination of other libraries is a stupid complaint. It's the kind of complaint that only complete newbies might have - anyone with any idea about what they're doing will not have a problem with it.
Not that it's hard, anyway. You don't need any actual libraries to use OpenGL. You just need up-to-date headers, and a way to link to the system's OpenGL library. The easiest way to get those is to use an extension loading library, which provides those headers, links to OpenGL at run-time (same thing that Direct3D does) and makes all of the available extensions available automatically.
Complaining about libraries like GLUT, GLFW, or SDL is completely irrelevant. If you were using Direct3D, you'd be writing windowing code directly on top of the Win32 API, which you can still do with OpenGL. If you want to use one of these libraries to handle the platform-specific windowing and OpenGL setup, you can. You don't have to - even in portable games, you can still just write your own platform-specific windowing and OpenGL setup code.
So the development setup and libraries are different. So what? It's fairly simple to work out for anyone but a complete beginner. On platforms like iOS or Mac OS X, OpenGL is actually trivial - everything you need is included in the platform's SDK. Same with Android. Same, to an extent, with Linux. OpenGL is only really awkward on Windows, and you can guess who's to blame for that.
But there are plenty of legitimate complaints about OpenGL.
The API is much more complex than Direct3D. There are dozens of ways to do things, with no way to tell which is the best way (short of looking at what Direct3D is doing, and copying that). Behaviour and performance is inconsistent between driver vendors, versions of driver from the same vendor, and across platforms. Some OpenGL drivers (Intel's on Windows, until very recently) are effectively unusable, or don't expose all of the hardware's functionality that Direct3D does. There are lots of legacy issues to carefully creep around, and they can still bite you even if you're not using the legacy features. The shader compilers aren't consistent between different vendors, and are often incredibly slow. Linking shaders is kind of clumsy. Since the API and drivers are much more complex, it's more common to run into severe performance issues caused by the driver than it is with Direct3D (and consoles are better than Direct3D in this regard, because their graphics drivers are so thin that they essentially don't exist).
Even picking a decent subset of OpenGL to use is a pain. Do you use OpenGL 2.x and ignore large chunks of it to get a reasonable API, and broad support? Do you go for OpenGL 3.x or 4.x instead? Which version? Which set of extensions? It's dead easy for OpenGL ES, though - 1.x (fixed function) or 2.x (shaders), neither of which carry around the legacy crap that OpenGL still carries.
Dealing with all of that is the problem with using OpenGL, not working out how to link to it.
Oh, and documentation. That really is shocking, mostly because the majority of documentation or guidelines you might find are written for OpenGL 1.x, and are completely obsolete.
There are some good beginner-level guides to getting started with modern OpenGL:
Question, why don't people just use OpenGL ES on Windows/Mac/Linux as well then? It sounds like the right level of not-backwards compatable, yet available everywhere
This is why I chose to learn DirectX first rather than OpenGL.
It's kind of like the Android vs iOS debate. DirectX is like iOS in that there's one main feature set which runs on a lot of devices. Whereas OpenGL was pretty fragmented because of extensions.
The only fragmentation on DirectX that I remember is the vertex-texture fetch (which was only supported by NVIDIA cards) vs render to vertex buffer (only supported by ATI cards) features in DirectX 9.0c. After that, Microsoft really started emphasizing the notion of a standard feature set.
OpenGL moved away from all of that starting with OpenGL ES which is partly why it has became so popular.
Well -- after some significant time wrestling with OpenGL/DirectX under Windows -- I got totally fed up and moved to OS X with Objective C... Objective C syntax certainly takes some getting used to -- but the iTunesU developer videos and overall documentation seems much better and more cohesive than the MSDN stuff ever did.
I guess, however, it's always a balancing act... I mean -- I thought Microsoft was supporting C# as its primary language -- however, Managed DirectX (with examples and documentation) never seemed to arrive (in fact it seemed to disappear)... C++ +MFC has to be the worst development schema ever created (luckily I managed to skip that part of the development history by ducking to VC roles)... I think the only thing that is clear about MFC is that it is a M. F. C. and anything to get away from it including Interop and switching to OS X/Objective C (even if Objective C is replete with legacy C APIs etc.)...
Matter of opinion. I vastly, vastly prefer it to D3D and its unnecessary OO abstractions. The GPU is not "object oriented" and the OpenGL state machine is much closer to how the GPU works. It takes some time learning to understand the underlying philosophy, but if you stick with the core profile (3.2 or newer) and ignore the legacy profile, it will prove a really quite beautiful API to work with.
> DirectX is rewritten often (with new versions) to accommodate new ideas, whereas OpenGL new features/ideas are just "tacked" onto the existing code base
What's the problem here. New functions are added, but older ones are still valid use-cases. Seriously outdated stuff that no hardware no longer really natively supports, such as the fixed-function pipeline, is clearly and most obviously flagged everywhere as outdated legacy ("compatibility profile") API and its use discouraged. However, if you really wanna fire up an old OpenGL 1.1 app you wrote as a teen some 15 years ago, you still could. Now that's actually rather neat, isn't it?
> OpenGL also has a huge barrier to entry compared to DirectX.
Nope? Don't even need an SDK for that. It's pre-installed on all major OSes and implemented by all GPU drivers for years.
Even better is, there's no need for what in D3D results in a DirectX install on client machines. That annoys me actually, whenever I install a new game with Steam, it proceeds to "install DirectX" (sometimes v9, sometimes v10, sometimes v11). Sometimes even just when I start a readily installed game after a longer period of not playing it. WTF? DirectX has been "installed" so many times by now, isn't once enough? And can't DX11 automatically provide a DX9 layer for older games? I know that my GeForce-provided GL 4.2 driver happily implements "all GL versions ever".
> MSND DirectX resources are fantastic, whereas resources on OpenGL are often out-dated and generally pretty crap.
Khronos' GL/GLSL API documentation pages are all comprehensible, accurate, up-to-date and complete, and so are their spec PDFs if that's the preferred format. Their Wiki pages also provide a wealth of absolutely current high-quality information.
As for tutorials out there, some are good and up-to-date, some not -- same for D3D I'd wager?
> whereas OpenGL requires GLUT, or GLEW? I think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them? What? Exactly.
DirectX 10 and 11 are part of the OS and there are no standalone installers anymore. What Steam does is noticing that the game has a dependency on DirectX and it launches a stub installer but apparently cannot actually check whether it runs on a recent Windows version where that thing does essentially nothing. There is a DirectX-9-compatible layer in current DirectX.
I don't agree. SFML sounds at first like a really good idea, and at first usage seems pretty cool. But there are invisible walls and they're not hard to run into. The API reflects the developer's way of thinking and I find it somewhat odd (though, to be fair, I'm sure plenty of people would consider the API I've built for my own private library to be somewhat odd, too), and I noticed in my most recent experiments with the 2.x beta that you end up having to drop out of the friendly confines of the SFML libraries into the underlying implementations alarmingly often to do anything interesting.
There are also what I consider reliability issues. SFML 1.6 and 1.6 have reproducible startup issues on any semi-modern ATI/AMD graphics chipset I was able to test it on (2008 to 2010 vintage). The recommended solution from the developer was to upgrade to the API-incompatible 2.x alpha--which still isn't even released as a 2.0 today. It's open-source, and totally his choice whether or not to fix bugs like that (at the time I wasn't capable of doing it myself); I'm not saying "oh, he's not at my beck and call, he sucks," but I'd be very wary of going back there again and it did play a factor in me choosing not to use SFML for my current project.
OpenGL also has a huge barrier to entry compared to DirectX.
MSND DirectX resources are fantastic, whereas resources on OpenGL are often out-dated and generally pretty crap.
DirectX requires the DirectX SDK, whereas OpenGL requires GLUT, or GLEW? I think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them? What? Exactly.