OpenGL because they have to make the same game for 3 different systems and some of them don´t realy support DirectX.
That's so unfortunate, because that also mean leaving all AMD/Intel graphics users behind, since currently nVidia is the only vendor who have first-class OpenGL support. Another OpenGL RTS engine, Spring, runs terrible on AMD cards, it's not even able to launch Zero-K match with ultra settings on HD7970, and on high setting it crashes all the time during a game. By the way, since more than 90% players use Windows anyway, I wonder if we can have native DirectX renderer for that platform.
And write a completely different API interface for DirectX, too much work if you ask me... I'm sure they'll test the game on AMD cards as well as Nvidia cards.
I do believe that Intel has pretty decent OpenGL support, considering that Intel is involved with OpenGL. It is also not OpenGL's fault, that AMD is lacking, it's mainly AMD who are terrible at writing drivers. (Well, in my experience, it tends to be both AMD and NVIDIA being terrible at drivers.) Maybe if they stopped worrying about useless benchmarking and actually got stuff working within their drivers, then we might have better support for OpenGL. Alternatively; Microsoft is pushing to have AMD, Intel and NVIDIA avoid decent OpenGL support, so game developers are forced to use DirectX. It certainly wouldn't be above Microsoft to be dicks like that. Where do you get this statistics from? If you are basing it on Statcounter and Netstat data of how many internet users uses which operating system, then I am afraid you are misreading the statistics. The statistics won't tell you how many of those users actually play games. But I doubt it is a majority or even 25%, as a lot of people who use computers these days, don't play games at all. Secondly, even if the statistics was limited to gamers, the statistics won't tell you whether their operating system at the time is their operating system of choice. They may just be dual booting into Windows to play a game, but would prefer to play it on Linux (like myself). But you know what they say; 83% of statistics are made up on the spot.
I never had any problems with Spring-Games, not on my radeon hd 3850/4850/7850. I also played a few other OpenGL games on them, with no problems whatsoever.
Besides: If Planetary Annihilation isn't going to be a complete failure (in terms of sales), then both AMD and Nvidia will be forced to patch their drivers for better OpenGL-support. Spring cant be used as a measurement in this case, neither is AMD aware of the problems (fanbase is far too small) nor is it necessarily AMDs fault that the game won't work. It's much more likely that the engine uses OpenGL not as the specification states, happens quite often that unexperienced developers make use of undefined behaviors which can not be replicated on other platforms.
Actually, this is utter nonsense. just because YOU have troubles running a product, doesn't mean the issue is automatically the drivers of your card's vendor. This is called "anecdotal evidence" and exists with all drivers, for all products., since the beginning of time. (Except Creative, they really DO suck) There is nothing wrong with OpenGL drivers written by AMD/ATI.
I do a good portion of my gaming on Linux, using an AMD videocard (proprietary drivers), which means all the games I'm playing are using OpenGL. All those games run just fine when compared to their Windows versions, despite the "issues" AMD has with its drivers. Also, Intel, Nvidea, and AMD are all part of Khronos, the group behind the development for OpenGL. They each have a stake invested in ensuring that their latest GPUs can handle the version of OpenGL they claim it can handle. (Plus any nonstandard OpenGL extensions that may be used to keep feature parity with DirectX, or to expose new GPU features.)
AMD OpenGL drivers are actually good, they are just not as much fool-proof as NVidia (which is some standard violation too, but not major one). And Nvidia OpenGL is just not as much fool-proof as DirectX. In most cases games don't work correctly on AMD's OpenGL due to bad shaders and other nasty stuff happening. In situation where NVidia driver will silently fix the problem, AMD driver will fault. In everything else, modern OpenGL and DirectX has almost function-to-function match (in low-api DirectX part). Open Source opengl implementation mesa3d even has proof-of-concept realization of DirectX 11 api over same drivers and infrastructure which are used by OpenGL. That is - it's just different function names, drivers are the same.
They had the "problem" that the OpenGL-port of their source engine is about 20-30% faster than the DirectX-version. Just kidding... They ran into several problems with AMDs and Nvidia OpenGL implementation, but both companies fixed their drivers within weeks. They also had to struggle with the performance of their engine when they made their first steps at porting it to OpenGL, but that was less due to OpenGL itself but improper use of overly expensive OpenGL methods when they tried to find the precise equivalent for each DX call. Once they used the OpenGL API as intended, they could beat the performance of their proven windows version of the source engine by 20% in only 2 months!
Once Valve got OpenGL working on Linux (because they discovered this when porting Source to Linux) it turned out to be quite a bit faster than Windows+DirectX. Being awesome and thorough, they discovered the fault wasn't HURR DURR WINDOWS IS SLOW. It turned out that OpenGL was slow, and that many of the changes they made to make Source work on Linux could be applied to Windows too. I think it's on the Valve blog.
Actually, you are not entirely correct. It was partly because HURR DURR WINDOWS IS SLOW, because while they managed to obtain 315 FPS on Linux with OpenGL, they only managed to obtain 303.4 FPS on Windows (with the same configuration). For comparison, DirectX only managed 270.6 FPS. They attribute this to the Linux kernel being A) faster and B) open. The latter allows them to A) see what a system call actually does (note: This also applies to OpenGL) and B) allows them to propose changes to it, if they have a better solution. The latter mostly applied to OpenGL rather than the Linux kernel. Source.
Ahh, yes. It appears I am a bit mistaken there. And yes, that was where I got my information from (actually a while ago now).