Sign in to follow this  

Should I go with directX or openGL

This topic is 1989 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

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?

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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. :D

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 [i]modern[/i] 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 [i]does[/i] 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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1341251114' post='4954973']
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.
[/quote]

Could you tell us some good tutorials for both? please

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1341251114' post='4954973']
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.
[/quote]
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.
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 [url="http://codesampler.com"]http://codesampler.com[/url] 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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='Karsten_' timestamp='1341307393' post='4955202']
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.
[/quote]
.....unless that something is an XBox or Windows mobile device....

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)".

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1341308660' post='4955216']
.....unless that something is an XBox or Windows mobile device....
[/quote]

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_

Share this post


Link to post
Share on other sites
[quote name='Karsten_' timestamp='1341309772' post='4955219']
[quote name='mhagain' timestamp='1341308660' post='4955216']
.....unless that something is an XBox or Windows mobile device....
[/quote]

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).
[/quote]
Yeah you can only code in C#/.Net with XNA without the Dev Kit.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='mark ds' timestamp='1341341637' post='4955399']
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.
[/quote]

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...

Share this post


Link to post
Share on other sites
[quote name='mark ds' timestamp='1341341637' post='4955399']
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.
[/quote]
AMD and Nvidia will never put there heads together to create a new API, just look at Close to Metal and Cuda, even OpenCL hasn't replaced Cuda or DirectCompute yet.
The DX 11 run time is actually pretty nifty when you think about it these feature levels make it a lot easier for people to develop on windows tbh. As long as you are running Vista or up DX 11 can now target very old DX9.0 hardware up to the newest DX11.1 hardware all from one API, there are a few features you shouldn't use but is easy to code arround.

Share this post


Link to post
Share on other sites
A single API would be nice, but in reality it's not really that big a deal. So long as the C/C++ code surrounding the API calls can be the same (or mostly the same) then the API itself tends to disappear into the background, and this is increasingly the case with modern versions of both.

A hypothetical example might be some code to add a bunch of particles to a dynamic vertex buffer and draw them when done. With D3D it's just some IASet* calls, Map, Unmap, set your shaders and Draw*. With OpenGL it's a glBindVertexArray, Map, Unmap, set your shaders and glDraw*. The big part of the code is actually setting up the particle verts and copying them in.

The bigger difference will be with shaders. Cg does exist so you can use that and compile it for either GL or D3D, but some might prefer to use the native shading language instead. But at least there [i]is[/i] an option that can be used with both.

As for NV and AMD getting together to create one API to rule them all - I highly doubt it. The situation with OpenGL is highly relevant here - NV have created a whole bunch of extensions that only work with their hardware and drivers, ditto AMD, and each would prefer if you gave their platform a competitive advantage over the other in your program.

Share this post


Link to post
Share on other sites

This topic is 1989 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.

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