My goal is to create a 2d game and I want to be as much in control as possible. That's why I'm currently learning C++ and eventually I will take the road of learning a graphics API and writting my own engine. My question to those who have had experience with both is, which should I go for? Is one language better then the other? more versatile? easier, harder to use?
0
Should I go with directX or openGL
Started by clem84, Jul 02 2012 08:13 AM
23 replies to this topic
Sponsor:
#2 Members - Reputation: 337
Posted 02 July 2012 - 08:42 AM
dont write your own engine.. write your own game ;) When you have your game you can extract good parts into an engine when you make your next game..
If you're just starting out as a programmer you might want to consider some 2d lib instead of using ogl or dx right away as you will progress faster to make your first game.. I havent used any of them as I started with ogl at university, but others could help with that or it shouldn't be to hard to find some info.
If you still want to go with an API you probably want to start with opengl.. Its easer to get help and its an easier interface to start off with..
If you're just starting out as a programmer you might want to consider some 2d lib instead of using ogl or dx right away as you will progress faster to make your first game.. I havent used any of them as I started with ogl at university, but others could help with that or it shouldn't be to hard to find some info.
If you still want to go with an API you probably want to start with opengl.. Its easer to get help and its an easier interface to start off with..
#3 Members - Reputation: 777
Posted 02 July 2012 - 08:59 AM
You could also go with SFML http://www.gamefromscratch.com/page/Game-From-Scratch-CPP-Edition.aspx < That is a fantastic tutorial with SFML and C++ showing off how to make a Pong clone with the graphic library SFML. It's really worth checking out and very easy to understand. From what i've seen with DX and OpenGL both of them aren't terribly bad to understand but starting out you'll wanna go with something simple to get a good foundation down. SFML can do that and it did for me. 
#5 Members - Reputation: 163
Posted 02 July 2012 - 09:50 AM
As a matter of fact I can understand you wanting to write a program that interfaces with a gfx api such as OpenGL or DirectX. But take note that you should not write your own engine. You can play around with the 2 to know what it's like communicating with a graphics card, but later you should really go for a readymade engine to create your game; that way you spend more time creating your game than doing side irrelevant stuff. The idea is that first you realize your concept quickly by creating a prototype with a readymade engine, then you can decide to create your real final game whichever way you like, using lowlevel APIs and the like.
<= A n00b programmer, on 06 June 2011 - 04:28 AM, said:
Someone once told me learning C++ was like learning how to juggle knives...
<= Servant of the Lord, on 06 June 2011 - 04:43 AM, replied:
That's not true at all! C++ doesn't require anywhere near the hand-eye coordination juggling requires. And with C++ after you slip and kill someone with the knife, you can reuse it for something else afterward. With actual knives, you have to get rid of the evidence.
Someone once told me learning C++ was like learning how to juggle knives...
<= Servant of the Lord, on 06 June 2011 - 04:43 AM, replied:
That's not true at all! C++ doesn't require anywhere near the hand-eye coordination juggling requires. And with C++ after you slip and kill someone with the knife, you can reuse it for something else afterward. With actual knives, you have to get rid of the evidence.
#7 Members - Reputation: 3839
Posted 02 July 2012 - 11:45 AM
Having experience with both, here's my take on it.
Ultimately you should learn both - neither is 100% superior to the other and having knowledge of both will give you a more well-rounded perspective. Learning one will not prevent you from learning the other, and there are a lot of core concepts that are common to both.
Each has a subtle but significant difference in approach. D3D tends to expose what's on the hardware and only what's on the hardware whereas OpenGL tends to abstract things a little more. There are advantages and disadvantages to each approach, with D3D needing slightly more work here and there but OpenGL making it a little harder to find the fast path owing to software fallbacks.
The quality of D3D drivers tends to be higher but OpenGL is a better option if portability is important to you.
D3D has vastly superior tools and documentation available; unfortunately OpenGL just can't compete in this respect. OpenGL is also hampered by the fact that a lot of the info and tutorials available on the web are seriously out of date (many were never much good to begin with) and will lead you into bad habits.
In terms of ease of use there is next to no difference whatsoever between the modern versions of each API. You'll be writing almost the exact same kind of code with GL3.x+ as you will with D3D10/11, and the main differences will be just in the API calls (e.g. glMapBufferRange vs ID3D11DeviceContext::Map) - the surrounding C++ code will be effectively identical.
OpenGL does have an older "immediate mode" which many may find easier to get started with and which D3D has no equivalent of, and also still retains a fixed pipeline option (deprecated in modern versions but in practice it will always be available - at least for the foreseeable future) which modern D3D has done away with (it's still in version 9 though). Be cautioned that this is only easier for relatively trivial operations (the number of glTexEnv/etc calls you need to get the equivalent of one line of shader code can be quite staggering), you will be getting poor performance from it, and overall it's considered one of those "bad habits" I mentioned earlier.
Many older versions of D3D do come with helper interfaces for easier handling of sprites, meshes, shaders and so on, but these are being phased out in more recent versions.
So, as for which of the two to pick up first, you can more or less flip a coin. Each is an excellent introduction provided you avoid the more common pitfalls.
Ultimately you should learn both - neither is 100% superior to the other and having knowledge of both will give you a more well-rounded perspective. Learning one will not prevent you from learning the other, and there are a lot of core concepts that are common to both.
Each has a subtle but significant difference in approach. D3D tends to expose what's on the hardware and only what's on the hardware whereas OpenGL tends to abstract things a little more. There are advantages and disadvantages to each approach, with D3D needing slightly more work here and there but OpenGL making it a little harder to find the fast path owing to software fallbacks.
The quality of D3D drivers tends to be higher but OpenGL is a better option if portability is important to you.
D3D has vastly superior tools and documentation available; unfortunately OpenGL just can't compete in this respect. OpenGL is also hampered by the fact that a lot of the info and tutorials available on the web are seriously out of date (many were never much good to begin with) and will lead you into bad habits.
In terms of ease of use there is next to no difference whatsoever between the modern versions of each API. You'll be writing almost the exact same kind of code with GL3.x+ as you will with D3D10/11, and the main differences will be just in the API calls (e.g. glMapBufferRange vs ID3D11DeviceContext::Map) - the surrounding C++ code will be effectively identical.
OpenGL does have an older "immediate mode" which many may find easier to get started with and which D3D has no equivalent of, and also still retains a fixed pipeline option (deprecated in modern versions but in practice it will always be available - at least for the foreseeable future) which modern D3D has done away with (it's still in version 9 though). Be cautioned that this is only easier for relatively trivial operations (the number of glTexEnv/etc calls you need to get the equivalent of one line of shader code can be quite staggering), you will be getting poor performance from it, and overall it's considered one of those "bad habits" I mentioned earlier.
Many older versions of D3D do come with helper interfaces for easier handling of sprites, meshes, shaders and so on, but these are being phased out in more recent versions.
So, as for which of the two to pick up first, you can more or less flip a coin. Each is an excellent introduction provided you avoid the more common pitfalls.
Edited by mhagain, 02 July 2012 - 11:46 AM.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#8 Members - Reputation: 125
Posted 02 July 2012 - 11:49 AM
Thanks for all the replies. I'm very much a noob when it comes to game creation. What are SDL and SFML? Are they a graphics language similar to Opengl and DirectX?
Anyway, I'm thinking of doing that pong game in SFML and take it to completion just to get a basic idea of what's involved in making a full game.
Anyway, I'm thinking of doing that pong game in SFML and take it to completion just to get a basic idea of what's involved in making a full game.
#9 Members - Reputation: 125
Posted 02 July 2012 - 12:00 PM
Thanks MHagain. The game I want to make is completely 2D using animated sprites. I don't suppose that makes much of a difference right? Anyway. You said to pick one so I think I'll start with openGL a little later on after I've completed that Pong game in SFML, and eventually move on to D3D.
#11 Members - Reputation: 3839
Posted 02 July 2012 - 12:48 PM
The best OpenGL tutorial is probably "Learning Modern 3D Graphics Programming" - http://www.arcsynthesis.org/gltut/ - this will see you right with up-to-date info and won't lead you into doing many of the things addressed on this page: http://www.opengl.org/wiki/Common_Mistakes (that's a very handy link to have by your side if using any of the older references by the way - always a good idea to cross-check with it).
For D3D the SDK tutorial material is very good but you probably need to supplement it with further info from elsewhere. The ToyMaker site was one I found useful years ago - http://www.toymaker.info/ - and I've heard very very good things about Frank Luna's books but don't have direct experience of them myself.
But overall once you have one you don't really need much in the way of tutorials for the other. You'll know that you need to (for example) map a dynamic vertex buffer and write data to it, so you'll find it easy enough to just search for the relevant terms and find the info you need.
For D3D the SDK tutorial material is very good but you probably need to supplement it with further info from elsewhere. The ToyMaker site was one I found useful years ago - http://www.toymaker.info/ - and I've heard very very good things about Frank Luna's books but don't have direct experience of them myself.
But overall once you have one you don't really need much in the way of tutorials for the other. You'll know that you need to (for example) map a dynamic vertex buffer and write data to it, so you'll find it easy enough to just search for the relevant terms and find the info you need.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#12 Crossbones+ - Reputation: 1179
Posted 03 July 2012 - 02:41 AM
Most of this stuff is still there to be honest, Maths has moved into the XNA math lib(as of DX11), effect framework into a standalone lib that you still have to compile (as of DX11), texture and shader loading is still in D3DX for all versions. DX10 still provides an effect and math framework.Many older versions of D3D do come with helper interfaces for easier handling of sprites, meshes, shaders and so on, but these are being phased out in more recent versions.
The only thing we lost is the ability to create simple 3D geometries through D3DX like: spheres, boxes and sprites and fonts (and for the last two that's also only true since DX11).
Also a good tutorial site is http://codesampler.com as they provide GL and DX (8.1 and 9.0 only though) samples which accomplish the same thing, but you have to be able to learn from source code with these tutorials.
Edited by NightCreature83, 03 July 2012 - 02:41 AM.
#13 Members - Reputation: 382
Posted 03 July 2012 - 03:23 AM
Just pick the one which you can find the most libraries for (i.e animated models etc...) unless you plan on writing your own then you of course have more flexibility.
Other than that they are pretty much the same to work with.
Also, if you ever want your game to work on something other than a Windows Desktop PC, then there is no choice... OpenGL is the only way to go.
Other than that they are pretty much the same to work with.
Also, if you ever want your game to work on something other than a Windows Desktop PC, then there is no choice... OpenGL is the only way to go.
#14 Members - Reputation: 3839
Posted 03 July 2012 - 03:44 AM
.....unless that something is an XBox or Windows mobile device....Also, if you ever want your game to work on something other than a Windows Desktop PC, then there is no choice... OpenGL is the only way to go.
But a good point and it does raise a slightly thorny issue. Many of the devices for which you'll commonly see portability claimed for OpenGL actually use GL ES. There are similarities (ES is heavily based on desktop GL) but there are also huge differences, and much of what you'll find in full desktop GL just isn't in ES. So you can't just write a desktop GL program and claim portability to these devices, and when you see portability claimed for OpenGL you need to be aware that in many cases it really means just "Windows/Linux/Mac (or any other platform for which a full desktop GL implementation is available)".
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#15 Members - Reputation: 382
Posted 03 July 2012 - 04:02 AM
.....unless that something is an XBox or Windows mobile device....
Can we even develop using C++ for those devices? Surely Microsoft has restricted us to using C#/XNA only for them unless your games company gets a bespoke contract with them.
As for OpenGL ES, yeah your right. The larger issues I ran into is that unless using an old device I had to develop code very similar to if I was targetting the core profile on the desktop version (which we all should be ;). Perhaps the biggest issue however is rigging the damn thing up to whatever windowing system the device uses. Eeek, no Glut!
(Sorry, I am taking this a bit off topic, I don't even know if the OP wants to write mobile / unix applications lol).
Edited by Karsten_, 03 July 2012 - 04:04 AM.
#16 Members - Reputation: 777
Posted 03 July 2012 - 04:12 AM
Yeah you can only code in C#/.Net with XNA without the Dev Kit.
.....unless that something is an XBox or Windows mobile device....
Can we even develop using C++ for those devices? Surely Microsoft has restricted us to using C#/XNA only for them unless your games company gets a bespoke contract with them.
As for OpenGL ES, yeah your right. The larger issues I ran into is that unless using an old device I had to develop code very similar to if I was targetting the core profile on the desktop version (which we all should be ;). Perhaps the biggest issue however is rigging the damn thing up to whatever windowing system the device uses. Eeek, no Glut!
(Sorry, I am taking this a bit off topic, I don't even know if the OP wants to write mobile / unix applications lol).
#17 Members - Reputation: 1408
Posted 03 July 2012 - 06:41 AM
One thing that usually isn't mentioned, is the use of version management tools. Writing programs for OpenGL (and surely D3D) is difficult. You get something to work, and then suddenly something stops working. This happens all the time. Using a version management tool has saved a lot of effort for me, even for hobby experimental projects.
#18 Members - Reputation: 132
Posted 03 July 2012 - 12:33 PM
DirectX and openGL are both API that lets you program the GPU. One is not better than the other, but in practice you may end up having a preference.
That being said, since DirectX is limited to Mircosoft platform, you cannot use directX code anywhere else. And DirectX 11 and more is more suitable to desktop PC games and Xbox. Windows 8 RT will have directX support but I am not sure it will be the full DirectX 11 API.
So I think, if you think you want to give a try to iOS or Android soon enough, then OpenGL is the best (only) choice. If you only care about Microsoft platform, then DirectX.
In reallity, if you plan a carreer in graphics engineering, you will be working with whatever API your company is using. So get started with one API if you have the choice now, and study the other API when you have the time.
That being said, since DirectX is limited to Mircosoft platform, you cannot use directX code anywhere else. And DirectX 11 and more is more suitable to desktop PC games and Xbox. Windows 8 RT will have directX support but I am not sure it will be the full DirectX 11 API.
So I think, if you think you want to give a try to iOS or Android soon enough, then OpenGL is the best (only) choice. If you only care about Microsoft platform, then DirectX.
In reallity, if you plan a carreer in graphics engineering, you will be working with whatever API your company is using. So get started with one API if you have the choice now, and study the other API when you have the time.
#19 Members - Reputation: 241
Posted 03 July 2012 - 12:53 PM
WIndows RT has full DirectX11 support, but only requires a 9_1 feature set... just to confuse. (I believe that's how Microsoft describes it). Unfortuantely, the only platform which runs both D3D and OpenGL are Windows PCs.
I'm amazed NV and AMD haven't got together to create a new, truly portable, API. It would life a gazzilion times easier for developers on non-console hardware. Even Windows RT could run it (although it would seriously piss off Microsoft!) if it were totally driver based.
I'm amazed NV and AMD haven't got together to create a new, truly portable, API. It would life a gazzilion times easier for developers on non-console hardware. Even Windows RT could run it (although it would seriously piss off Microsoft!) if it were totally driver based.
#20 Members - Reputation: 132
Posted 03 July 2012 - 01:57 PM
I'm amazed NV and AMD haven't got together to create a new, truly portable, API. It would life a gazzilion times easier for developers on non-console hardware. Even Windows RT could run it (although it would seriously piss off Microsoft!) if it were totally driver based.
Fortunately, both API are not so different (at the level of OpenGL 2.0 and DirectX 9) that there is huge work for developpers to convert OpenGL code to DirectX and vice versa... Still, it takes some time and some thinking. Especially if you are in a hurry...
