Why you should use OpenGL and not DirectX
blog.wolfire.com
blog.wolfire.com
API use was shifted in favor of DirectX
by Microsoft's two-pronged DirectX
campaign around the launch of XBox
360 and Windows Vista, including the
spread of FUD (fear, uncertainty and doubt)
about the future of OpenGL, and wild
exaggeration of the merits of DirectX.
By the time of OpenGL 2.1, OpenGL was
running into a problem. It had a lot of
legacy cruft. The API wasn't easy to
use anymore. There were 5 ways to do
things, and no idea which was the fastest.
By David Rosen on January 8th, 2010
Edit: I guess the point I'm making is, OpenGL runs on non-MS as well as MS platforms (perfectly/badly is another question), but DirectX is locked to Microsoft only. That is what makes it of little to no value for people like me who need to care about cross-platform products and support.
OpenGL seems like a no-brainer for future survival as MSFT platform dominance exhibits entropy.
The PS3 used a proprietary API based on OpenGL 1.0.
http://www.eurogamer.net/articles/digitalfoundry-how-the-cre...
On traditional PCs and Macs, Microsoft
still owns an overwhelming market share,
with 91.8 percent of all traffic coming
from Windows-based machines. Among non-
Microsoft operating systems, both OS X
and Linux have stalled since October
2011, hovering around 6.9 percent and
1.2 percent, respectively.
What game developer say to themselves,
It looks like in 10 years, Linux and OSX adoption will _probably_ approach 50% market share. Therefore, the best choice for my new game, which will be released in 3-4 years, is to choose OpenGL
I'm not a game developer, but I would bet they are interested in where the market will be in the medium term, and there is no indication Linux/OS X will suddenly dominate within that timeframe.
Not all of them unless you count using an OpenGL-to-DirectX wrapper library. "Cross platform" sometimes means writing all the platform specific code yourself.
We've got plenty of directx support for those too. What are they again? Surface? Windows phone? I think I know one guy who has one.
Edit: It looks like the authors snark isn't as obvious to others as it was to me. I'm all for cross platform development and doing whatever makes sense your company/brand in terms of development, all my side projects use tools that make them as portable as possible.
But... this is not very important anyway. There's no reason to have a "brand loyalty" flame war. Arguing and flaming about this on the internet is not productive. Let's just have a practical discussion about how to target multiple mobile platforms.
If I was serious about writing a cross-platform mobile game, I would use some middle-ware like Unity, Unreal Engine, Cocos (yes there is a version for Windows Phone), etc. This takes care of the underlying differences between OpenGL ES and Direct 3D, so the developer can focus on the game itself and not worry too much about the rendering engine or graphics API.
If I was writing some other app that used OpenGL ES, I could still make a port for Windows Phone / Windows RT by using a wrapper for the graphics-specific code. Such wrappers already exist, and it is not too terribly difficult to roll your own if you prefer.
A lot of times, when you see a big game that is available on iOS, Android, AND Windows Phone / RT, usually they have done this:
- Use middle-ware as discussed above already
AND / OR:
- Write the majority of the logic in C++ (all of these platforms have ways of utilizing C++ code), and use a graphics wrapper that isolates the rendering code, so you can work with OpenGL ES or Direct 3D interchangeably.
And yet, it was locked by SE mods as out of topic. While I love Stack Exchange and I'm thankful for the value it brought in so many ways, this policy of locking reasonable and valid questions is just upsetting.
It became so around the time GPUs started being programmed by shaders - prior to that era OpenGL was quite pleasant compared to DirectX, yet DirectX mostly overtook OpenGL
Yes, OpenGL is a great API if one cares about portability and FOSS.
Reality, the game industry cares about their IP and getting games released no matter what technology stack is used.
Many AAA studios don't even develop for all platforms, rather target a main one, leaving the port to subcontractors.
Back in the golden days of the arcades, many subcontractors were not even given source code. There are plenty of subcontractor stories about having to play through games while taking pictures or recording on tape.
When you have development processes like this in place, the gaming API doesn't matter that much.
AAAs are one thing and are mostly based on engine technology that has been in development for years. For them D3D vs. OpenGL is a non-issue that was solved a decade ago. Or they stick to being Windows only. And they have the budget to port (or hire a subcontractor to port) one way or another.
For indies, on the other hand, the most money these days is (probably, don't have any stats at hand) coming from Android and iOS, which both use OpenGL (ES). Using off the shelf game engines is a very popular option but a lot of developers roll their own tech.
OpenGL ES 2+ is more like DX10 and less like Open GL.
Not only do they abstract away API details, perhaps even provide an api independence layer but they actually make the 3d magic hapen. OpenGL/D3D have no notion of "3d", there are no models, cameras, scenes, etc.
> OpenGL ES 2+ is more like DX10 and less like Open GL.
Not really. OpenGL ES is still like OpenGL. It's a subset of full OpenGL and does not fix the inherent design issues with the API.
Feature-wise OpenGL ES 2 is like DX9 which is like OpenGL 2.1 sans the legacy crap. OpenGL 3 is comparable to D3D10 and OpenGL 4 to D3D11. OpenGL 2.x was the "big change" from the old fixed function pipeline to a programmable shader based pipeline, but nothing was removed or deprecated in order to provide an incremental porting path. OpenGL 3 actually deprecates some of the old features but does not change the API, only removes the old parts.
But the API is still a horrible mess with a global state and weird side effects, even if a lot of stuff was removed. For the programmer, D3D is a lot nicer than OpenGL in many ways and that is unfortunately not going to change for the foreseeable future.
OpenGL gets the job done but it's very uncomfortable to use.
*(disclosure: my employer, but I don't work in this area)
I'm sure you can find some examples of mobile successes that brought in big money for a small indie studio, but I'd be shocked if you could find even half as many as you can if you look at PC and console.
It's worth pointing out that desktop GL and mobile GL ES are pretty significantly different (extension support, API, compressed textures, etc), too.
I've been an independent developer for a year now, and having just launched our first game I can really echo that this is how we feel about the App Store too. You can rank in the "top 100 highest grossing games" for a multitude of countries and still make absolutely no money on a F2P game... we've been there. And various articles back up this "winner takes all" vibe [1].
[1] http://www.whiteboardmag.com/the-one-percent-winner-take-all...
Subcontracting to a porting house is just as common if not more common for indies. If your game is successful on one platform a porting studio will be willing to work for a revenue percentage as indies are much more willing to give away significant percentages. Furthermore publishers are fairly willing to front the money for porting if you have a fully working game already designed and playable no matter what platform it was initially developed for. Indie games rarely push the computation and memory boundaries so porting isn't particularly difficult.
The general case for Indie developers is develop for whatever you're most comfortable and worry about that other stuff once you actually have something worth worrying about. The cost of porting a game is pretty trivial if it's worth porting.
I hope Android & iOS are not eating up all the revenue. Some of my favorite indie games fall under Microsoft Studios. Those obviously don't run on Android, and I hope the developers are getting the marketshare they deserve (IMO)
ps. google me, i have considerable experience. that doesn't stop me from being wrong or making a mistake, but don't make such brash assumptions.
Myself, I don't have explicit game industry experience, but I do follow it since the mid-90's, having been a IGDA member, GDC Mag subscriber, paid my attendance to GDCE a few times and do know a few people in German studios.
If I work for the boring IT industry it is mainly for not wanting to deal with crunch time and rather enjoy enterprise benefits.
PSGL is a thing and is multiple times reference in a few Sony papers, but it a mix of OpenGL ES 1.0 with Cg and lacks the performance LibGCM offers.
Furthermore, when Sony asked if anyone cared about OpenGL ES 2.0, no seemed to care that much.
As far as I know the XBox PSGL was more of a proof of concept thingy than a proper API. Also a third hand quote.
The thing is that all those APIs follow an OpenGL like way of doing 3D graphics, but they are all different enough that you end up with multiple code paths.
iOS - OpenGL ES
Android - OpenGL ES
Mac - OpenGL
Linux - OpenGL
HTML5 - WebGL (based on OpenGL ES) - even in IE!
Emerging platforms like Tizen, Firefox OS - OpenGL ES/WebGL
DirectX is just for Windows and Windows Phone. Isn't it getting to the point where the bother of having to write a DirectX port might cause developers to skip the Windows platforms, or stick to OpenGL on Windows desktop? Windows isn't as overwhelmingly important as it used to be, and couldn't the fact that DirectX is different start to work against MS? Imagine if Blackberry came out with their own custom 3D API - wouldn't that only serve to hurt them?
OpenGL != OpenGL ES != WebGL, yes they are all based on the same concepts, but require separate code paths and different shader versions.
Whilst technically true, WebGL is designed to have API compatibility with OpenGL ES (2), which in turn is based off of OpenGL (2). OpenGL ES 3 and WebGL 2 are beginning to emerge and are based off of OpenGL 3. In my experience shaders that work with WebGL will also work with OpenGL ES 2 and OpenGL 2.1. Equivalent versions tend to use the same concepts. On the other hand, code written for desktop (v3+) won't work on mobile, because the desktop version is one version ahead of mobile (and I imagind that it will be for several more versions).
Back in the day that was true, but I don't think that's the case these days. Xbox is obviously DirectX. Wii was OpenGL, and I think Sony used OpenGL as well.
Wii had its own API too, though closer to OpenGL, still wasn't OpenGL.
I'm a huge fan of OpenGL, but evangelists have been spreading misinformation about OpenGL just as much as they accuse DirectX as.
Anyone that cares about graphics programming on game consoles knows how broken or non existent such support is.
Specially when enough information is actually publicly available for anyone that cares about game development, in online forums, games magazines, conferences and game courses.
As to why and where I gained this misinformation I don't know. But somewhere along the line I've gotten my wires crossed.
I don't know how much still holds for the XBox One, but for instance the XBox 360 version of DirectX is very different from the PC version: it's much closer to the metal and exposes pretty much all the GPU functionalities.
Here is a thread talking about XBox 360 dev: http://beyond3d.com/showthread.php?t=62049
With PhyreEngine being used as main prototype engine.
Lots of nice technical documents available at http://develop.scee.net/publications
PS4 API is called GNM, http://www.eurogamer.net/articles/digitalfoundry-how-the-cre...
OpenGL dominates casual platforms.
DirectX dominates "traditional gaming" platforms.
While they had OGL implementations, all of them basically require you to write against a low-level proprietary api to be competitive with other games on the platform.
Could you explain that? I've played some pretty great games on my iPhone/iPad over the last few years. There certainly are games that could stand up to the average PC release (remember BattleField 7 and Call of Duty 18 are not average). Many are at least easily comparable to games of the 16 bit era.
A sample from my purchased apps list: Battleheart, Beat Sneak Bandit, Brainsss, Device 6, Fieldrunners, Edge, Game Dev Story, Girls Like Robots, One Tap Hero, Punch Quest, The Room, Slayin, Spider, Spy Mouse, Star Command, Supermagical, Tiny Heroes, Tiny Thief, Waking Marks, and Zenbound.
This doesn't include 'tiny' games, ports, digital version of boardgames, etc.
WoW, Rift, Guild Wars, SC, competitive FPS's, Witcher style RPG's, Elder Scrolls, etc. these are not games you will be playing on a tablet. There exists a clear divide between casual and serious gamers.
I don't mean to imply that there's anything wrong or inherently inferior about the more casual side of things, just that they really are two very different markets.
Then there are the hardcore games. Eve Online, World of Warcraft, Call of Duty, Grand Theft Auto, Street Fighter 4, etc. These games often require lots of skill or dedication, and are often big budget titles.
But there is a ton of stuff in between. Games that you might be able to play fast but are very difficult (like Spelunky), that the player can choose how to play (Minecraft or Terraria), that just aren't designed to be highly competitive and difficult (Sly Cooper series, maybe Ratchet and Clank series), aren't hardcore ultra-deep sims (SimCity, Game Dev Story), and many sports games (Madden, NBA2k, etc).
Some people go really deep on some games and play them in a 'hardcore' way. The lines aren't easy as I know many people think World of Warcraft has been dumbed-down throughout the expansions to where it may not be 'hardcore' for many people.
But that's my general taxonomy. Casual, 'normal', hardcore.
I'd bet money that in two years time 2 out of the top 5 "real" games will be available on iOS and/or Android. (Not entirely sure how we are defining "real" games, though).
And I shouldn't have used the term "real". I'm talking about games like WoW. Many (many) buttons that need to be pressed quickly in response to your opponent (not talking about LFR obviously...).
So, essentially, your argument is that control schemes should be dumbed down so that they play on mobile? Yeah, that will go over well.
I'd note that it's pretty hard to do tilt-control on a PC...
And there are already plenty of actions games on iOS that work well (and need to be more responsive than WoW).
Anyway, iOS controller support means the touch screen isn't the only input device.
Thanks to android being open source people can take it and build ...stuff.. with it. I'm sure you have heard of it: http://en.wikipedia.org/wiki/Ouya
And while it's very low-end, there is still stuff like http://www.youtube.com/watch?v=ldwU96PGOyM which might not be a "real" game but it seems pretty close.
Now imagine the next generation of android consoles with OpenGL ES 3.0 and more powerful GPUs.
Today with tools like Unity3d, UDK, CryEngine, Shiva Engine, MonoGame etc, game developers are at a point where they can pretty much stop worrying about the OpenGL/DirectX layer beneath their engines. Those Engines have become so powerful and affordable that it hardly makes any sense to roll your own. In fact, imo you would need a very strong reason to build your own engine these days instead of focusing on your product.
Soon all of these will support WebGL/HTML5 as a target and even render most of the (still very basic) WebGL engines obsolete.
Now if you were in the business of creating your own tools or engine, you would need to support both of OpenGL and DirectX to be able to support all the major platforms anyway.
Yes and no.
If you want to be writing a typical 3d game like an FPS, and RTS or 3rd person platformer, you can and probably should use an off the shelf 3d engine and stay away from the lower level APIs, OpenGL and d3d.
However, if you want to do something more exotic, say processing your webcam input stream with your GPU, or write a space scale render of the solar system or do anything that diverges from the use cases you typically use 3d engines for, you might still be better off using D3D or OpenGL directly.
Then there are aspiring future game engine programmers and hobbyists who want to use OpenGL directly. It's arguably more interesting than paying for a 3d engine but it's more work of course.
So most people do not need to touch D3D and OpenGL, in the same way that most people do not need to write C. But some people must and some people want to.
Of course, if you want to be (or are) an engine programmer, go for it and get your feet wet using OpenGL/DirectX, but for the broad mass of game developers, these aren't issues anymore.
Playing with it directly can be fun yes, but it can also be frustrating if all you want is so much easier with a game engine.
I'm doing a combination of scientific and practical computing, and I'm currently in the middle of the choice of whether to use DirectX or OpenGL. Portability counts, but so does simplicity. It's a very relevant question.
Sure, Unity3d is very flexible and has given us some outstanding games. Like Kerbal Space Program, for example. KSP has quite a bit of modifications to make Unity3d work for them, they have had to do some black magic to make Unity3d work in space scale scenes on both, the physics and graphics departments.
When looking at dev talks given by the KSP team, it begs the question whether or not they would have been better off not using Unity at all and doing a specialized engine from scratch. There's no real answer to this question and Unity probably made their time to market shorter so they could actually ship and sell the game to keep the development alive. And then they went on later to rewrite a lot of the stuff they did early on.
But from a purely software engineering standpoint, they might have been better off not using an off the shelf 3d engine, because there are no space scale 3d engines available.
Again, for most people it makes sense to pick up an engine and go with it but there are use cases where it might pay off to invest the time and effort to build your own tech from scratch.
Anyways, client-server works fine.
Several times I tried expanding an existing modular 3D engine (OGRE) towards my goal of displaying a huge virtual universe of planets and stars. While I got it rendering 3D planets after some work (where I basically had to implement manual rendering code anyway, since the engine didn't support the odd use-case of spherical terrain), contorting it to support massive coordinate spaces, huge view ranges, dynamic loading/unloading etc. was just far too messy to even hope to attempt in that engine.
After several attempts to cleanly implement a space-scale engine as an extension of an existing engine, I started over from scratch using pure OpenGL (WebGL). And this time, I managed to keep the code reasonably tidy while supporting trillions of stars, planets etc. as I had originally planned [1].
Would I have been able to do the same thing in OGRE if I kept trying? Probably... but likely with far more ugly code, terrible hacks, bloated engine, and slower loading times.
To be fair, I'm not advocating always "rolling your own" 3D engine. It's usually a huge task, and using a pre-existing engine will in almost every case be the smarter choice. But with some people trying to argue "you can make it fit in [Unity/OGRE/etc]", I thought I'd provide at least one anecdotal counter-example.
1. Kosmos: A virtual 3D universe in your web browser (https://github.com/judnich/Kosmos)
Uh, most of those have their core runtime engine written in C++ and are probably not itching to port their CPU-side code to JavaScript.. Porting to WebGL is only trivial for the GLSL shaders, nothing else. If anything, these companies are waiting and holding out for either PNaCl/ASM.js/Emscripten to be able to generate fast fully-working web-compatible engine code.
And those engines aren't just loading 3D models and blit them to the screen, at least that's not their selling point. They have their occlusion culling system .. particle systems .. animations .. hardware audio .. fake wind simulation .. rudimentary pathfinding .. a reasonably fast terrain renderer .. some physics engine intimately integrated into the whole thing.
You wanna port all that to JS? Go right ahead!
Of course there will still be usecases for Three.js and the likes, for more lightweight WebGL integrations. But full blown HTML5 games will pretty soon be possible through these engines. Unity3D already had a pretty feature complete Flash export and i am very sure they are already working hard on a html5 target option.
It is already done. https://github.com/kripken/emscripten/wiki
The Emscripten based competition only have a few tech demos so far and the possible coming of PNaCl outside Chrome doesn't look that probable at this point.
You are using Unity 3D, so NO, it's not a problem of the past. You have multiplatform because Unity developers decided to go with OpenGL.
Even Microsoft supports WebGL (based OpenGL ES 2) in Internet Explorer 11.
Beside that the article doesn't mention that OpenGL 2 came late (and 1.x is way outdated). And to bootstrap OpenGL 2+ on Windows you still need a OpenGL 1.4 context to create an OpenGL 2+ context. So not so trivial at all :/
As the article is pre-smartphone era: the future for OpenGL/WebGL is very good now. You can run WebGL on every device/OS (beside Windows, OpenGL 2/3 but no ES driver).
I was reading the article and he mentions WinXP is half of all gamers.. I couldn't believe my eyes. These things should come with a disclaimer here like "really really old stuff, i just want to pick a few points from it which are this and this. ignore the rest".
This is a quantifiable lie. I have written cross platform rendering engines and worked with many, I can tell you right now that platform and vendor specific hacks for OpenGL are a necessary evil if you want your stuff to work properly.
If you are working in a cross platform environment you abstract away rendering then whether you are using DX or OpenGL (or anything else - RSX, or whatever...) is not really important.
The question I always wonder is why OpenGL isn't this... if I can make it so can anyone else, absolutely. Its not hard or especially time consuming and gives you the power of actually being cross platform.
This is a constantly improving situation though... for example I no longer need to tell a large number of Intel graphics cards that clockwise is infact counter-clockwise for face winding - because they are obsolete and the drivers have improved. There are still many problems of that nature though... you might not realise that the driver is processing your vertex shader on the CPU for instance which makes for a significantly different performance profile to similar hardware in that class...
OpenGL was kept on life support in the aughts by high-end 3D products which are often cross-platform (e.g. Maya), and Apple (which switched to OpenGL from QuickDraw 3D after the spectacular failure of the latter -- incidentally OpenGL being "open" was SGI's proactive defense against QuickDraw 3D), and then rebuilt the entire Mac UI architecture on top of it.
OpenGL ES and iPhone have completely revived OpenGL's fortunes -- there's nothing much to worry about now unless Android and iOS both fail in the marketplace.
(It's entertaining that the Stackexchange post linked elsewhere was written more-or-less as a final "this is why OpenGL died" -- it's not dead yet... getting better...)
Usually people don't "bash" DirectX or D3D. Most OpenGL programmers acknowledge that it is a better API with more corporate backing (ie. budget). But at the same time it is still Windows only, and for a lot of people it simply isn't an option.
For OpenGL, the tooling is provided by individual vendors, and yes, it's not as good as d3d. But the situation has improved in the past few years and keeps on improving.
Even NVidia only started to invest in OpenGL performance measuring tools, after their Android support started.
Yes, there probably aren't tools that are as good as the D3D tools. But Nvidia, AMD and Intel have all released OpenGL profiling and debugging tools. Yes, every vendor has their own tools. Not ideal.
Fantastic book. C++ but you can use SharpDX for your C# development, which complies reasonably closely with the standard DirectX APIs. There are numerous websites/articles only a Google search away to fill in any gaps if/when you get stuck. This is the approach I've been taking. http://nathanridley.com if you're interested.
My old OpenGL vs Direct3D post is #1 on hacker news! https://news.ycombinator.com/item?id=6852961 Maybe time for a 2013 update -- a lot has changed since then.
1. D3D 11.1+ only supports Windows 8, which only 20% of Steam users have. OpenGL 4.4 works on all versions of Windows.
2. NVIDIA and ATI both now have good profiling and debugging tools for OpenGL that were formerly only available for DirectX
3. OpenGL Core is now lean and mean, making it easier for hardware vendors to create efficient and correct drivers.
4. Valve now strongly supports OpenGL with their own games and with SteamOS -- helps ensure the future of OpenGL itself, and vendor support.
5. Humble Indie Bundle creates an extra commercial incentive for indies to support Mac and Linux, which is much easier if you use OpenGL.
6. All the old points still stand -- OpenGL works on Mac, Windows, Linux, Web, iOS and Android. Direct3D only works on Windows and XBox.
I think developers may be driven away from using OpenGL at least partially based on worry about driver support. Using Windows this is a non-issue if you stay within DX10 and Windows 7/8. According to Steam Survey, this accounts for 81.61% of users. This drops down to 56.2% for DX11.
In short, until vendor OpenGL driver support is a given, many developers will stick with Windows and Direct3D.
Another note, this one on cross platform compatibility - the limitations of OpenGL ES2.0 are problematic for anything beyond rudimentary shaders. The primary limitation right now in my mind is a shortage of uniform vectors, and the wide variance in size for different android hardware. For instance, a smooth skinning (matrix pallet) shader for skeleton-based deformation will be limited to 5 or 6 joints per mesh on most android/OpenGL ES devices, whereas most x86/OpenGL systems allow for hundreds of joints. Similar limitations apply to pixel shaders as well - post processing such as blur, bloom, dof, and SSAO are not feasible on current generations of android devices for production use.
Of course android device GPUs are getting much more powerful with each iteration, and eventually will provide a good hardware base for advanced graphics engines.
For now, though, the idea of porting a full OpenGL graphics engine with advanced shaders to OpenGL ES2.0 is pretty much a re-write of the engine. This, combined with limited CPU and memory performance, is the primary reason we don't see AAA titles showing up on Android devices yet.
A lot is coming down the pipe in terms of hardware advances, though - I'm excited to see OpenGL support grow in parallel.
And seriously, the GNMX API (a high level wrapper of GNM) of PS4 has more similarity to DirectX than OpenGL.
This is good for all of us consumers, as the lock in inherent to the technology choices made my game devs will be diminished. I can only see that as a good thing.
And besides, middleware is getting so good, how many of us really need to hack on an engine anyway. My games logic is done in Lua, not C/OpenGL :)
Buying the alpha means paying for continuous development...
Also, you get a new download of the current state every time they have some significant changes.
If you ask me, these guys should have realized the opportunity and work more on Receiver at the time since it had the traction and enough sales to show up on Steam store charts. But there will always be guys who will insist on working their Magnum Opus, and consequentially, there will be vaporware.
This problem does not exist anymore.
They used to be pushing Silverlight as a way to do 3D rendering (which made sense, because it had the DirectX bindings from XNA and .NET is a superior platform for rendering code when compared with JavaScript) but now that Silverlight and basically every other native plugin is on the way out, there's no way they can lean on that anymore.
What I think you mean is letting the browser run scripts in the Windows Scripting Host, which gives you unlimited access to the filesystem, etc.
You'd think once they went to the expense of porting to OpenGL, they'd re-use that code on Windows? Or is it because they get better performance with DirectX on Windows?
Many cheap computers have GPUs with shitty or non-existent OpenGL drivers.
DirectX was born out of necessity, not proprietary greed.
Edit: Maybe its time to take another look at OpenGL - open is better than closed, especially for the multi-platform aspect. But does it have the same features as DirecX? Tesselation, shader programming, etc.
Of course it does. Even OpenGL ES 2.0 and WebGL (based on the same API as ES 2.0) do as well.
The fixed function pipeline of old has been deprecated in recent versions, so you don't have a choice but to use GLSL.
http://www.opengl.org/wiki_132/images/RenderingPipeline.png (blue = programmable)
[1] - http://www.gamasutra.com/blogs/DavidRosen/20100108/86330/Why...
Perhaps they're getting the point?
These vehement kinds of slashdotty style articles about MS's being this controlling conspiracy...you would almost think that...gasp...its a large corporation doing everything it can to make money for its shareholders. I mean, if the roles were somehow different and Apple were the market leader for the most popular gaming platform they would be all sweetness and light and no one would have any reason to complain. (Oh wait...)
It turns out that businesses in that position tend to make "lock in" plays. This post kind of glosses over SGI's history with OpenGL as if they were only ever kind and loving shepherds of an open standard that was created to help children.
Don't use directx cuz "evil" is stupid. If you were writing an application that needed to be cross platform...like a 3D authoring environment...you would probably want to look at opengl. (instead of writing your own...) If you were targeting the windows ecosystem directx has some platform integration features that are interesting. Tooling and developer experience also matter.
This kind of breathless nonsense is boring and silly.