Sign in to follow this  
TheCompBoy

DirectX vs OpenGL ?

Recommended Posts

Hello!
I read about DirectX and OpenGL and which one is the best to use for what and which one is bad at what..

All i found was that OpenGL is cross-platform and its easier to code with it.. But is this realy true or can some one please provide me with a better website where i can read about it ? Or something,

Thanks!

Share this post


Link to post
Share on other sites
[url="http://www.google.com.au/search?q=%22DirectX+vs+OpenGL%22+site%3Agamedev.net"]Previous threads here[/url]

GL works on Linux/Mac/Windows
GLES works on mobile devices and browsers
DX9 works on Windows XP/Vista/7
DX11 works on Windows Vista/7

GL has 4 main versions --
* GL1 is the basic stuff that the majority of tutorials will cover. This is old and deprecated, but can still be used as an introduction to graphics programming.
* GL2 is the equivalent to DX9. It adds shaders and other 'modern' features.
* GL3/GL4 are the modern versions, equivalent to DX10/11.

GLES has 2 main versions -- one for older mobiles, and one for newer mobiles with more modern features.

D3D has 3 main versions at the moment --
* DX9 is only used if you need to support Windows XP.
* DX10 has been superseded by DX11, and isn't required any more.
* DX11 is the current gold standard for graphics APIs, but only works on Vista/Win7.

Share this post


Link to post
Share on other sites
OpenGL is a cross-platform graphics API. It only does graphics. It is easier to initialize than DirectX, but I don't think it's significantly easier or more difficult to use. I haven't looked at it in a while, so I'm not the guy to give you many specifics. Also, you'll need other libraries if you want sound or game-controller support.

DirectX is Windows-only, and has APIs for sound and input as well as graphics. It's a bit more complicated to set up, but not severely so. If you're targeting WinXP then you're limited to DirectX 9; if you're not targeting XP then look at DirectX 11. DirectX 9 still has a fixed-function pipeline, which makes it easier to get into than DirectX 11's shader-only model, but so much has changed between the two versions that learning DX 9 has limited benefits if you're more forward-looking.

Share this post


Link to post
Share on other sites
just pick whichever one your more comfitible with.
from what ive read and checked out, there is no "real" difference between the two, other OpenGL does not care weather your running XP/Vista/Win7 it wont cut you off from features if your card supports it.

Share this post


Link to post
Share on other sites
Choosing between DirectX or OpenGL is largely pragmatic. "Knowing" how to use a given API is purely semantics so don't get bogged down with "is x better than y", especially at this stage.

Share this post


Link to post
Share on other sites
I (subjective opinion!) would definitively say yes, OpenGL is easier and better to read than DirectX.

Take a look at a DirectX "Hello World" and OpenGL "Hello World". You will be able to read the OpenGL-code at once, but with DirectX you will first think of "wth? What's LPWSTR? pd3dDevice? SRV? Why aren't there any self-documenting names?". (at least that's what I thought of my first DirectX tutorial)

And it's getting even worse if you what to find a very uncommon functionality in the msdn documentation AND understand it. - good luck!
Well, OpenGL hasn't a super-good documentation either, but most function-names (I had to use) are self-explaining.

If you want to use DirectX, Program on Windows or if you like Visual Studio then ok. If you don't care I would use OpenGL.
But take a look at a Hello World Example of both before you make a decision! ;)

Share this post


Link to post
Share on other sites
[quote name='DEADC0DE' timestamp='1313014256' post='4847363']
I (subjective opinion!) would definitively say yes, OpenGL is easier and better to read than DirectX.

Take a look at a DirectX "Hello World" and OpenGL "Hello World". You will be able to read the OpenGL-code at once, but with DirectX you will first think of "wth? What's LPWSTR? pd3dDevice? SRV? Why aren't there any self-documenting names?". (at least that's what I thought of my first DirectX tutorial)

And it's getting even worse if you what to find a very uncommon functionality in the msdn documentation AND understand it. - good luck!
Well, OpenGL hasn't a super-good documentation either, but most function-names (I had to use) are self-explaining.

If you want to use DirectX, Program on Windows or if you like Visual Studio then ok. If you don't care I would use OpenGL.
But take a look at a Hello World Example of both before you make a decision! ;)
[/quote]

While you are thinking about that, keep in mind that DirectX is built using "simple" COM. Whether you believe that is a good thing or not, a capable Windows programmer should have a good understanding of the naming conventions found within the API.

Share this post


Link to post
Share on other sites
My experience was that OpenGL (1.X though) was waaaay easier to get up and running and rendering a few triangles, but actually working with it was a pita compared to working with Direct3D (9.0c). It was mostly small things, such as math libraries, texture loading and font rendering IIRC. It was several years ago, but I can imagine some of it being the same due to cross platform and licensing issues.

Maybe someone with more (recent) OpenGL experience can clarify the following?
* Is there a math library in OpenGL for matrices/vectors/planes/etc?
* Can you load textures in png or jpeg formats without using external libraries such as DevIL?
* Is there any simple way to render a string in OpenGL? I seem to recall there being some function to draw a single char using a supplied bitmap font..?

Share this post


Link to post
Share on other sites
[quote name='DEADC0DE' timestamp='1313014256' post='4847363']
But take a look at a Hello World Example of both before you make a decision! ;)
[/quote]
A Hello World example is about the worst possible way to judge an API or language.

[quote name='DvDmanDT' timestamp='1313017313' post='4847383']
My experience was that OpenGL (1.X though) was waaaay easier to get up and running and rendering a few triangles, but actually working with it was a pita compared to working with Direct3D (9.0c). It was mostly small things, such as math libraries, texture loading and font rendering IIRC. It was several years ago, but I can imagine some of it being the same due to cross platform and licensing issues.
[/quote]
It's neither of these. It's just that these things are out of the scope of a graphics API. They have never and will never be part of OpenGL. Note that D3D11 (and partially D3D10) went the same way, essentially removing all this bloated D3DX stuff. The only really useful remains were moved to XNAMath, which became largely API independent.

[quote name='DvDmanDT' timestamp='1313017313' post='4847383']
Maybe someone with more (recent) OpenGL experience can clarify the following?
* Is there a math library in OpenGL for matrices/vectors/planes/etc?
* Can you load textures in png or jpeg formats without using external libraries such as DevIL?
* Is there any simple way to render a string in OpenGL? I seem to recall there being some function to draw a single char using a supplied bitmap font..?
[/quote]
No, no and no. The first (lack of math library) may be debatable, but everything else should never be part of a graphics API. Keep in mind that the main focus of a competitive graphics API is not beginner friendliness, but flexibility, performance, scalability, standarization and ease of driver implementation for IHVs. If you are looking for a beginner friendly framework, then both D3D and OpenGL are the wrong choices. A third party graphics or game engine is a much better solution for such scenarios.

Share this post


Link to post
Share on other sites
[quote name='DvDmanDT' timestamp='1313017313' post='4847383']
My experience was that OpenGL (1.X though) was waaaay easier to get up and running and rendering a few triangles, but actually working with it was a pita compared to working with Direct3D (9.0c). It was mostly small things, such as math libraries, texture loading and font rendering IIRC. It was several years ago, but I can imagine some of it being the same due to cross platform and licensing issues.

Maybe someone with more (recent) OpenGL experience can clarify the following?
* Is there a math library in OpenGL for matrices/vectors/planes/etc?
* Can you load textures in png or jpeg formats without using external libraries such as DevIL?
* Is there any simple way to render a string in OpenGL? I seem to recall there being some function to draw a single char using a supplied bitmap font..?
[/quote]

It has nothing to do with cross platform or licensing issues, OpenGL is an interface between your application and the graphics driver, the actual OpenGL implementation you run is written and provided by the hardware manufacturers(The same goes for Direct3D) and it makes little sense to complicate their job by adding a bunch of irrelevant stuff that they have to implement.

Direct3D is exactly the same, it doesn't support text rendering, png or jpeg loading or high level math either, all that is handled by D3DX (Which is a helper library included in the DirectX package (This is written by Microsoft and doesn't make things harder for the hardware manufacturers as they can ignore its existance)).

There are plenty of D3DX equivalents for OpenGL you can choose from, you can even use D3DX along with OpenGL if you're crazy enough just like you can use DirectSound with OpenGL. (Allthough D3DX is a bit more tightly coupled with D3D which makes it far more painful to use with another graphics API)

Share this post


Link to post
Share on other sites
[quote name='Yann L' timestamp='1313018945' post='4847392']A Hello World example is about the worst possible way to judge an API or language.[/quote]

Well, everything I thought of the hello-world in DirectX/OpenGL becaue true (I hate the naming conventions in DX and have big problems with things that should be easy, but are not!).
OpenGL: never had really big problems with it. Ok, it's not easy and not everything goes well, but I never searched for 2 weeks to solve one problem. (in DX I have)

But as I said - subjective opinion. If someone likes DX I have no problem with that ;D

[quote]
* Is there a math library in OpenGL for matrices/vectors/planes/etc?
* Can you load textures in png or jpeg formats without using external libraries such as DevIL?
* Is there any simple way to render a string in OpenGL? I seem to recall there being some function to draw a single char using a supplied bitmap font..?
[/quote]

I don't know about matrices/vectors and so on, but if you want to load a jpeg/render a string... I think you use additional libs in both, DirectX and OpenGL:
DirectX => Win32/DXUT/XNA?... (there is also D3DX11SaveTextureToFile)
OpenGL => glut/SDL/SDL_ttf/glui/glee/openml?...

Share this post


Link to post
Share on other sites
Use directX i was an OpenGL fan but finally i gave up, directX has a lot more support, and complex stuff are handled more easy, and dont care openGL is cross-platform because wine runs DX very well on linux. read this link for more info http://vasilydev.blogspot.com/2011/08/dificulty-of-deploying-3d-applications.html

Share this post


Link to post
Share on other sites
[quote name='Gl_Terminator' timestamp='1313512841' post='4849912']
Use directX i was an OpenGL fan but finally i gave up, directX has a lot more support, and complex stuff are handled more easy,
[/quote]
Could you be more specific please?

Share this post


Link to post
Share on other sites
When i first saw DirectX code and then OpenGL, i said: goodbye DirectX.
Im choosing OpenGL. And im glad that i did this. OpenGL is alot easier and cleaner. It makes many things so much easier.
And now im not even thinking about switching to DirectX.

Share this post


Link to post
Share on other sites
[quote name='BytePtr' timestamp='1313921238' post='4851845']
When i first saw DirectX code and then OpenGL, i said: goodbye DirectX.
Im choosing OpenGL. And im glad that i did this. OpenGL is alot easier and cleaner. It makes many things so much easier.
And now im not even thinking about switching to DirectX.
[/quote]

On the other hand...
[code]
glEnableClientState (GL_VERTEX_ARRAY);
glVertexPointer (...);

glEnableClientState (GL_COLOR_ARRAY);
glColorPointer (...);

glClientActiveTexture (GL_TEXTURE0);
glEnableClientState (GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer (...);

glClientActiveTexture (GL_TEXTURE1);
glEnableClientState (GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer (...);

glClientActiveTexture (GL_TEXTURE1);
glEnableClientState (GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer (...);

glDrawRangeElements (...);
[/code]
Versus...
[code]
device->SetFVF (...);
device->SetStreamSource (...);
device->SetIndices (...);
device->DrawIndexedPrimitive (...);
[/code]
It does go both ways you know. And don't even get me started on "bind to modify"...

Share this post


Link to post
Share on other sites
I am using both equally. I will mention a few things that I don’t see mentioned every time there is an OpenGL vs. Direct3D discussion.

OpenGL has a way of biting you in the ass because of its state-machine structure.
Example #1: Long ago while learning about both Direct3D and OpenGL, I had an engine that was running fine on both. Then one day when I disabled lighting, all of my models in the OpenGL version turned black instead of bright as they had always done before. I had no idea when no-light rendering stopped working so I started research on their lighting model.
I discovered that glColor is used when lighting is off.
I had glColor set to black to prevent it from modifying my sprites and other things it modifies.

Changing a state can have consequences where you least expect it until you really have a lot of experience with OpenGL.


Example #2: I was a beginner with OpenGL but not graphics programming or programming in general. So I knew to put in redundancy checks to prevent redundant state changes.
So if the texture ID in that slot is the same as the one being applied to that slot, early out and time saved.
Unfortunately in OpenGL this is not so simple as it is in Direct3D.
Since you have to bind textures both to create them and to use them, one day a bug appeared when an object was loaded in the middle of gameplay. Suddenly the wrong texture was on an object.
Of course it was a simply folly that was easy to fix, but it is a newbie trap for those just beginning in OpenGL who don’t know the full impact of every single function.


Example #3: And that makes multi-threading a real pain in OpenGL. To load two textures on different threads, you have to create thread-safe blocks (critical sections or mutexes) where you can be sure no other threads can call glBindTexture until you are done with the current texture. And that can be called during a render too so be sure to lock your critical section or mutex during the entire render too.
And glGetError is needed to tell if some functions fail and to get information about why they failed.
Have to create another critical section for that to make sure another thread does not clear the error while you are loading a texture. It goes on and on.
If you are beginning OpenGL, forget about multi-threaded resource creation.



Direct3D 9 has one major issue: Resource management. You will probably not be able to resize the window or toggle full-screen mode for a while if you are beginning Direct3D 9.
Direct3D 10 and Direct3D 11 are harder to grasp for a beginner, but people have been managing and they do not have this major issue, just as OpenGL does not.



Overall DirectX is less hassle-prone and easier to understand thanks to its object-oriented structure. Functions are more descriptive and terminology is more commonplace (see post by mhagain).
DirectX is also significantly faster than OpenGL on most Windows implementations (my new engine has equal logical overhead (same redundancy checks, same tick logic, same number of shader/texture swaps, etc.) but every scene in OpenGL is only 75% the speed of the same scene in Direct3D), but I doubt you will be able to use that difference as a beginner.


L. Spiro

Share this post


Link to post
Share on other sites
My own opinion of the war between the two is that up to version 1.4, when compared to the equivalent D3D level, OpenGL was clearly superior. If that's all the functionality you need, and if you're happy to stick with immediate mode, then it's a no-brainer. You'll probably find OpenGL easier.

The vertex arrays API in OpenGL (the example I gave above) is a mess. If you're using vertex arrays then - when compared to a D3D8 or 9 level (the last versions that let you draw from system memory pointers) - D3D is easier and cleaner. In this case 3 of the function calls I gave above can be collapsed into one.

OpenGL 1.5 was where things got interesting. OpenGL's original implementation of VBOs was - to put it mildly - a crock. Yes, there was some sense in piggy-backing it on top of the vertex array API, but there are a whole heap of problems that arise from that and now we have the gl*Pointer calls that behave in two quite different manners depending on whether or not a VBO is bound. The lack of clear and unambiguous VBO data access semantics is not nice. As for which function to use: glMapBuffer? glBufferData? glBufferSubData? glMapBufferRange? WTF!

Of course that's improved with subsequent extensions, but extensions are both one of OpenGL's greatest strengths and one of the factors that can make you pull your hair out screaming. Want to run on as wide a range of hardware as possible? Prepare to enter the extension tango with multiple rendering backends. OpenGL 2.0 or higher shaders? GL_ARB_shader_objects? GL_ARB_vertex_program? These are the problems you have to deal with when you move on to making programs that people other than you will use. D3D by comparison has one clear API for each version. If you want to code a D3D9 app all of the D3D9 API is available.

OpenGL drivers are a horrible mess. There are no conformance tests yet available for the newer versions, so driver vendors are more or less free to interpret the spec whatever way they want. Driver quality can be poor (hello Intel, hello AMD). You can still get unexpectedly punted back to software emulation. Vendor-specific workarounds are still occasionally needed. Check this note from the AutoDesk people: http://archicad-talk.graphisoft.com/download.php?id=13495&sid=f6cb976ac04f7441b369bf3e58819086

OpenGL's OS portability is better, yes, but it's graphics hardware portability is actually significantly worse.

Plus D3D is faster:
[quote name='YogurtEmperor' timestamp='1313933377' post='4851886']DirectX is also significantly faster than OpenGL on most Windows implementations[/quote]

I'll second that. I've consistently found the same, and so has this guy: http://aras-p.info/blog/2007/09/23/is-opengl-really-faster-than-d3d9/

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1313936301' post='4851900']
OpenGL's OS portability is better, yes, but it's graphics hardware portability is actually significantly worse.

Plus D3D is faster:
[quote name='YogurtEmperor' timestamp='1313933377' post='4851886']DirectX is also significantly faster than OpenGL on most Windows implementations[/quote]

I'll second that. I've consistently found the same, and so has this guy: http://aras-p.info/blog/2007/09/23/is-opengl-really-faster-than-d3d9/
[/quote]
I would be very careful with such bold claims. If you take a look at the numbers in that blog (up to 50% slowdown on OpenGL), it becomes painfully obvious that this guys OpenGL path is doing something horribly wrong. Personally I have witnessed balance going both ways depending on the position of the bottleneck in the pipeline (NVidia, modern GL4 code versus comparable DX11 code). However, differences were rarely significant (and again, both ways) and can majorly be attributed to the differences in the ASM generated by the GLSL and HLSL shader compilers.

It is very difficult to compare different graphics APIs on a performance level, especially if they use different paradigms. I would guess that in 99% of all cases a person claims that API x is faster than API y, the difference can be attributed to incorrect or suboptimal usage of API y. A call to function A may be more efficient than a call to function B on one API, but it may present itself the other way round on the other API. Accommodating such differences may require a substantial change to the rendering logic and possibly even to rendering algorithms. Most people don't do that and quickly slip into what can be a pathological case for one API or another.

A clear exception is the D3D9 draw call overhead mentioned in the blog above. Other than what the blog claims, this behaviour is well documented and perfectly reproducible (and acknowledged by Microsoft). Fixing it was a major improvement of D3D10.

Share this post


Link to post
Share on other sites
As for DirectX 11, there is no comparison to any other graphics API in existence. In my most simplistic and optimal cases, the same scene is over 5 times faster in Direct3D 11 than it is in Direct3D 9.
I literally get 400 FPS in Direct3D 9 and 2,000 FPS in Direct3D 11.


As for OpenGL vs. Direct3D 9, I kept reliable records.
My records are based off the construction of my engine from the very start, when the engine was nothing more than activating a vertex buffer, an optional index buffer, a shader, and 0 or 1 textures.
Both the Direct3D and OpenGL pipelines were equally this simple, and both fully equipped to eliminate any redundant states that could occur from this primitive system.

[url="http://lspiroengine.com/?p=60"]My results[/url].

Frankly I was generous in saying that OpenGL was 95% the speed of Direct3D 9 in all cases, because when I upgraded my DirectX SDK to the latest version that number became 75% but I didn’t have the heart to upgrade my blog accordingly.

As of the latest DirectX API, there is no contest. And unless OpenGL can make a 5-fold improvement on their speed [i]without[/i] multi-threaded rendering, there never will be, compared to DirectX 11.


I am talking about a rendering system that started as primitive as it could be, without even texture support or index buffer support (eliminating most of the potential pitfalls that could slow down my OpenGL implementation), and has grown to be fairly modernized. In all of that time, throughout all stages, OpenGL has never been able to keep up with the speed of DirectX.
But as mentioned in the post, this is on Windows, where the OpenGL specification is not required to meet any certificate of quality. Many vendors may just be lazy when it comes to OpenGL on PC, but may be great on Linux or Macintosh.


L. Spiro

Share this post


Link to post
Share on other sites
[quote name='YogurtEmperor' timestamp='1313953796' post='4851981']
As for OpenGL vs. Direct3D 9, I kept reliable records.
My records are based off the construction of my engine from the very start, when the engine was nothing more than activating a vertex buffer, an optional index buffer, a shader, and 0 or 1 textures.
Both the Direct3D and OpenGL pipelines were equally this simple, and both fully equipped to eliminate any redundant states that could occur from this primitive system.

[url="http://lspiroengine.com/?p=60"]My results[/url].
[/quote]
I'm sorry to be so blunt, but your results are bogus from a performance analysis point of view.

First of all, you are comparing benchmarks in frames per second, ie. in non-linear space. Read [url="http://www.mvps.org/directx/articles/fps_versus_frame_time.htm"]this article[/url] for an explanation how this approach is flawed.

Second, you are benchmarking with a far too high framerate. As a rough and dirty guideline, all benchmarks that include FPS rates above 1000 are useless. The frametime at 1000 fps is 1ms. No API is designed to operate at this framerate. You will run into all kinds of tiny constant overheads that may affect performance in every possible unpredictable way. You don't leave the time for the GPU to amortize overheads. For real solid benchmarking results, you must do much heavier work. Not necessarily more complex, just more. Get your frametimes up, remove constant driver and API overheads. Benchmark your API within the range it is supposed to operate in. And be sure to know what part of the pipeline you're actually benchmarking, which leads us to the next point.

Third, benchmarking a graphics subsystem is much more complex than just hitting out a single number. What part of the pipeline [i]are[/i] you benchmarking ? Do you actually know ? In your case, you essentially always benchmark the API overhead - function calls, internal state management, maybe command buffer transfer. In other words, you are benchmarking the CPU, not even the GPU ! Read [url="http://developer.download.nvidia.com/assets/gamedev/docs/EG_04_OptimizingGPUPipeline.pdf"]this document[/url]. Although a bit dated (and it doesn't represent modern pipelines very well anymore), it gives a good basic overview over how to measure performance in a graphics system. A real engine is going to be bottlenecked within the GPU. So you should actually measure this.

As a conclusion, it is important to learn about how to properly conduct meaningful benchmarks before making claims based on flawed data.

[quote name='YogurtEmperor' timestamp='1313953796' post='4851981']
As of the latest DirectX API, there is no contest. And unless OpenGL can make a 5-fold improvement on their speed [i]without[/i] multi-threaded rendering, there never will be, compared to DirectX 11.
[/quote]
This does not make any sense. Again, read up on bottlenecks. Even if an API would reduce its overhead to zero (which is partially possible by removing it entirely and talking to the hardware directly, as it is done in many consoles), the final impact on game performance is often very small. Sometimes it's not even measurable if the engine bottleneck is on the GPU (which is almost always the case on modern engines). The more work is offloaded to the GPU, the less important API overhead becomes.

The much more important question, which can indeed make a large difference between APIs and drivers, is the quality of the optimizers for the APIs native shader compiler.

Share this post


Link to post
Share on other sites
[quote name='Yann L' timestamp='1313952288' post='4851974']I would be very careful with such bold claims. If you take a look at the numbers in that blog (up to 50% slowdown on OpenGL), it becomes painfully obvious that this guys OpenGL path is doing something horribly wrong.[/quote]

As he's one of the guys behind Unity I'd work on the assumption that he has a reasonable enough idea of what he's talking about. Plus his renderer was originally written for, and optimized around, OpenGL (also mentioned in the blog post) and had D3D shoehorned on after the fact.

Share this post


Link to post
Share on other sites
The blog post is also from Sept 23rd 2007; that is long enough ago that the data point is no longer relevant. Hell, AMD alone between then and now would have put out around 47 driver updates in that time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this