Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is it that DirectX is easier or better than OpenGL, even if OpenGL is cross-platform? Why do we not see real powerful games for Linux like there are for Windows?

share
55  
False premise - where is evidence that game developers prefer windows? I think @user17674 had it more accurately - they want to develop for platforms so they can sell more and make more money:-) –  Rory Alsop Mar 22 '11 at 0:04
10  
I prefer directX, it seems more OO than GL.. –  Daniel Little Mar 22 '11 at 7:09
258  
Virus developers also prefer Windows. It's all about the user base. –  CesarGon Mar 22 '11 at 7:45
100  
Why do people rob banks? Because thats where the money is. –  GrandmasterB Jun 29 '11 at 19:27
7  
@CesarGon: It is not only because of the user base but also for the ease of development. –  Giorgio Aug 2 '12 at 17:15
show 8 more comments

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

locked by World Engineer Sep 9 '13 at 3:42

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

14 Answers

up vote 1158 down vote accepted

Many of the answers here are really, really good. But the OpenGL and Direct3D (D3D) issue should probably be addressed. And that requires... a history lesson.

And before we begin, I know far more about OpenGL than I do about Direct3D. I've never written a line of D3D code in my life, and I've written tutorials on OpenGL. So what I'm about to say isn't a question of bias. It is simply a matter of history.

Birth of Conflict

One day, sometime in the early 90's, Microsoft looked around. They saw the SNES and Sega Genesis being awesome, running lots of action games and such. And they saw DOS. Developers coded DOS games like console games: direct to the metal. Unlike consoles however, where a developer who made an SNES game knew what hardware the user would have, DOS developers had to write for multiple possible configurations. And this is rather harder than it sounds.

And Microsoft had a bigger problem: Windows. See, Windows wanted to own the hardware, unlike DOS which pretty much let developers do whatever. Owning the hardware is necessary in order to have cooperation between applications. Cooperation is exactly what game developers hate because it takes up precious hardware resources they could be using to be awesome.

In order to promote game development on Windows, Microsoft needed a uniform API that was low-level, ran on Windows without being slowed down by it, and most of all cross-hardware. A single API for all graphics, sound, and input hardware.

Thus, DirectX was born.

3D accelerators were born a few months later. And Microsoft ran into a spot of trouble. See, DirectDraw, the graphics component of DirectX, only dealt with 2D graphics: allocating graphics memory and doing bit-blits between different allocated sections of memory.

So Microsoft purchased a bit of middleware and fashioned it into Direct3D Version 3. It was universally reviled. And with good reason; looking at D3D v3 code is like staring into the Ark of the Covenant.

Old John Carmack at Id Software took one look at that trash and said, "Screw that!" and decided to write towards another API: OpenGL.

See, another part of the many-headed-beast that is Microsoft had been busy working with SGI on an OpenGL implementation for Windows. The idea here was to court developers of typical GL applications: workstation apps. CAD tools, modelling, that sort of thing. Games were the farthest thing on their mind. This was primarily a Windows NT thing, but Microsoft decided to add it to Win95 too.

As a way to entice workstation developers to Windows, Microsoft decided to try to bribe them with access to these newfangled 3D graphics cards. Microsoft implemented the Installable Client Driver protocol: a graphics card maker could override Microsoft's software OpenGL implementation with a hardware-based one. Code could automatically just use a hardware OpenGL implementation if one was available.

In the early days, consumer-level videocards did not have support for OpenGL though. That didn't stop Carmack from just porting Quake to OpenGL (GLQuake) on his SGI workstation. As we can read from the GLQuake readme:

Theoretically, glquake will run on any compliant OpenGL that supports the texture objects extensions, but unless it is very powerfull hardware that accelerates everything needed, the game play will not be acceptable. If it has to go through any software emulation paths, the performance will likely by well under one frame per second.

At this time (march ’97), the only standard opengl hardware that can play glquake reasonably is an intergraph realizm, which is a VERY expensive card. 3dlabs has been improving their performance significantly, but with the available drivers it still isn’t good enough to play. Some of the current 3dlabs drivers for glint and permedia boards can also crash NT when exiting from a full screen run, so I don’t recommend running glquake on 3dlabs hardware.

3dfx has provided an opengl32.dll that implements everything glquake needs, but it is not a full opengl implementation. Other opengl applications are very unlikely to work with it, so consider it basically a “glquake driver”.

This was the birth of the miniGL drivers. These evolved into full OpenGL implementations eventually, as hardware became powerful enough to implement most OpenGL functionality in hardware. nVidia was the first to offer a full OpenGL implementation. Many other vendors struggled, which is one reason why developers preferred Direct3D: they were compatible on a wider range of hardware. Eventually only nVidia and ATI (now AMD) remained, and both had a good OpenGL implementation.

OpenGL Ascendant

Thus the stage is set: Direct3D vs. OpenGL. It's really an amazing story, considering how bad D3D v3 was.

The OpenGL Architectural Review Board (ARB) is the organization responsible for maintaining OpenGL. They issue a number of extensions, maintain the extension repository, and create new versions of the API. The ARB is a committee made of many of the graphics industry players, as well as some OS makers. Apple and Microsoft have at various times been a member of the ARB.

3Dfx comes out with the Voodoo2. This is the first hardware that can do multitexturing, which is something that OpenGL couldn't do before. While 3Dfx was strongly against OpenGL, NVIDIA, makers of the next multitexturing graphics chip (the TNT1), loved it. So the ARB issued an extension: GL_ARB_multitexture, which would allow access to multitexturing.

Meanwhile, Direct3D v5 comes out. Now, D3D has become an actual API, rather than something a cat might vomit up. The problem? No multitexturing.

Oops.

Now, that one wouldn't hurt nearly as much as it should have, because people didn't use multitexturing much. Not directly. Multitexturing hurt performance quite a bit, and in many cases it wasn't worth it compared to multi-passing. And of course, game developers love to ensure that their games works on older hardware, which didn't have multitexturing, so many games shipped without it.

D3D was thus given a reprieve.

Time passes and NVIDIA deploys the GeForce 256 (not GeForce GT-250; the very first GeForce), pretty much ending competition in graphics cards for the next two years. The main selling point is the ability to do vertex transform and lighting (T&L) in hardware. Not only that, NVIDIA loved OpenGL so much that their T&L engine effectively was OpenGL. Almost literally; as I understand, some of their registers actually took OpenGL enumerators directly as values.

Direct3D v6 comes out. Multitexture at last but... no hardware T&L. OpenGL had always had a T&L pipeline, even though before the 256 it was implemented in software. So it was very easy for NVIDIA to just convert their software implementation to a hardware solution. It wouldn't be until D3D v7 until D3D finally had hardware T&L support.

Dawn of Shaders, Twilight of OpenGL

Then, GeForce 3 came out. And a lot of things happened at the same time.

Microsoft had decided that they weren't going to be late again. So instead of looking at what NVIDIA was doing and then copying it after the fact, they took the astonishing position of going to them and talking to them. And then they fell in love and had a little console together.

A messy divorce ensued later. But that's for another time.

What this meant for the PC was that GeForce 3 came out simultaneously with D3D v8. And it's not hard to see how GeForce 3 influenced D3D 8's shaders. The pixel shaders of Shader Model 1.0 were extremely specific to NVIDIA's hardware. There was no attempt made whatsoever at abstracting NVIDIA's hardware; SM 1.0 was just whatever the GeForce 3 did.

When ATI started to jump into the performance graphics card race with the Radeon 8500, there was a problem. The 8500's pixel processing pipeline was more powerful than NVIDIA's stuff. So Microsoft issued Shader Model 1.1, which basically was "Whatever the 8500 does."

That may sound like a failure on D3D's part. But failure and success are matters of degrees. And epic failure was happening in OpenGL-land.

NVIDIA loved OpenGL, so when GeForce 3 hit, they released a slew of OpenGL extensions. Proprietary OpenGL extensions: NVIDIA-only. Naturally, when the 8500 showed up, it couldn't use any of them.

See, at least in D3D 8 land, you could run your SM 1.0 shaders on ATI hardware. Sure, you had to write new shaders to take advantage of the 8500's coolness, but at least your code worked.

In order to have shaders of any kind on Radeon 8500 in OpenGL, ATI had to write a number of OpenGL extensions. Proprietary OpenGL extensions: ATI-only. So you needed an NVIDIA codepath and an ATI codepath, just to have shaders at all.

Now, you might ask, "Where was the OpenGL ARB, whose job it was to keep OpenGL current?" Where many committees often end up: off being stupid.

See, I mentioned ARB_multitexture above because it factors deeply into all of this. The ARB seemed (from an outsider's perspective) to want to avoid the idea of shaders altogether. They figured that if they slapped enough configurability onto the fixed-function pipeline, they could equal the ability of a shader pipeline.

So the ARB released extension after extension. Every extension with the words "texture_env" in it was yet another attempt to patch this aging design. Check the registry: between ARB and EXT extensions, there were eight of these extensions made. Many were promoted to OpenGL core versions.

Microsoft was a part of the ARB at this time; they left around the time D3D 9 hit. So it is entirely possible that they were working to sabotage OpenGL in some way. I personally doubt this theory for two reasons. One, they would have had to get help from other ARB members to do that, since each member only gets one vote. And most importantly two, the ARB didn't need Microsoft's help to screw things up. We'll see further evidence of that.

Eventually the ARB, likely under threat from both ATI and NVIDIA (both active members) eventually pulled their head out long enough to provide actual assembly-style shaders.

Want something even stupider?

Hardware T&L. Something OpenGL had first. Well, it's interesting. To get the maximum possible performance from hardware T&L, you need to store your vertex data on the GPU. After all, it's the GPU that actually wants to use your vertex data.

In D3D v7, Microsoft introduced the concept of Vertex Buffers. These are allocated swaths of GPU memory for storing vertex data.

Want to know when OpenGL got their equivalent of this? Oh, NVIDIA, being a lover of all things OpenGL (so long as they are proprietary NVIDIA extensions), released the vertex array range extension when the GeForce 256 first hit. But when did the ARB decide to provide similar functionality?

Two years later. This was after they approved vertex and fragment shaders (pixel in D3D language). That's how long it took the ARB to develop a cross-platform solution for storing vertex data in GPU memory. Again, something that hardware T&L needs to achieve maximum performance.

One Language to Ruin Them All

So, the OpenGL development environment was fractured for a time. No cross-hardware shaders, no cross-hardware GPU vertex storage, while D3D users enjoyed both. Could it get worse?

You... you could say that. Enter 3D Labs.

Who are they, you might ask? They are a defunct company whom I consider to be the true killers of OpenGL. Sure, the ARB's general ineptness made OpenGL vulnerable when it should have been owning D3D. But 3D Labs is perhaps the single biggest reason to my mind for OpenGL's current market state. What could they have possibly done to cause that?

They designed the OpenGL Shading Language.

See, 3D Labs was a dying company. Their expensive GPUs were being marginalized by NVIDIA's increasing pressure on the workstation market. And unlike NVIDIA, 3D Labs did not have any presence in the mainstream market; if NVIDIA won, they died.

Which they did.

So, in a bid to remain relevant in a world that didn't want their products, 3D Labs showed up to a Game Developer Conference wielding presentations for something they called "OpenGL 2.0". This would be a complete, from-scratch rewrite of the OpenGL API. And that makes sense; there was a lot of cruft in OpenGL's API at the time (note: that cruft still exists). Just look at how texture loading and binding work; it's semi-arcane.

Part of their proposal was a shading language. Naturally. However, unlike the current cross-platform ARB extensions, their shading language was "high-level" (C is high-level for a shading language. Yes, really).

Now, Microsoft was working on their own high-level shading language. Which they, in all of Microsoft's collective imagination, called... the High Level Shading Language (HLSL). But their was a fundamentally different approach to the languages.

The biggest issue with 3D Labs's shader language was that it was built-in. See, HLSL was a language Microsoft defined. They released a compiler for it, and it generated Shader Model 2.0 (or later shader models) assembly code, which you would feed into D3D. In the D3D v9 days, HLSL was never touched by D3D directly. It was a nice abstraction, but it was purely optional. And a developer always had the opportunity to go behind the compiler and tweak the output for maximum performance.

The 3D Labs language had none of that. You gave the driver the C-like language, and it produced a shader. End of story. Not an assembly shader, not something you feed something else. The actual OpenGL object representing a shader.

What this meant is that OpenGL users were open to the vagaries of developers who were just getting the hang of compiling assembly-like languages. Compiler bugs ran rampant in the newly christened OpenGL Shading Language (GLSL). What's worse, if you managed to get a shader to compile on multiple platforms correctly (no mean feat), you were still subjected to the optimizers of the day. Which were not as optimal as they could be.

While that was the biggest flaw in GLSL, it wasn't the only flaw. By far.

In D3D, and in the older assembly languages in OpenGL, you could mix and match vertex and fragment (pixel) shaders. So long as they communicated with the same interface, you could use any vertex shader with any compatible fragment shader. And there were even levels of incompatibility they could accept; a vertex shader could write an output that the fragment shader didn't read. And so forth.

GLSL didn't have any of that. Vertex and fragment shaders were fused together into what 3D Labs called a "program object". So if you wanted to share vertex and fragment programs, you had to build multiple program objects. And this caused the second biggest problem.

See, 3D Labs thought they were being clever. They based GLSL's compilation model on C/C++. You take a .c or .cpp and compile it into an object file. Then you take one or more object files and link them into a program. So that's how GLSL compiles: you compile your shader (vertex or fragment) into a shader object. Then you put those shader objects in a program object, and link them together to form your actual program.

While this did allow potential cool ideas like having "library" shaders that contained extra code that the main shaders could call, what it meant in practice was that shaders were compiled twice. Once in the compilation stage and once in the linking stage. NVIDIA's compiler in particular was known for basically running the compile twice. It didn't generate some kind of object code intermediary; it just compiled it once and threw away the answer, then compiled it again at link time.

So even if you want to link your vertex shader to two different fragment shaders, you have to do a lot more compiling than in D3D. Especially since the compiling of a C-like language was all done offline, not at the beginning of the program's execution.

There were other issues with GLSL. Perhaps it seems wrong to lay the blame on 3D Labs, since the ARB did eventually approve and incorporate the language (but nothing else of their "OpenGL 2.0" initiative). But it was their idea.

And here's the really sad part: 3D Labs was right (mostly). GLSL is not a vector-based shading language the way HLSL was at the time. This was because 3D Labs's hardware was scalar hardware (similar to modern NVIDIA hardware), but they were ultimately right in the direction many hardware makers went with their hardware.

They were right to go with a compile-online model for a "high-level" language. D3D even switched to that eventually.

The problem was that 3D Labs were right at the wrong time. And in trying to summon the future too early, in trying to be future-proof, they cast aside the present. It sounds similar to how OpenGL always had the possibility for T&L functionality. Except that OpenGL's T&L pipeline was still useful before hardware T&L, while GLSL was a liability before the world caught up to it.

GLSL is a good language now. But for the time? It was horrible. And OpenGL suffered for it.

Falling Towards Apotheosis

While I maintain that 3D Labs struck the fatal blow, it was the ARB itself who would drive the last nail in the coffin.

This is a story you may have heard of. 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. You could "learn" OpenGL with simple tutorials, but you didn't really learn the OpenGL API that gave you real performance and graphical power.

So the ARB decided to attempt another re-invention of OpenGL. This was similar to 3D Labs's "OpenGL 2.0", but better because the ARB was behind it. They called it "Longs Peak."

What is so bad about taking some time to improve the API? This was bad because Microsoft had left themselves vulnerable. See, this was at the time of the Vista switchover.

With Vista, Microsoft decided to institute some much-needed changes in display drivers. They forced drivers to submit to the OS for graphics memory virtualization and various other things.

While one can debate the merits of this or whether it was actually possible, the fact remains this: Microsoft deemed D3D 10 to be Vista (and above) only. Even if you had hardware that was capable of D3D 10, you couldn't run D3D 10 applications without also running Vista.

You might also remember that Vista... um, let's just say that it didn't work out well. So you had an underperforming OS, a new API that only ran on that OS, and a fresh generation of hardware that needed that API and OS to do anything more than be faster than the previous generation.

However, developers could access D3D 10-class features via OpenGL. Well, they could if the ARB hadn't been busy working on Longs Peak.

Basically, the ARB spent a good year and a half to two years worth of work to make the API better. By the time OpenGL 3.0 actually came out, Vista adoption was up, Win7 was around the corner to put Vista behind them, and most game developers didn't care about D3D-10 class features anyway. After all, D3D 10 hardware ran D3D 9 applications just fine. And with the rise of PC-to-console ports (or PC developers jumping ship to console development. Take your pick), developers didn't need D3D 10 class features.

Now, if developers had access to those features earlier via OpenGL on WinXP machines, then OpenGL development might have received a much-needed shot in the arm. But the ARB missed their opportunity. And do you want to know the worst part?

Despite spending two precious years attempting to rebuild the API from scratch... they still failed and just reverted back to the status quo (except for a deprecation mechanism).

So not only did the ARB miss a crucial window of opportunity, they didn't even get done the task that made them miss that chance. Pretty much epic fail all around.

And that's the tale of OpenGL vs. Direct3D. A tale of missed opportunities, gross stupidity, willful blindness, and simple foolishness.

share
24  
Did you have this written up somewhere, or did you write if off the top of your head? –  Kristofer Hoch Jun 29 '11 at 19:33
38  
@Kristofer: I don't know if you can call it "off the top of your head" for something that took an hour or so to compose, but I didn't have it written up somewhere. –  Nicol Bolas Jun 29 '11 at 19:45
18  
@F.Aquino: So you're willing to attribute this to the rendering system that FPS games use, rather than the engine itself? Even though CS is based on Half-Life 1, which is based on Quake? Sorry; not buying it. Granted, I don't buy the premise that new FPSs have no e-sport potential, even though there are plenty of e-sports tournaments centered around newer FPSs. They may not hold the same attraction that CS does to some players, but don't make the mistake of thinking that those players make up all of FPS e-sports. –  Nicol Bolas Jun 29 '11 at 21:36
165  
Wow. I don't even care about most of this stuff and it's still a great read! –  Peter Rowell Jun 29 '11 at 22:48
12  
Which they, in all of Microsoft's collective imagination, called... the High Level Shading Language (HLSL). LOLled for more than 6 minutes at this. –  ApprenticeHacker Jul 17 '12 at 4:58
show 35 more comments

So I've gone over all these answers, and as a game developer who has code on console games that have been on Walmart shelves, I have a very different answer.

Distribution.

See, if you want to be on a Nintendo console, you have to get Nintendo's permission, buy from Nintendo's factories, pay Nintendo's overheads, negotiate with Walmart, deal with warehousing, you need money up front to manufacture, to print boxes, to ship, to do all the insurance, et cetera.

If you want onto the XBox, sure there's XBLA, but you still need Microsoft's blessing, you have to wait your turn in line, it's tens of thousands of dollars just to release a patch, etc.

On iOS, you still need Apple's okay, and they can (and do) capriciously pull you.

On Steam, you still need Valve's permission or greenlight, and lots of money.

.

On Windows? You set up a website and a download button.

.

I'm not saying the other platforms aren't valuable. But there is so *much* horrible stuff going on when you're trying to develop a game, that to me, the promise of being able to just slap a binary on a site and focus on the work - at least to get started - really lowers a lot of potential failure barriers.

"We can do the XBLA port later, when things are stable" mentality.

And to a lesser extent sure this is fine for Linux too, and if seven customers is good, you can start there.

But Windows has three massive advantages: genuinely open development, genuinely open deployment, and a very large, very active customer base which is interested in quirky stuff.

It's hard to imagine where else I'd rather start.

share
add comment

Tools, tools, tools.

That's what it comes down to. Develop on Windows and you get access to some of the best development tools on the planet. Nothing comes even remotely close to Visual Studio's debugger, the DirectX Debug Runtimes are awesome, PIX is awesome, and comparable equivalents just don't exist on other platforms/APIs. Sure, there is some good stuff there; I'm not saying that the tools on other platforms are bad, but those that MS provide are just so far ahead of the pack (honourable exception: Valgrind) that it's not even funny.

Bottom line is that these tools help you. They help you get stuff done, they help you be productive, they help you focus on errors in your own code rather than wrestle with an API that never quite behaves as documented.

share
    
PIX is awesome. Debugging shaders by clicking a bothersome pixel and seeing what happened is great! –  Chris Pitman Nov 17 '12 at 15:54
add comment

The answer is obvious. The objective of writing a game is to make money. More end users run Windows, therefore there is a bigger market and you would expect to make more money from a Windows game than a Linux game. It's that simple.

If ever you ask yourself the question 'Why does someone do...', just remember that money makes the world go round.

share
1  
Yes but you can make a cross platform game and get more than just windows users ;) –  M.Sameer Nov 16 '12 at 11:39
    
Being cross-platform isn't everything. If the number of extra users you get is a relatively low percentage then you need to balance the extra development cost and ongoing support cost against what extra you're going to get in from them and make an informed decision based on actual hard data. There's no globally right or wrong answer to that one, but there is an answer that's right or wrong for each individual program, and what's right for one program may be wrong for another. –  Jimmy Shelter Dec 9 '12 at 16:04
add comment
  1. Inertia. If you've used Windows in the past then switching to something else is a hassle. If you're on Windows DirectX is easier and more likely to work well than OpenGL.
  2. Market share. The market share of Windows on the desktop is bigger than that of OS X which in turn is bigger than that of Linux. Money talks.
  3. Brand. DirectX is better known than things like SDL (which is the sort of thing you would need to replicate some of DirectX's features that go beyond OpenGL).
  4. Less confusion. Will the user's Linux only support up to OpenGL 1.4 or OpenGL 2+? Can you use an OpenGL 2.0 tutorial like An intro to modern OpenGL. Chapter 1: The Graphics Pipeline on your version Linux?

These days Linux is more of a curio when it comes to games development and most developers would be better off fiscally doing an OS X port version before a Linux version (see things like Steam). Even then the console market is worth more than these two platform combined for games...

If you wanted to mono platform DirectX is fine. If you want to be cross platform there's a strong chance you will have to go with OpenGL on at least some of the other platforms.

share
2  
The answer to question 4 is: 2+. Mesa3D supports up to OpenGL 2.1, which means that all graphics drivers for 3D hardware for X11 support at least OpenGL 2.1 since Mesa version 6.8. That covers all Linux distros released in the last couple years, and binary drivers that NVIDIA and AMD ship support 3.0 and up. This doesn't include users of the intel895, but they've been deprecated. –  greyfade Jun 29 '11 at 23:34
1  
I'm afraid this is not the case. Computers with i915/i945 (GMA 900/950) chipsets are (still) being sold and are not deprecated. Even on modern distributions from a few months ago (Ubuntu 11.04/Fedora 15) glxinfo will return an OpenGL version no higher than 1.4 (Mesa 7.11-devel). Such Intel hardware simply can't do later versions without software help so until softpipe is available by default, Linux on such cards will never do a higher version OpenGL. Targeting OpenGL 2.0 (or higher) will stop a program running on a wide range of Linux desktop systems... –  Anon Jul 19 '11 at 6:50
    
Even so, I fail to see the concern. Those same chipsets have limitations on Windows, so most graphics-heavy games would be out of the question anyway. –  greyfade Jul 19 '11 at 15:05
add comment

It's because there are more Windows users on the planet than Linux and Mac. The truth is that people make things for whichever has the biggest market.
The same goes with mobile phones: Android and iPhone have awesome games but Windows Mobile and Symbian don't...

share
24  
@Mahmoud Hossam: That's not true. Using OpenGL doesn't mean that your entire application will just magically work under a *nix environment, it means that graphics engine will (and even then it doesn't mean there aren't quirks on (for example) Windows that don't exist on Linux and vice versa). That's not the whole basket and there is definitely an appreciable cost of maintaining their code for multiple platforms. –  Ed S. Mar 21 '11 at 23:16
5  
@Mahmoud: Exactly. And if you're not going to bother porting to Linux/Mac OS anyway, then why not use the native library? DirectX is much better supported on Windows than OpenGL is. –  Dean Harding Mar 21 '11 at 23:20
10  
@Mahmoud: the whole premise of the question is "why do developers prefer Windows". Answer: because that's what gamers use. There's no point porting to Linux/Mac if it only makes up 2% of your market, and in that case, there's no point using OpenGL if you're not going to port anyway. –  Dean Harding Mar 22 '11 at 2:11
4  
@Mahmoud, its not the game developer's job to get people to switch to Linux. –  GrandmasterB Mar 22 '11 at 3:57
6  
@John 10+ million of World of Warcraft players would like to have a word with you. And this is just one game. –  Marcelo Jun 29 '11 at 19:38
show 13 more comments

A lot has to do with politics and control. In the late 90s, SGI and MS actually agreed to combine efforts:

http://en.wikipedia.org/wiki/Fahrenheit_graphics_API

SGI invested heavily in the project, MS did not. SGI needed MS more than MS needed SGI. The rest is history.

D3D and OpenGL are two very different APIs, it is up to the developer to choose which is right for your needs.

share
add comment

Simply because Linux failed horribly as a desktop system. As somebody pointed out earlier Linux is a mess for developers (different libraries, ui toolkits, etc)

Another problem is freetardism and the lack of support for proprietary software. Nvidia always provides fine (proprietary) drivers for Linux however Ubuntu and other distros are not shipping it. There is also no binary driver interface available for Linux as for Windows. (There is a text file called binaryApiNonsense.txt or something in the Kernel sources) Having said that only Nvidia hardware is properly supported under Linux. You can play most of ID softwares games using Nvidia hardware under Linux.

Next thing development tools. MSFT provides excellent C++ support and the Visual Studio debugger is better then gdb with regard to C++. Last but not least, further tools are missing such as Photoshop. Also .net allows you to quickly create gui tools. Many game studios code their tools for internal use using the .net framework.

I almost forgot: The graphics system is horribly, back in the days they just ported X11 over because it was the easiest thing which worked. They failed to properly design and implement a modern graphic system which OSx and Win have.

share
4  
Hmm? My intel and ati cards work fine in Linux... And whats wrong with X11? I always felt it was much better than the alternatives for other OS's (particularly Windows) because of its client-server architecture. –  alternative Jun 29 '11 at 20:25
    
No they don't type glxinfo and see weather it's fine or not! X11 is horrible broken just an example theinvisiblethings.blogspot.com/2010/08/… –  Nils Jun 29 '11 at 20:28
    
and if you read the last sentence, Linus himself implemented the kernel level patch - not an X11 patch. –  alternative Jun 29 '11 at 20:33
1  
I do not know much about graphics system (you may have a point) but saying that Linux failed as a desktop system is not true or at least not accurate. I moved from Windows to Linux and I feel much productive ever since. Linux's performance is and was superior to Windows in all machines I used. I also do not code C++ and I want to know where does Eclipse stand as a C++ IDE as compared to Visual Studio. –  M.Sameer Jun 29 '11 at 20:43
    
Put down the flamethrowers. I think the generally accepted opinion is that VS is the best IDE. However, Eclipse is still young and has way to go - we shall see. I simply love how easily everything is scriptable and pipeable in Linux, however! –  Vorac Aug 31 '12 at 13:31
show 3 more comments

Because Windows is backed by a huge organization, that more than a decade ago decided they want game development to happen on their platform.

This wasn't true for the Mac, and it isn't true now. Not even for iOS. Apple doesn't provide tools for iOS game development. But it's a huge market (there's more iPhones out there, than there was PCs in 1995) with relatively little competition, so people do it anyhow.

As for Linux, there's not even some sort of central institution, that could set any sort of priorities. The direction in which Linux is going, is more less determined by a bunch of very good, yet slightly unworldly programmers.

To create a PC game today, you need a lot of 2d/3d artists, game designers, scriptors, actors, testers and what not. As to the actual programming, you might simply use an actual game engine (CryEngine, Unreal Engine, Quake Engine, Source Engine). So you might be able to do the whole thing without any actual programmers.

Because of that, and because of the nature of businesses, programmers have little say in which platform is chosen. And typically, managers look for support, which is something Microsoft claims to offer, and to deal with things that are somehow seizable to their thought patters, which open source is not.

For that reason, most commercial end-user software development is done on windows.
I work for a company, that creates flash games, and is thus not bound to a particular platform. However, we all develop on windows, because most of the tools we use aren't available for Linux.

share
2  
"So you might be able to do the whole thing without any actual programmers." You forgot the sarcasm. –  Allon Guralnek Oct 13 '11 at 20:00
    
@AllonGuralnek: No sarcasm there. In classic game development of big games, programmers will create engines and means to provide content and behavior (through visual editors or actual scripting) and then game/level/mission designers will use those means. If you buy a working and sufficiently powerful engine, you can basically cut out step one. –  back2dos Oct 13 '11 at 20:09
2  
Do you have a specific example of a reasonably notable game that was created without writing a single line of code? –  Allon Guralnek Oct 13 '11 at 20:15
1  
@AllonGuralnek: I didn't say anybody would be creating games without code, but without programmers. You don't need to be a programmer to create an entirely game-changing mod. DotA is the most popular one I can think of off the top of my head. –  back2dos Oct 13 '11 at 21:21
1  
@AllonGuralnek: No. People who write code are people who write code. Level designer are required to have a certain understanding of scripting. Much programmers are often required to have a certain amount of management skills. It doesn't make the first one a programmer, nor the second one a manager. Also your assessment of DotA is wrong. Firstly it's entirely game-changing, turning an RTS into a new genre and secondly it is considered as a separate game by many eSports leagues including the ESWC –  back2dos Oct 13 '11 at 22:07
show 1 more comment

Ewwww, I don't. I use Linux almost exclusively. I dual-boot to Windows to make Windows builds, and use the Mac for the Mac builds, but that's it.

The trick is a cross-platform framework we've developed over the years. Our games are built on top of that, and behave identically in Linux/OpenGL, Mac/OpenGL, and Windows/Direct3D (and soon in iOS/OpenGL).

Admittedly my company doesn't do AAA titles, so it may not apply to these, but we do make top casual games (see website - CSI:NY, Murder She Wrote and the two upcoming 2011s are examples of titles using important licenses, The Lost Cases of Sherlock Holmes 1 and 2 were quite successful as well)

I wouldn't give up gedit+gcc+gdb+valgrind for anything else.

share
3  
gedit is underrated for programming –  Alexander Jul 7 '11 at 22:49
2  
@Alexander, underrated doesn't even begin to explain –  Visa is Racism Jan 28 '13 at 10:27
3  
Sorry, I did give up gedit in the end. I now use gvim and I'm much happier :) –  ggambett Jan 29 '13 at 10:17
add comment

I found it strange that everybody's focusing on user base, when the question is 'game developers', not 'game editors'.

For me, as a developer, Linux is a bloody mess. There are so many versions, desktop managers, UI kits, etc... If I don't want to distribute my work as open source, where the user can (try to) recompile so it fits his unique combination of packages, libraries and settings, it's a nightmare!

On the other hand, Microsoft is providing (most of the time) incredible backward compatibility and platform stability. It is possible to target whole range of machines with one closed-source installer, for instance computers running Windows XP, Vista and 7, 32 and 64 bits flavors, without proper DX or VC redistributables installed, etc...

One last thing, PLEASE EVERYBODY ON THE INTERNET STOP COMPARING OPENGL AND DIRECTX! Either compare Direct3D vs OpenGL or don't do this. DirectX provides input support, sound support, movie playing, etc etc that OpenGL doesn't.

share
40  
"For me, as a developer, Linux is a bloody mess." Indeed! I work in an environment with Fedora and Ubuntu. We have problems even between just those two. (I must add I'm a Linux fanboy.) –  David Poole Jun 29 '11 at 14:58
48  
@jv42: This seems a common misconception: Almost all of those versions and desktop managers and UI kits, etc. are pretty irrelevant to getting a game up and working. If your game (as shipped) depends on more than libGL, libX11, and libasound (or libopenal or libao or liboss), you're doing something wrong. –  greyfade Jun 29 '11 at 22:00
19  
@greyfade "If your game (as shipped) depends on more than libGL, libX11, and libasound (or libopenal or libao or liboss), you're doing something wrong." -- And then you link to libao-0.0.4alpha, and your user has libao-0.0.5beta and nothing works. –  quant_dev Jun 30 '11 at 8:34
17  
Packaging up a binary so that it runs on all Linux distributions isn't that hard. Heck, the Blender developers do it with each release. There's only the one (well two, 32 bit and 64 bit) Linux release package of Blender. –  datenwolf Jul 5 '11 at 15:44
8  
show 21 more comments

As some have already said, the most important part is the user-base. 95% of PC users use Windows. PC gamers use almost exclusively Windows. Even these who use Mac or Linux most often run Windows games through some virtualization or emulation (with very, very few exceptions).

But demographic is not everything. I wouldn't underestimate the part that Microsoft is doing to make the platform more attractive for game developers. Basically you get fully featured set of tools for free, most importantly XNA Game Studio. This allows not only development for Windows, but also for Xbox360. And with the latest edition even for WP7 phones. Obviously since it's Microsoft tool, it uses DirectX, not OpenGL.

share
3  
Note for any time-travelling readers: As of April 2014, XNA will be officially dead. The last release (4.0) was published in 2010 and won't be seeing a new version between now (2013) and it's sunset. –  Aren Feb 9 '13 at 2:11
1  
Another note to any time-traveling readers: Windows 8 (and up) development will no longer be free in the future. –  InkBlend Apr 1 '13 at 20:40
add comment

I think you should read more about the History of DirectX and This Article.

I think MS chose DX over openGL because they like to lock people into using their own OS.

share
4  
no, they created DX because OGL isn't optimised for Windows, can't be expanded quickly to take advantage of new hardware and operating system developments, doesn't incorporate sound, control input, etc. etc.. –  jwenting Mar 22 '11 at 7:44
2  
iow DX is specialised for Windows for performance reasons and to allow Microsoft to keep it that way and quickly incorporate new technology as it becomes available. OpenGL is stuck at the level of graphics hardware support that existed 5 years ago, maybe more, because it's a comittee effort. –  jwenting Mar 22 '11 at 7:46
1  
@jwenting I don't think performance was the only reason they didn't port it to other platforms, I mean, if they wanted to port it, at least they would've open-sourced it and left it to the community to implement it. –  Mahmoud Hossam Mar 22 '11 at 12:18
1  
they didn't open source C#, they submitted the language specification to standards bodies. Microsoft is a member of those standards bodies, and does such things all the time (they have large contributions to the html, javascript, and other standards for example). Open sourcing it would have meant releasing the source code for the compiler and libraries under something like the APL. –  jwenting Mar 23 '11 at 8:08
1  
@jwenting: For the record, there is an implementation of Direct3D 10 and 11 on Linux that targets the Gallium3D framework. (And it has nothing to do with Wine.) I would also disagree with your assertion that "OGL isn't optimised for Windows." That's an issue of hardware driver implementations, not a limitation of OpenGL. –  greyfade Jun 29 '11 at 23:30
show 6 more comments

Because Windows has over 90% market share, and Linux (since you specifically asked about Linux) has a reputation for having lots of users who don't like to pay for software. Whether or not that's true or how true it is is irrelevant; the perception is there and it influences people's decisions.

share
1  
If developers use OpenGL it will support both Windows and linux so it will be marketing advantage actually to attract Linux users who are willing to pay and are using Linux because they believe it's better. –  M.Sameer Mar 21 '11 at 22:56
9  
Even using OpenGL there are costs in developing and testing cross platform which the Linux market doesn't justify. Directx is also (sadly) a better platform for PC gaming at the moment than OpenGL - there are very few new games on PCs being built on OpenGL. –  Martin Beckett Mar 21 '11 at 23:10
25  
Cross platforming isn't as straightforward as "just code for OpenGL". –  System Down Mar 21 '11 at 23:11
13  
That's not true actually, that Linux users won't pay for software. The Humble Indie Bundle (a bundle of games you can get for any amount of money you wish to pay) has been done twice now and every time it showed Linux users paying more than Windows users for the bundle. –  Htbaa Mar 22 '11 at 8:36
9  
@Htbaa Of course they paid more, they were desperate, its probably the only games they get to play on their OS. –  Marcelo Jun 29 '11 at 13:59
show 1 more comment

protected by Yannis Rizos Feb 3 '13 at 0:36

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.