Jump to content
  • Advertisement
Sign in to follow this  
GMX

OpenGL OpenGL vs. DirectX

This topic is 4089 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've heard different things when wondering whether to use DirectX for graphical programs or to use OpenGL. Some people have said that DirectX is more powerful/better but harder to use, is this true?

Share this post


Link to post
Share on other sites
Advertisement
This topic again?

http://www.google.com/search?q=opengl+vs+directx

and

http://tinyurl.com/3x6m7e (local search)

Search is a wonderful thing.

Summary? It is up to you, they can both more or less do the same things, and they do them in similar ways for the most part.

Share this post


Link to post
Share on other sites
This question springs up a lot and tends to lead to pointless arguments between different camps.

Firstly I'd better point out the more accurate comparison is between OpenGL and Direct3D. DirectX controls a lot more than just the graphics. That isn't necessarily a strike against OpenGL though, as with libraries such as SDL you can get a similar grade of functionality for most games.

I'm not an expert, but I've read a few of these debates. Basically I think the argument comes down to this:
  • If you are aiming for cross-platform games, use OpenGL
  • If you prefer C style procedural programming then OpenGL is more your flavour. If you prefer a more object oriented approach you might prefer Direct3D.
  • OpenGL may be slightly easier to get started in and draw things to the screen, but when you get deep into it then it's roughly the same.
  • If you are undecided about any of these and are developing for Windows it probably doesn't matter which one you choose. Once you are familiar with either OpenGL or Direct3D it's pretty easy to learn the other one.
  • Ideally once you get into a large project you'd write the code so it's not that dependent on what graphical interface you use, so you can easily swap between OpenGL or Direct3D or give your players the choice between the two

Share this post


Link to post
Share on other sites
I've worked with both, and OpenGL is a LOT easier to understand and start with. Direct3D is cool when you get it to work, but you got a lot to do before you get it to work like what you want.

But, Direct3D is a lot more powerful than OpenGL. I rarely see professional games in OpenGL, though OpenGL can be used in Linux as well.

I'm a very C style programmer, and only use OOP features when necessary. I also use Dev-C++, which is Linux based, instead of VC++, and OpenGL is the practially the only thing that works on it. This makes me exclusively OpenGL.

Now, I once tried Direct3D with VC++ and was impressed at what it can do, but ultimately I will never go back. It has too much overhead for me, and that constricts me too much. I'm just a 'weekend game programmer', so I'm not looking for flashy cool things. :)

Anyways, I'd say go with OpenGL, but if you want a real professional game, you must learn Direct3D someday. ;)

Share this post


Link to post
Share on other sites
hmmm... you signed up to post this, the most commonly asked question of all time. ( I think )

Troll?

Well, in any case, they're both pretty solid. Here's the first result from Google, that site has been known to have excellent articles. Personally I think its best to support both. There are so many cards and so many configurations out there, that who knows what kind of drivers / system setup your end-user will have. If you use an engine like OGRE, it will already include nearly identical support for both DirectX & OpenGL, so that your user can choose which to use and you can focus on other things.

Share this post


Link to post
Share on other sites
Quote:
Original post by sykosnakesix
I've worked with both, and OpenGL is a LOT easier to understand and start with. Direct3D is cool when you get it to work, but you got a lot to do before you get it to work like what you want.

But, Direct3D is a lot more powerful than OpenGL. I rarely see professional games in OpenGL, though OpenGL can be used in Linux as well.

I'm a very C style programmer, and only use OOP features when necessary. I also use Dev-C++, which is Linux based, instead of VC++, and OpenGL is the practially the only thing that works on it. This makes me exclusively OpenGL.

Now, I once tried Direct3D with VC++ and was impressed at what it can do, but ultimately I will never go back. It has too much overhead for me, and that constricts me too much. I'm just a 'weekend game programmer', so I'm not looking for flashy cool things. :)

Anyways, I'd say go with OpenGL, but if you want a real professional game, you must learn Direct3D someday. ;)


Odd, i thought doom3 was a professional game.

Also i still havn't seen a single feature in D3D that isn't avaliable in OpenGL. For any platform except Vista OpenGL is the only API that provides full access to the latest hardware. (And it will continue to be the case unless microsoft changes their mind about backporting DX10 to older windows versions , or updating D3D9 yet again.)

Ofcourse you might be refering to something else when you talk about power.

Share this post


Link to post
Share on other sites
I think the previous messages give some good advice. For whatever this is worth, I learned DirectX when I took a contract to create the game engine (and the guts of the first game) for a commercial game development company. So I guess it is reasonable to say I understood DirectX pretty well by the time the game was complete and released to market.

A few months ago I had to create the guts of a new 3D engine from scratch, which had to be based upon OpenGL for portability reason. Having gone through a painful learning curve with brand X, I was not thrilled to repeat the learning curve again with brand Y. Anyway, seeing your post made me think my experience might be helpful to your question. But remember, we all have different tastes and reasons for our preferences, so possibly your experience could be opposite mine.

The first week or so was definitely getting used to a new approach to 3D, which is to say, the way they work *is* different - or about as different as they can be given they end up being almost identical, functionally.

However, after the first week, everything thereafter was a major relief! It was like having a thorn removed after you kind of got used to the pain. For me, the difference is that significant. While I know some developers out there might be able to have exactly the opposite experience, it is actually difficult for me to believe it deep inside. Yet I know tastes *are* often that different.

Specifically, when working with the OpenGL API, I find my thinking process is about 3D, graphics, the architecture of my application, things like that. When I work with the DirectX API, I find my thinking process is often about finding or remembering or looking-up arbitrary details - the "how do I get done what I want). It feels like one extra unnecessary level of information to remember and cope with --- which almost seems to vanish with OpenGL.

That was my experience. Depending on your goals and your own preferences (likes and dislikes), your experience could be different, even opposite I suppose (even if that is difficult to imagine from inside my skull).

Oh, one important difference (mentioned by others) is not a matter of taste. If you think you'll ever be creating 3D applications for other platforms, you might want to choose OpenGL now - because then you won't need to subject yourself to a learning curve repeatedly like I did. Actually, it was three times for me (because the first 3D engine I wrote was 100% in my own code with no "helper" API beneath - just linear memory mapped onto the screen).

Good luck.

Share this post


Link to post
Share on other sites
If you are definately going to do Windown, Linux and OSX versions then OpenGL uis probably the easier route. Note the definately in that sentance, some dream about maybe one day along the line doing it shouldn't be a consideration imo.

That aside, honestly, give both a try and see which you prefer.
About the only real advantage D3D has right now over OpenGL for the new user is the SDK and related docs, they are pretty good and easy to get hold of.

One more consideration to throw into the mix; OpenGL is changing and soon.

I'm 99% sure that June will see the release of the new spec for OpenGL Longs Peak, this is a major change and while the old OpenGL2.x style programming will of course still work you might want to consider that you'll have to learn a reasonably different set of API functions afterwards to get the best from it.

I'm also given to believe there are some differences between D3D9 and D3D10 as well which means the same more or less applies there; however don't take my word on this as a definative answer as I'm a D3D9 newbie myself [grin]

Quote:

Original post by sykosnakesix
But, Direct3D is a lot more powerful than OpenGL.


This, is wrong.
Both OGL and D3D talk to the same hardware via the same drivers; effectively what one can do the other can do (there are small differences).

The reason why you see less OpenGL based commerical games is due to other factors; mostly based in what was going on in the OGL world a couple of years back based on the speed of OGL change and unresponsiveness of the ARB to change leading to what many termed 'extension hell' where vendor specific paths had to be taken to have access to the latest and greatest features. This has somewhat been fixed in the last couple of years.

As for games which use it; well anything based on the Quake or Doom engine series is ofcourse OpenGL based and I was surprised to find Homeworld 2 was (I knew Homeworld was), however you'd be right saying that many new commerical titles don't use it on Windows at least (WoW for example uses it on the Mac).

Share this post


Link to post
Share on other sites
I've not worked extensively with D3D on Win32 platforms, but I have on both Xbox and Xbox 360. My impression of it is that it has a C++ interface, but it's not exactly accurate to call it object oriented. It's really almost as procedural as OpenGL in practice.

The capability comparisons are mostly related to your platform and driver combo than the APIs themselves.

OpenGL's biggest strength and weakness is the "Open" part. It means that hardware manufacturers can add support for new features via extensions without the intervention of another company, but it also has historically meant that things can go for long periods of time without being standardized... leaving you in a situation where you have to implement the same feature in 2-3 different ways (using manufacturer extensions) because nothing has been standarized yet.

I don't know if this is a huge problem today, but it was a pretty big annoyance last time I did OpenGL development (shortly before OpenGL 2.0 was standarized).

So yeah, it really doesn't come down to one API being intrinsically better than the other. It comes down to which you prefer and which runs on the platforms you are targetting. (For all its portability, OpenGL isn't supported on a few significant commercial platforms.)

But this is always framed as a "versus" debate. So I'm going to make the audacious suggestion of learning and using both APIs.

Share this post


Link to post
Share on other sites
Quote:
Original post by exwonder
I've not worked extensively with D3D on Win32 platforms, but I have on both Xbox and Xbox 360. My impression of it is that it has a C++ interface, but it's not exactly accurate to call it object oriented. It's really almost as procedural as OpenGL in practice.

The capability comparisons are mostly related to your platform and driver combo than the APIs themselves.

OpenGL's biggest strength and weakness is the "Open" part. It means that hardware manufacturers can add support for new features via extensions without the intervention of another company, but it also has historically meant that things can go for long periods of time without being standardized... leaving you in a situation where you have to implement the same feature in 2-3 different ways (using manufacturer extensions) because nothing has been standarized yet.

I don't know if this is a huge problem today, but it was a pretty big annoyance last time I did OpenGL development (shortly before OpenGL 2.0 was standarized).

So yeah, it really doesn't come down to one API being intrinsically better than the other. It comes down to which you prefer and which runs on the platforms you are targetting. (For all its portability, OpenGL isn't supported on a few significant commercial platforms.)

But this is always framed as a "versus" debate. So I'm going to make the audacious suggestion of learning and using both APIs.


It is a bit better today, but i would still claim that OpenGLs main strengths are extensions and portability, and its greatest weakness is extensions.

Currently we can play with the G80 using nvidias extensions. (We could do that a few months before D3D10 was released even) , ATI/AMD doesn't seem to have any info regarding extensions for the r600 yet though. Thus we cannot know how big a problem it will be for this generation of cards.

The uncertainty is the biggest problem right now imo.
If i write a game in D3D10 i know it will run well on ATI:s next card without any modifications. If i write it in OpenGL using the new nvidia extensions i will possibly have to release a patch to get the same features on ATI hardware.

Ofcourse if i write it in OpenGL i get those features working in win2k/XP, aswell as non microsoft systems, but the number of users with G80:s running those systems are easily counted. (Mostly OpenGL developers who like to play with new shiny features as most gamers belive you need Vista to even use a G80)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Similar Content

    • By nOoNEE
      hello guys , i have some questions  what does glLinkProgram  and  glBindAttribLocation do?  i searched but there wasnt any good resource 
    • By owenjr
      Hi, I'm a Multimedia Engineering student. I am about to finish my dergree and I'm already thinking about what topic to cover in my final college project.
      I'm interested in the procedural animation with c++ and OpenGL of creatures, something like a spider for example. Can someone tell me what are the issues I should investigate to carry it out? I understand that it has some dependence on artificial intelligence but I do not know to what extent. Can someone help me to find information about it? Thank you very much.
       
      Examples: 
      - Procedural multi-legged walking animation
      - Procedural Locomotion of Multi-Legged Characters in Dynamic Environments
    • By Lewa
      So, i'm still on my quest to unterstanding the intricacies of HDR and implementing this into my engine. Currently i'm at the step to implementing tonemapping. I stumbled upon this blogposts:
      http://filmicworlds.com/blog/filmic-tonemapping-operators/
      http://frictionalgames.blogspot.com/2012/09/tech-feature-hdr-lightning.html
      and tried to implement some of those mentioned tonemapping methods into my postprocessing shader.
      The issue is that none of them creates the same results as shown in the blogpost which definitely has to do with the initial range in which the values are stored in the HDR buffer. For simplicity sake i store the values between 0 and 1 in the HDR buffer (ambient light is 0.3, directional light is 0.7)
      This is the tonemapping code:
      vec3 Uncharted2Tonemap(vec3 x) { float A = 0.15; float B = 0.50; float C = 0.10; float D = 0.20; float E = 0.02; float F = 0.30; return ((x*(A*x+C*B)+D*E)/(x*(A*x+B)+D*F))-E/F; } This is without the uncharted tonemapping:
      This is with the uncharted tonemapping:
      Which makes the image a lot darker.
      The shader code looks like this:
      void main() { vec3 color = texture2D(texture_diffuse, vTexcoord).rgb; color = Uncharted2Tonemap(color); //gamma correction (use only if not done in tonemapping code) color = gammaCorrection(color); outputF = vec4(color,1.0f); } Now, from my understanding is that tonemapping should bring the range down from HDR to 0-1.
      But the output of the tonemapping function heavily depends on the initial range of the values in the HDR buffer. (You can't expect to set the sun intensity the first time to 10 and the second time to 1000 and excpect the same result if you feed that into the tonemapper.) So i suppose that this also depends on the exposure which i have to implement?
      To check this i plotted the tonemapping curve:
      You can see that the curve goes only up to around to a value of 0.21 (while being fed a value of 1) and then basically flattens out. (which would explain why the image got darker.)
       
      My guestion is: In what range should the values in the HDR buffer be which then get tonemapped? Do i have to bring them down to a range of 0-1 by multiplying with the exposure?
      For example, if i increase the values of the light by 10 (directional light would be 7 and ambient light 3) then i would need to divide HDR values by 10 in order to get a value range of 0-1 which then could be fed into the tonemapping curve. Is that correct?
    • By nOoNEE
      i am reading this book : link
      in the OpenGL Rendering Pipeline section there is a picture like this: link
      but the question is this i dont really understand why it is necessary to turn pixel data in to fragment and then fragment into pixel could please give me a source or a clear Explanation that why it is necessary ? thank you so mu
       
       
    • By Inbar_xz
      I'm using the OPENGL with eclipse+JOGL.
      My goal is to create movement of the camera and the player.
      I create main class, which create some box in 3D and hold 
      an object of PlayerAxis.
      I create PlayerAxis class which hold the axis of the player.
      If we want to move the camera, then in the main class I call to 
      the func "cameraMove"(from PlayerAxis) and it update the player axis.
      That's work good.
      The problem start if I move the camera on 2 axis, 
      for example if I move with the camera right(that's on the y axis)
      and then down(on the x axis) -
      in some point the move front is not to the front anymore..
      In order to move to the front, I do
      player.playerMoving(0, 0, 1);
      And I learn that in order to keep the front move, 
      I need to convert (0, 0, 1) to the player axis, and then add this.
      I think I dont do the convert right.. 
      I will be glad for help!

      Here is part of my PlayerAxis class:
       
      //player coordinate float x[] = new float[3]; float y[] = new float[3]; float z[] = new float[3]; public PlayerAxis(float move_step, float angle_move) { x[0] = 1; y[1] = 1; z[2] = -1; step = move_step; angle = angle_move; setTransMatrix(); } public void cameraMoving(float angle_step, String axis) { float[] new_x = x; float[] new_y = y; float[] new_z = z; float alfa = angle_step * angle; switch(axis) { case "x": new_z = addVectors(multScalar(z, COS(alfa)), multScalar(y, SIN(alfa))); new_y = subVectors(multScalar(y, COS(alfa)), multScalar(z, SIN(alfa))); break; case "y": new_x = addVectors(multScalar(x, COS(alfa)), multScalar(z, SIN(alfa))); new_z = subVectors(multScalar(z, COS(alfa)), multScalar(x, SIN(alfa))); break; case "z": new_x = addVectors(multScalar(x, COS(alfa)), multScalar(y, SIN(alfa))); new_y = subVectors(multScalar(y, COS(alfa)), multScalar(x, SIN(alfa))); } x = new_x; y = new_y; z = new_z; normalization(); } public void playerMoving(float x_move, float y_move, float z_move) { float[] move = new float[3]; move[0] = x_move; move[1] = y_move; move[2] = z_move; setTransMatrix(); float[] trans_move = transVector(move); position[0] = position[0] + step*trans_move[0]; position[1] = position[1] + step*trans_move[1]; position[2] = position[2] + step*trans_move[2]; } public void setTransMatrix() { for (int i = 0; i < 3; i++) { coordiTrans[0][i] = x[i]; coordiTrans[1][i] = y[i]; coordiTrans[2][i] = z[i]; } } public float[] transVector(float[] v) { return multiplyMatrixInVector(coordiTrans, v); }  
      and in the main class i have this:
       
      public void keyPressed(KeyEvent e) { if (e.getKeyCode()== KeyEvent.VK_ESCAPE) { System.exit(0); //player move } else if (e.getKeyCode()== KeyEvent.VK_W) { //front //moveAmount[2] += -0.1f; player.playerMoving(0, 0, 1); } else if (e.getKeyCode()== KeyEvent.VK_S) { //back //moveAmount[2] += 0.1f; player.playerMoving(0, 0, -1); } else if (e.getKeyCode()== KeyEvent.VK_A) { //left //moveAmount[0] += -0.1f; player.playerMoving(-1, 0, 0); } else if (e.getKeyCode()== KeyEvent.VK_D) { //right //moveAmount[0] += 0.1f; player.playerMoving(1, 0, 0); } else if (e.getKeyCode()== KeyEvent.VK_E) { //moveAmount[0] += 0.1f; player.playerMoving(0, 1, 0); } else if (e.getKeyCode()== KeyEvent.VK_Q) { //moveAmount[0] += 0.1f; player.playerMoving(0, -1, 0); //camera move } else if (e.getKeyCode()== KeyEvent.VK_I) { //up player.cameraMoving(1, "x"); } else if (e.getKeyCode()== KeyEvent.VK_K) { //down player.cameraMoving(-1, "x"); } else if (e.getKeyCode()== KeyEvent.VK_L) { //right player.cameraMoving(-1, "y"); } else if (e.getKeyCode()== KeyEvent.VK_J) { //left player.cameraMoving(1, "y"); } else if (e.getKeyCode()== KeyEvent.VK_O) { //right round player.cameraMoving(-1, "z"); } else if (e.getKeyCode()== KeyEvent.VK_U) { //left round player.cameraMoving(1, "z"); } }  
      finallt found it.... i confused with the transformation matrix row and col. thanks anyway!
    • By Lewa
      So, i'm currently trying to implement an SSAO shader from THIS tutorial and i'm running into a few issues here.
      Now, this SSAO method requires view space positions and normals. I'm storing the normals in my deferred renderer in world-space so i had to do a conversion and reconstruct the position from the depth buffer.
      And something there goes horribly wrong (which has probably to do with worldspace to viewspace transformations).
      (here is the full shader source code if someone wants to take a look at it)
      Now, i suspect that the normals are the culprit.
      vec3 normal = ((uNormalViewMatrix*vec4(normalize(texture2D(sNormals, vTexcoord).rgb),1.0)).xyz); "sNormals" is a 2D texture which stores the normals in world space in a RGB FP16 buffer.
      Now i can't use the camera viewspace matrix to transform the normals into viewspace as the cameras position isn't set at (0,0,0), thus skewing the result.
      So what i did is to create a new viewmatrix specifically for this normal without the position at vec3(0,0,0);
      //"camera" is the camera which was used for rendering the normal buffer renderer.setUniform4m(ressources->shaderSSAO->getUniform("uNormalViewMatrix"), glmExt::createViewMatrix(glm::vec3(0,0,0),camera.getForward(),camera.getUp())//parameters are (position,forwardVector,upVector) ); Though i have the feeling this is the wrong approach. Is this right or is there a better/correct way of transforming a world space normal into viewspace?
    • By HawkDeath
      Hi,
      I'm trying mix two textures using own shader system, but I have a problem (I think) with uniforms.
      Code: https://github.com/HawkDeath/shader/tree/test
      To debug I use RenderDocs, but I did not receive good results. In the first attachment is my result, in the second attachment is what should be.
      PS. I base on this tutorial https://learnopengl.com/Getting-started/Textures.


    • By norman784
      I'm having issues loading textures, as I'm clueless on how to handle / load images maybe I missing something, but the past few days I just google a lot to try to find a solution. Well theres two issues I think, one I'm using Kotlin Native (EAP) and OpenGL wrapper / STB image, so I'm not quite sure wheres the issue, if someone with more experience could give me some hints on how to solve this issue?
      The code is here, if I'm not mistaken the workflow is pretty straight forward, stbi_load returns the pixels of the image (as char array or byte array) and you need to pass those pixels directly to glTexImage2D, so a I'm missing something here it seems.
      Regards
    • By Hashbrown
      I've noticed in most post processing tutorials several shaders are used one after another: one for bloom, another for contrast, and so on. For example: 
      postprocessing.quad.bind() // Effect 1 effect1.shader.bind(); postprocessing.texture.bind(); postprocessing.quad.draw(); postprocessing.texture.unbind(); effect1.shader.unbind(); // Effect 2 effect2.shader.bind(); // ...and so on postprocessing.quad.unbind() Is this good practice, how many shaders can I bind and unbind before I hit performance issues? I'm afraid I don't know what the good practices are in open/webGL regarding binding and unbinding resources. 
      I'm guessing binding many shaders at post processing is okay since the scene has already been updated and I'm just working on a quad and texture at that moment. Or is it more optimal to put shader code in chunks and bind less frequently? I'd love to use several shaders at post though. 
      Another example of what I'm doing at the moment:
      1) Loop through GameObjects, bind its phong shader (send color, shadow, spec, normal samplers), unbind all.
      2) At post: bind post processor quad, and loop/bind through different shader effects, and so on ...
      Thanks all! 
    • By phil67rpg
      void collision(int v) { collision_bug_one(0.0f, 10.0f); glutPostRedisplay(); glutTimerFunc(1000, collision, 0); } void coll_sprite() { if (board[0][0] == 1) { collision(0); flag[0][0] = 1; } } void erase_sprite() { if (flag[0][0] == 1) { glColor3f(0.0f, 0.0f, 0.0f); glBegin(GL_POLYGON); glVertex3f(0.0f, 10.0f, 0.0f); glVertex3f(0.0f, 9.0f, 0.0f); glVertex3f(1.0f, 9.0f, 0.0f); glVertex3f(1.0f, 10.0f, 0.0f); glEnd(); } } I am using glutTimerFunc to wait a small amount of time to display a collision sprite before I black out the sprite. unfortunately my code only blacks out the said sprite without drawing the collision sprite, I have done a great deal of research on the glutTimerFunc and  animation.
  • Advertisement
  • Popular Now

  • Forum Statistics

    • Total Topics
      631383
    • Total Posts
      2999694
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!