Why you should do OpenGL and not DirectX | Hacker News Reader

Why you should do OpenGL and not DirectX

blog.wolfire.com

192 pointszitterbewegung42 comments

This is sort of a loaded article, since it glances over the benefits of DirectX. (Note: I'm an OpenGL developer, but I worked on implementing D3D10 on top of OpenGL, and I've worked with DX7+ over the years. I'm not a fan, but leaving these things out is misleading.)

First and foremost, it's wrong to compare OpenGL and DirectX, rather than OpenGL and Direct3D. OpenGL directly competes with a small portion of Direct3D, and requires several libraries (I'm a big fan of SDL, OpenAL, etc myself) to begin to touch the breadth of DX.

Second, with OpenGL you have many vendors producing extensions and implementing them at different times. With Direct3D, you have a single set of features you write for which are guaranteed to be there (in a given version). This means that when you write code for OpenGL, you have to special-case paths for many different available extensions and duplicate many pieces of functionality.

If you want to use shaders, you have to either make your own effects system on top of GLSL/ARB shaders or use something like Cg. The Direct3D effects pipeline saves a lot of time, but of course reduces flexibility.

In the end, the call on OGL vs DX really comes down to these things: How much do you care about cross-platform compatibility? How much time do you have to put into your engine? Do you want complete flexibility w.r.t. your rendering pipeline?

If you're an engine-tech-heavy firm, OpenGL will almost always be the right choice. If you're just making a game, DirectX will almost definitely save you time. Again, I'm not a DX fan, but it has its place, and this sort of article is woefully misleading.

OpenGL only competing against a portion of DirectX can be seen as a plus or a minus. I like the fact that OpenGL focuses on one thing and tries to "do one thing and do it well."

As do I, but it certainly increases the cost of development on a production engine. Personally, I like that; it gives me about as low-level control as possible, which is great, but it's certainly not for everyone.

DirectX is an umbrella brand. Direct3D is the equivalent of OpenGL. Most of the Direct3D developers don't even bother to checkout the source code for the other DirectX components.

Is opengl always harder? Aren't there any libs/projects that makes it way easier?

I don't think OpenGL is harder. For many tasks, OGL is just downright simple, especially when using SDL. But if you're producing a production engine, there's a lot of added complexity.

If you're interested in OGL development, I strongly suggest NeHe's guides ( http://nehe.gamedev.net/ ). Of course, the Red Book is also indispensable.

NeHe's guides are pretty well recognized now to be damaging to beginners. The code is sloppy and encourages copy-pasta coding by failing to properly explain the purpose of the code it provides. I really have to recommend against the NeHe guides.

If read in order (at least the first dozen or so), the NeHe guides do explain the purpose of each line of code with reasonable clarity. A decent programmer who is a beginner at OpenGL can use the NeHe guides to get started. I'd agree, though, that a novice programmer should have some additional guidance if using NeHe to learn C programming and OpenGL.

The NeHe guides get you up and going quickly and provide a base for easy experimentation. That alone makes them hugely useful, I believe. The code is horrendous and there's often a lack of explanation, but it's very easy to take the code and play around with it. They're certainly not the thing to read if you're looking for best practices, but they give you the ability to hit the ground running.

Aren't NeHe's tutorials very outdated? They seem to focus on use of the fixed function pipeline, which is deprecated in OpenGL 3.

"If you're just making a game"

…for Microsoft's platforms. This article[1] tend to prove that the extra time you spend with OpenGL can be a worthy investment, even if you are "just making a game". (I know you didn't say otherwise, but you sounded like you thought otherwise.)

[1]: http://blog.wolfire.com/2008/12/why-you-should-support-mac-o...

No, I certainly agree that cross-platform compatibility is important (the D3D10 implementation I mentioned in my post was for WinXP, OS X, and Linux, and spawned from a reimplementation of Win32 on OS X/Linux), but this has to be weighed against the costs.

Going with OpenGL, SDL, OpenAL, etc is certainly not the easy route, even with the huge benefits, and for small dev houses it can easily become overwhelming. If your code needs to be cross platform, then OpenGL (or both, but that again is more expensive) is the only way to go. If cross-platform compatibility would simply be icing on the cake, then you need to weigh the development costs of both approaches.

If you're just making games, you should just use one of the many free, cross-platform rendering engines (OGRE3D, Irrlicht, etc.) or a comprehensive game-maker (Unity or UDK). Both of these options abstract away OpenGL, Direct3D, shader implementations, extensions, etc.

I have wasted a pretty huge amount of my life writing engine code when I don't much care for engine problems and know someone else will be able to write something that performs better and has a good-enough API.

Don't read.

This article is simply a manifesto calling for developers to use OpenGL. The mindset of the author is firmly locked in the late-1990s, which was the height of the OpenGL vs. DirectX flamewars. I'm amazed that he didn't bring up Fahrenheit. (http://en.wikipedia.org/wiki/Fahrenheit_graphics_API)

The accusations about Direct3D gaining dominance because of FUD or some other nefarious actions are pretty ridiculous. Graphics APIs evolved rapidly during the period between 1998-2005, and there were times when Direct3D had a clear technology lead in certain areas. I've never met a single graphics developer who switched away from OpenGL for any reason other than preferring to work with D3D.

However, the balance has stabilized in recent years, and the author of this article doesn't tell us anything useful about current technology.

The rest of the article aside, I think that avoiding MS lock-in is a great reason to use OpenGL over Direct3D.

Lock-in is definitely a big concern, but the article vastly overstates the cross-platform benefits of OpenGL. Different platforms have different capabilities and limitations, and most of the work in creating high-performance 3D software involves optimizing for specific hardware.

For example, porting an OpenGL-based game from Windows to the PS3 would not be significantly easier than porting a D3D-based X-Box game.

FWIW: SCEA provide an implementation of OpenGL for PS3 so it should be 'easier'. I've heard it's not that fast given the strange nature of the PS3 hardware pipeline but it might be fast enough.

In gaming, lock-in is an inherent problem. You always need to optimize for specific platforms and hardware to stay competitive, so you might as well optimize for specific APIs as well. Most "ports" of games also include significant renderer rewrites. And with every non-desktop platform, you are really targeting OpenGL ES, not full OpenGL. ES is more of an API starter-kit, so it varies significantly between platforms.

Ignore the article. I'm an OpenGL developer but I would dearly love to use Direct3D instead - Direct3D has a very nice API and is well supported on all graphics cards, while OpenGL is a mess of extensions and only works well on Nvidia GPUs (and maybe ATI). The only reason we use OpenGL is for independence from Windows.

I wrote a big comment about OpenGL vs Direct3D with a bit of a historical as well as future looking perspective here: http://news.ycombinator.com/item?id=593801

In summary, OpenGL is an abstraction of 3D concepts with many vendor-specific extensions to enable performance. Direct3D is an abstraction of the most common implementation of real world 3D hardware. Game developers did, and continue to, unambiguously ask Microsoft to produce the latter.

I understand the graphics pipeline pretty deeply if anyone needs some clarification.

Having used both and worked at companies that make 3d engines as their main product, I've seen that one good way to approach this problem is to simply abstract away the API into a common interface that can be swapped between.

At a high level, the concepts that both APIs provide arent that unsimilar and abstraction is possible even if you are using some of the more esoteric features of each.

I was hoping for a good comparison of the two, and instead got a typical fanboy rant. There are a few good points, too bad they are buried.

I rather see it as an attempt at a manifesto, a call to action, to point out the risks of blindly following MS too closely.

The danger here, though, is in writing a blatantly misleading article clearly targeting those developers that would be better suited by DirectX, generally. Developers doing the sort of complex work that OpenGL is particularly well suited for (tech-heavy engine development, wherein total control is useful) tend to know that they need OpenGL. Developers just looking to write a game would often be better served by using DirectX, and leaving out the (very real) benefits of DirectX/3D is just downright misleading.

Can anyone comment on how Open GL ES plays into this? It seems to be the defacto standard for SmartPhones and that market is going to continue to grow rapidly. Is that going to influence OGL's adoption elsewhere? Or are there other factors that make that irrelevant?

I doubt portable games would affect OpenGL's use on the desktop directly. Games on the major consoles are typically not ported to portables and vice versa, so the two markets will remain segregated. And while console games are frequently ported to PC, portable games are not -- although perhaps this will change with the adoption of WebGL mentioned in the article. In any case, portable games will not directly help the performance, stability, or feature-richness of desktop OpenGL drivers in the way that console games help desktop Direct3D drivers.

That said, one way that portable games could contribute to the general advancement of OpenGL is by being the first platform that new programmers learn. A typical console game requires significant coding experience and artistic assets to compete, while the expectations (and costs) for a portable or web game are much lower, making such a game a more appealing target for a beginning programmer. And perhaps those programmers will continue to use OpenGL when they go on to make desktop games.

I was under the impression that DirectX was a more extensive API, and included support for more complex high level operations- is this untrue?

Yes, the article says this is untrue. It specifically mentions features that OpenGL has had years before DirectX.

Well, no, the article points out a few specific cases where it's untrue, but there are a few things that need to be pointed out here. Extensions like tessellation aren't guaranteed to be there, and if they aren't you have to implement this yourself. It also ignores the shader/effect pipeline, which you effectively have to build yourself in OpenGL, unless you use Cg. As I noted in my first comment here, these are strengths of OpenGL in some cases, but are big negatives in others.

"and if they aren't you have to implement this yourself."

Either that or offer a slightly degraded gaming experience according to what the OpenGL system exposes.

Nobody cares that much if their phone can't show the same tessellation glory their kid's dual-GPU oil-cooled deskside monster can.

Tesselation is a hardware feature. It's not an API extension. It's not "guaranteed to be there" ever. Any app that wants to use it needs to test for its presence. How are the D3D and OpenGL mechanisms not completely isomorphic?

And OpenGL has had a standard shader language since v2.0, about 6-7 years ago? You don't have to "build it yourself" except in the sense of having to port DX shaders to a slightly different source language.

"DirectX" is an umbrella term that covers a lot of low level APIs. OpenGL is just a 3D graphics layer (good one) while DirectX does many things including 2D, IO and sound. Now it seems as if the author is only comparing OpenGL to Direct3D, but he doesn't make that clear.

Minor correction: OpenGL actually works great for 2D as well. There are versions of all the API functions that accept vertices with 2 dimensions instead of 3. And you can quite easily make vertex buffer objects with only 2 dimensions.

You have the ortho modes and all that, but that's not really 2d drawing. Doing things like concave shapes with specific line drawing (especially if you want decent anti-aliasing) is complex and expensive, since OpenGL isn't particularly well suited for it.

Of course, on the DirectX side you have the DirectDraw vs Direct2D mess, not to mention that the APIs are very poorly designed (in my opinion, at least). Doing 2D stuff in OpenGL isn't terrible, but it's certainly not well suited to it. In most cases, something like SDL ends up being easier and rarely too much slower (well, unless you're scaling/rotating...).

It's true that OpenGL doesn't have built-in support for things like concave shapes, but you can always do tessellation and feed GL triangles. (Some tessellation options were mentioned in the article.)

I've found that for my particular uses, the hardware acceleration you get with GL makes it worth it for 2D, even if it's perhaps not otherwise as well-suited for that as SDL.

You know, this makes me think. Are there any good 2D libraries for OpenGL? I've seen a few, but they all seemed very special-purpose or were either poorly designed or just didn't work. It'd be interesting to have a nice library like SDL, but sitting on top of real hardware acceleration.

Just wait for SDL 1.3 to mature. From the wikipedia article: "SDL 1.3 is a major update to the SDL 1.2 codebase. It replaces several parts of the 1.2 API with more general support for multiple input and output options. Some feature additions include multiple window support, multiple input device support (many mice, many keyboards, etc.), hardware-accelerated 2D graphics, and better Unicode support."

Cocos2d is a 2d library that sits on top of OpenGL ES for the iPhone, it's rather nice.

Cairo comes to mind. It has an OpenGL backend that works very well.

Qt also has a GL drawing engine, which turned out to be a good move on Trolltech's part.

DirectDraw/Direct2D has been deprecated long time ago in favor of Direct3D. So basically you are in the same position as with OpenGL.

No, that's not true. DirectDraw was deprecated with no replacement, then Direct2D was created for Windows 7/Win2k8R2.

DirectX has a lot of sub sections - DirectShow for media playback, DirectSound for audio stuff and so on. For graphics, there is Direct3D and some other stuff I know too little about.

Reply on news.ycombinator.com