Yet another opengl vs direct3D thread

Pages: 12
Hello,

I want to learn a graphics API but i'm torn between OpenGL and Direct3D.
I know this has been discussed extensively on the internet but I can't seem to find a good one from past 2010. With a view on the future: Which API and why?
OpenGL when you:
A) Plan on deploying on other platforms than Windows (or want to use an API that isn't based of 10 year old technology on Windows XP)
B) Simply don't like Microsofts naming conventions.

Other than that, it doesn't really matter. There's no significant performance difference between the two beyond varying quality of driver implementations.
DirectX is primarily a game programming library. It's superior to OpenGL in advanced projects because of how many extra game-related features it provides, but if it's not a (graphically complex) game, then use OpenGL.
DirectX is also only available on Windows, while OpenGL is supported by virtually every system with drivers.
@NGen
I'm pretty sure the Source engine (Valve's game engine) has an OpenGL backend. It looks just fine while rendering relatively complex scenes.

-Albatross
Last edited on
I also would like to question NGen's comment.

What are some "extra game-related features" D3D offers that OpenGL does not?
It might be important to note that he referred to DirectX, not Direct3D. This isn't a fair comparison since OpenGL is a low-level graphics library while DirectX is an amalgamation of graphics, sound, etc. APIs. OpenGL is more comparable with Direct3D than DirectX as a whole. If you want to compare open source libraries with DirectX, you need to include OpenGL, GLU, GLEW, OpenAL, etc. or it isn't a fair comparison. It's not so much comparing apples and oranges as apples and fruit salad.
How many of the DirectX libraries other than D3D are still actively being used? I thought they were mostly abandoned.
I don't know about that, I've never used DirectX. I just wanted to point out the fallacy in comparing a component of a game programming library with an entire game programming library.
closed account (S6k9GNh0)
There is practically nothing you can do in DirectX you can't do in OpenGL, while still having an API that's open to virtually any system that has an implemented driver.

I dunno, pretty hands down for me.
Last edited on
The only real reason I see to use DirectX over OpenGL is if you're planning on entering the game industry - most PC games are Direct3D based (not all, but definitely the majority) - mostly due to clever marketing of microsoft in the early to mid 2000's, and the subsequent lack of people who actually knew anything other than D3D.
closed account (S6k9GNh0)
I seem to truly fail to see how that provides an advantage towards using DirectX over OpenGL. Why does entering the game market mean it's advantageous to use DirectX?
Last edited on
It's not an advantage, but likely a requirement if you're going to work on existing projects (and new ones too - as I said, the majority is used to using Direct3D).
@computerquip,
If technology X is used by the vast majority of the industry but you only know how to use technology Y, you're at a disadvantage.
Chrisname was right, I'll continue to only speak in the context of Direct3D, instead of DirectX as a whole.

The Geometry Pipeline is a major feature that was added to D3D10, which enables generation (not just transformation) of vertex data on the fly. In concept, you can generate an entire scene on the graphics card without having to store anything in RAM (except the most basic of DirectX interfaces and utilities, of course.)

Multi-threaded rendering (... sort of, look here: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476892(v=vs.85).aspx) is advantageous for complex scenes due to the overhead of immediate, blocking state changes that would otherwise have to be endured.

I'm pretty sure the Source engine (Valve's game engine) has an OpenGL backend. It looks just fine while rendering relatively complex scenes.

The first things that come to mind are Portal 2 and Left 4 Dead, which aren't too complex compared to many of the other AAA games that I've seen.

An additional benefit of using Direct3D over OpenGL is that you can be sure that features are available, since iterations of Direct3D aren't released as frequently as OpenGL. In a personal project, we have to determine which API we're able to use at runtime, which is a hassle when you can't use GLEW (it messes up our project configuration, unfortunately.) With DirectX, you can be guaranteed that you'll be using a given API because you have to explicitly state which version you're using.

But I'm not saying that Direct3D is better. OpenGL's API is MUCH simpler, requires less pointless (at least, in the applications I've written) configuration, is cross-platform, and requires much less setup. Writing multiple rendering backends for Direct3D can be a real chore, considering how you're not guaranteed to have a similar interface between version iterations. The jump from Direct3D 9 to Direct3D 10 brought nearly an entirely new API. In many applications, OpenGL is enough. But for scenes requiring complex operations, Direct3D provides tools that make the job more feasible on less capable hardware, due to the control and low-level utilities it provides. Sure, OpenGL can still render the same things that Direct3D can, but the performance difference can be significant depending on the API used, the exclusive technologies and optimizations employed, and the overall complexity of the scene being rendered.

(Also, this is not a comprehensive comparison (if that wasn't already obvious) but a snippet of the capabilities that I am aware of. I do not have much experience with Direct3D itself as many of my projects use OpenGL, but my experience comes from theoretical discussion, game development books that are available to me, and various source code and demos that I have skimmed through.)
Last edited on
The Geometry Pipeline is a major feature that was added to D3D10, which enables generation (not just transformation) of vertex data on the fly. In concept, you can generate an entire scene on the graphics card without having to store anything in RAM (except the most basic of DirectX interfaces and utilities, of course.)


Was available through OpenGL extensions before, and became core in 3.2.

Multi-threaded rendering (... sort of, look here: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476892(v=vs.85).aspx) is advantageous for complex scenes due to the overhead of immediate, blocking state changes that would otherwise have to be endured.


Multithreading is a bit of an issue with OpenGL, but the advantage of OpenGL here really isn't that great. You can still only render in one thread, you can just create bulks of commands to render them later (which may be a bit faster than executing the commands seperately, but I doubt the difference would be too great).


An additional benefit of using Direct3D over OpenGL is that you can be sure that features are available, since iterations of Direct3D aren't released as frequently as OpenGL. In a personal project, we have to determine which API we're able to use at runtime, which is a hassle when you can't use GLEW (it messes up our project configuration, unfortunately.) With DirectX, you can be guaranteed that you'll be using a given API because you have to explicitly state which version you're using.


You can explicitly state what version of OpenGL you're using if you're using OpenGL 3+.
Was available through OpenGL extensions before, and became core in 3.2.
Wasn't aware of that, I'll keep that in mind.

Multithreading is a bit of an issue with OpenGL, but the advantage of OpenGL (assuming you mean Direct3D here) here really isn't that great. You can still only render in one thread, you can just create bulks of commands to render them later (which may be a bit faster than executing the commands seperately, but I doubt the difference would be too great).
The main advantage would be preventing immediate changes to state that would block the thread from executing. I'll admit that the benefit of this is questionable, but state switching is an intensive process, so at the very least it's something to ponder.

You can explicitly state what version of OpenGL you're using if you're using OpenGL 3+.
But using OpenGL 3+ blocks you from the casual gamer demographic (plus gamers with older hardware), as they tend to have integrated graphics that don't support more recent and capable versions of OpenGL, nor do they provide many of the extensions required. In a current project, we've had to prevent certain visual effects from being available to a sizable portion of our testers because their integrated graphics, without OpenGL 2.0 support, couldn't render to textures. (Copying to a texture doesn't count.) However, using a Direct3D API would've gone just fine since Direct3D 8 is supported on many integrated cards, and provides the minimum functionality for render targets.
...due to the control and low-level utilities [Direct3D] provides

And OpenGL does not?

But using OpenGL 3+ blocks you from the casual gamer demographic [...] as they tend to have integrated graphics that don't support more recent and capable versions of OpenGL

Second-generation Intel Core processors support OpenGL 3.0. :/

plus gamers with older hardware

Now *this* is an issue. :)

-Albatross
Last edited on
Not sure if this is an issue, but when I looked at DirectX by way of a Teach Yourself DirectX Game Programming in 21 Days, the DX API is nearly as horrible as the old Win32API. Don't know if OpenGL's API is bad or not though.
Not sure if this is an issue, but when I looked at DirectX by way of a Teach Yourself DirectX Game Programming in 21 Days, the DX API is nearly as horrible as the old Win32API


At least regarding the naming conventions, yes. It's actually the main reason I don't use DirectX.
Pages: 12