Sign in to follow this  
crosstantine

OpenGL worth the try?

Recommended Posts

crosstantine    102
I'm starting with the game development path, I've a very good background in programming (C++, Java, C#, etc etc), not an expert but I'm sure I could manage most of them pretty good, and I'm starting right now with SDL and I'm very happy with the results, but I stopped to watch if there's a serious game development using OpenGL and found that OpenGL is used mainly as "learning" library, and some maths work,

I consider myself an Open Source lover and always try to enforce the multiple platform support in my developments, but I'm finding that the people say: "if you want to create serious game development stick with DirectX and XNA (Same thing)", that means that the game development future for apple, linux or others (based on OpenGL) is extinct?

Is it worthless to learn OpenGL if you will end up with DirectX anyway?

What about Android and iOS that are OpenGL based, are they planning to move to DirectX in the future (don't think so, but it's pretty strange that OpenGL has no really big plans for the future)?

I'm aware that this topic is going to be one of those topics where some people pull in one way while others pull to the other side of the rope, but I dont want to put all the eggs on the same basket and waste time.

Thanks for your answers.

Share this post


Link to post
Share on other sites
PropheticEdge    150
[quote name='Crosstantine' timestamp='1302907489' post='4798947']
I'm starting with the game development path, I've a very good background in programming (C++, Java, C#, etc etc), not an expert but I'm sure I could manage most of them pretty good, and I'm starting right now with SDL and I'm very happy with the results, but I stopped to watch if there's a serious game development using OpenGL and found that OpenGL is used mainly as "learning" library, and some maths work,

I consider myself an Open Source lover and always try to enforce the multiple platform support in my developments, but I'm finding that the people say: "if you want to create serious game development stick with DirectX and XNA (Same thing)", that means that the game development future for apple, linux or others (based on OpenGL) is extinct?

Is it worthless to learn OpenGL if you will end up with DirectX anyway?

What about Android and iOS that are OpenGL based, are they planning to move to DirectX in the future (don't think so, but it's pretty strange that OpenGL has no really big plans for the future)?

I'm aware that this topic is going to be one of those topics where some people pull in one way while others pull to the other side of the rope, but I dont want to put all the eggs on the same basket and waste time.

Thanks for your answers.
[/quote]

Woah woah woah! OpenGL is not a "learning" library. It's very full featured and you can make extremely high end graphics with it.

Further, DirectX is a proprietary set of libraries for Windows, so no, Apple and Google are not going to move to it. It would definitely be worth your time to learn it, I believe.

Edit: Also, DirectX and XNA are not the same thing. DirectX is a collection of multimedia libraries, one of which is Direct3D (which is what almost everyone refers to when they say DirectX). Direct3D is a low-level API that allows you to leverage GPU hardware for 3D rendering, generally providing you with a rendering pipeline and the ability to control it. XNA is a .NET library that is designed to provide a higher level API for game development. It provides functionality in addition to graphics rendering, and is designed to be used with managed code. The performance of XNA, while quite good, is unlikely to match the performance of DirectX + C++.

They differ quite a bit in design philosophy. One of the prime goals of XNA is to eliminate a lot of the boilerplate code that is involved in making games, while DirectX promises no such thing.

Share this post


Link to post
Share on other sites
crosstantine    102
Thanks for your fast reply PropheticEdge, I realized that OpenGL is not a learning library as it's very powerful and complex for a none skilled developer, but I labeled as "learning" because as far as I can see most of the people use it to do some experiments and small games, but when the people comes to the big games they changed to DirectX, I'm trying to wonder why is that, as far as I can read OpenGL is easier to learn than directx because it abstracts the hardware interaction and with DirectX you need to handle a lot of things that OpenGL does for you,

From my gamer experience I found that OpenGL is far slower than DirectX but I blame the dedication that developers tend to give to DirectX because it's the higher seller, and OpenGL is for some geeks that play on weird platforms like linux (I'm this kind of geek that's why I started with OpenGL).

Sorry I now realized that I expressed my point wrong, XNA and DirectX are not the same thing, but are propietary and not multiplatform also it's one of the Microsoft's tentacles.

PropheticEdge, if someone ask you to create a new game will you take DirectX or OpenGL for that? in either case why will you choose that one over the other, I know it could be a tricky and long answer but I'm trying to understand why, if OpenGL is that good and offers multiplarform, most of developers goes to a complicated-propietary API.

Share this post


Link to post
Share on other sites
PropheticEdge    150
[quote name='Crosstantine' timestamp='1302910405' post='4798966']
Thanks for your fast reply PropheticEdge, I realized that OpenGL is not a learning library as it's very powerful and complex for a none skilled developer, but I labeled as "learning" because as far as I can see most of the people use it to do some experiments and small games, but when the people comes to the big games they changed to DirectX, I'm trying to wonder why is that, as far as I can read OpenGL is easier to learn than directx because it abstracts the hardware interaction and with DirectX you need to handle a lot of things that OpenGL does for you,

From my gamer experience I found that OpenGL is far slower than DirectX but I blame the dedication that developers tend to give to DirectX because it's the higher seller, and OpenGL is for some geeks that play on weird platforms like linux (I'm this kind of geek that's why I started with OpenGL).

Sorry I now realized that I expressed my point wrong, XNA and DirectX are not the same thing, but are propietary and not multiplatform also it's one of the Microsoft's tentacles.

PropheticEdge, if someone ask you to create a new game will you take DirectX or OpenGL for that? in either case why will you choose that one over the other, I know it could be a tricky and long answer but I'm trying to understand why, if OpenGL is that good and offers multiplarform, most of developers goes to a complicated-propietary API.
[/quote]

I would use DirectX simply because it's what I know better (I'm not great with DirectX to be honest, but I'm worse with OpenGL).

Honestly? I think the reason people use DirectX is because other people use DirectX. It's just really commonly known and used, so people learn it since it's the most common thing. Performance differences aren't really tied into the API itself, I don't believe, but the implementation of the graphics hardware itself and its drivers. Direct3D tends to have more robust driver support, but I think for all practical purposes you will not be hamstringed by using OpenGL and can do basically anything that DirectX can do.

It sounds to me like you want to use OpenGL, but are afraid to because you believe it will be useless. It won't be. Go ahead and learn it if you like the way the API works or want cross-platform support.

Still, I'd suggest you wait until someone else pipes up on the boards. I'm just one dude and really not the most qualified to answer these questions.

Share this post


Link to post
Share on other sites
According to Wolfire Games, DirectX has a lot of propaganda tied to it and that's why people think it's what you need for serious games. I don't know much about it myself, but i found their arguments to be persuasive and you can read them here: [url="http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX"]http://blog.wolfire....and-not-DirectX[/url]

id Software is probably most notable for their use of OpenGL and for being an "early pioneer in the Linux gaming market" according to their wiki article. At one point John Carmack wrote a [url="http://rmitz.org/carmack.on.opengl.html"]lengthy article/rant[/url] about why he preferred OpenGL. Doom 3, a very serious game, is offered on Linux, presumably thanks to GL. Googling "Carmack directX" today brings up a bunch of articles on why he currently ("finally", according to them) prefers DirectX.

I would say OpenGL is worth learning because the API is really clean. In contrast, DX, or Windows code in general, feels bulky, abrasive, and uninspired. I won't defend that--it's just opinion. Knowing both DX and GL would probably be best so that one could be prepared for anything on any platform.

Share this post


Link to post
Share on other sites
Direct3D used to have much better support than OpenGL back in the day, so it was much easier to find good Direct3D drivers than good OpenGL drivers. That's why so many games used Direct3D. Now that situation is much better, though for some things OpenGL drivers are still rough. In any case, that's still mostly inertia these days.

Also, yes, Direct3D in DX9 and earlier was horrible in comparison to OpenGL in terms of ease of use (there were lots of things Direct3D didn't do that it should have done... context losses were the main reason several games wouldn't support alt+tab while in fullscreen actually). That got better though, so they're pretty much at the same level. I still like OpenGL more though =|

Also, if you plan to work outside Microsoft platforms, then Direct3D won't take you far... if at all, really. So as soon as you move onto a non-Microsoft platform you have to go with OpenGL or similar (e.g. OpenGL ES for mobile devices).

Share this post


Link to post
Share on other sites
crosstantine    102
Thanks for sharing your knowledge with me, basically that's what I thought, OpenGL worth the try and I will start with it, actually I'm using SDL which will bring a little bit of abstraction over OpenGL (and it will use the DirectX advantages in windows, or that's what I understood from some posts I read about SDL), that way I can start my developments faster and with less pain :D.

Eventually I will need to use OpenGL directly and start to try DirectX if I want to be a game deverloper that could manage to stay in business.

Share this post


Link to post
Share on other sites
kdmiller3    178
SDL is definitely a good start, as many all of the OpenGL tutorials I've run across on the Internet use it.

If you prefer a C++ equivalent, [url="http://www.sfml-dev.org/"]SFML[/url] is also a good option. It doesn't have the vast install base of SDL, but it's entirely hardware-accelerated (like SDL 1.3 will be).

When you're ready to take on OpenGL directly and want something small and lightweight to set up your context, I suggest [url="http://www.glfw.org/"]GLFW[/url] (plus [url="http://www.un4seen.com/bass.html"]BASS[/url] or [url="http://connect.creativelabs.com/openal/default.aspx"]OpenAL[/url] for sound). It offers similar functionality to [url="http://www.opengl.org/resources/libraries/glut/"]GLUT[/url] or [url="http://freeglut.sourceforge.net/"]freeglut[/url] but gives you more control over your main loop. (GLUT and friends tend to implement the main loop themselves.)

Also, to answer the original question: I think OpenGL is a good way to learn graphics programming since there are many helpful tutorials out there. Earlier versions of OpenGL (1.x and 2.x) are very easy to learn since they take care of a lot of things for you, though you wouldn't want to make a commercial game with those. Once you're comfortable with the basics, you can move on to more advanced techniques and later versions of OpenGL (3.x and 4.x). Since later versions of OpenGL and Direct3D act as relatively thin layers over the low-level graphics subsystem, they tend to work in relatively similar ways so learning one will let you pick up the other fairly quickly. It can't hurt to know both. :)

Share this post


Link to post
Share on other sites
crosstantine    102
:o that really hit something important, didn't know that SDL is not hardware accelerated, I read that SDL 1.3 will use DirectX under the hood to get advantange of the hardware acceleration provided by DirectX but I thought they were talking about using the drivers provided to DirectX (which seems to be better than the OpenGL's) but did not realize that SDL 1.2 was not hardware accelerated, why is that? OpenGL is hardware accelerated too right?

Share this post


Link to post
Share on other sites
kdmiller3    178
To answer the [i]original[/i] original question ("Is it worthless to learn OpenGL if you will end up with DirectX anyway?"): no, it's not. While PC games use DirectX almost exclusively, many platforms use OpenGL in some form (e.g. OpenGL ES on mobile devices). If you're genuinely interested in graphics programming, learn [i]both[/i] APIs. While you may prefer one or the other for your own projects, knowing both will give you more options when it comes to your career.

Share this post


Link to post
Share on other sites
kdmiller3    178
[quote name='Crosstantine' timestamp='1303143161' post='4799950']OpenGL is hardware accelerated too right?[/quote]
While it has a pure-software implementation, OpenGL is almost by definition hardware-accelerated. :)
(Substitute "Direct3D" for "OpenGL" in your question and the answer is the same.)

Share this post


Link to post
Share on other sites
mhagain    13430
My opinion, from the perspective of having converted to D3D from OpenGL.

Ignore John Carmack's infamous rant for starters; it's 15-odd years out of date, refers to DirectX 3, and it was only a year later that he was saying "Direct3D with DrawPrimitive doesn't suck". It's completely irrelevant to any discussion in other words. By all means read it as a historical curiosity, but if you want to get any meaningful info just ignore it otherwise.

OpenGL isn't open source. A lot of people seem to make this mistake (not sure if the OP is heading in that direction); it's not open source, it's an open standard.

Portability. In any non-trivial project the 3D API-specific portion of your code is going to be quite small. You also have decisions to make regarding networking, input, sound, window management, possibly even file IO, etc. Many people when discussing portability say something along the lines of "with OpenGL I can support <long list of platforms>". Oh no you can't. The PS3 doesn't use OpenGL natively, it [i]can [/i]use OpenGL through an emulation layer but you get maybe 10% performance; for anything decent you need to use it's native API. Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast (very D3D-like in concept and execution actually). Factor in driver quality (which can be quite appalling) and OpenGL's portability advantage doesn't look so hot anymore.

OpenGL is defined as a specification which hardware vendors then implement in their drivers. A lot of this spec actually dates back to the mesozoic era, and covers features that may have been hardware-accelerated on SGI workstations (or that the original writers thought should be added for completeness or correctness sake). Trouble is that in order to be called "OpenGL" an implementation must continue to support these features - through software emulation if necessary. More recent versions of OpenGL have been gradually doing away with this by marking certain features as deprecated, and not exposing them in a "core context".

D3D is more tightly coupled to the hardware. If a feature or format isn't available in hardware D3D just won't expose it. In that sense it's more predictable; if you write D3D9 code for D3D9-class hardware you can have a greater certainty that it will work right on a broader range of hardware. The driver model is simpler too, but comes with some traps that can catch you out (like the infamous D3DERR_DEVICELOST on versions 9 and earlier). Older versions used to look like they were designed by a team of monkeys on LSD; there are still some parts of newer versions that look that way. When it doesn't work it can sometimes fail to do so in style, locking up your machine or resetting your display adapter. D3D's tools are more comprehensive than OpenGL's (PIX, debug runtimes, etc).

Modern versions of both APIs look more similar than different. There's a more or less one-to-one direct mapping between large chunks of them. Modern, well written and highly performing OpenGL code will use exactly the same rendering techniques that D3D has almost always required. This can steepen the learning curve a little as you now need to start planning out stuff like your vertex buffer strategy before you can start drawing anything; no more jumping in and bashing out a few lines of code to get that first triangle on screen.

Share this post


Link to post
Share on other sites
issch    479
[quote name='Crosstantine' timestamp='1303143161' post='4799950']
:o that really hit something important, didn't know that SDL is not hardware accelerated, I read that SDL 1.3 will use DirectX under the hood to get advantange of the hardware acceleration provided by DirectX but I thought they were talking about using the drivers provided to DirectX (which seems to be better than the OpenGL's) but did not realize that SDL 1.2 was not hardware accelerated, why is that? OpenGL is hardware accelerated too right?
[/quote]
SDL 1.2 has some primitive hardware acceleration for drawing images, which used DirectX as a backend, afaik.

SDL 1.3 is built on top of OpenGL giving you a fully hardware accelerated 2D drawing API (if you want to do 3D, you will have to use OpenGL yourself to do the graphics, but you can still use SDL for everything else: setting up windows, input, threads, timing, etc). SDL 1.3 also has a much richer drawing API than 1.2 did.

Share this post


Link to post
Share on other sites
Yann L    1802
[quote name='mhagain' timestamp='1303149641' post='4799991']
Portability. In any non-trivial project the 3D API-specific portion of your code is going to be quite small.
[/quote]
Don't underestimate this. Porting an advanced production-class D3D engine to OpenGL, or vice-versa, can be a very time consuming and cost intensive task. If an engine is scheduled for porting to another platform at some point in the future, then this should definitely be taken into account when creating its initial design. Doing so after the fact can be very expensive. In other words, if you plan to port to Mac or to embedded/mobile, don't use D3D. If you plan to port to XBox, don't use OpenGL. PS3 (ie. RSX) is a thing apart.

[quote name='mhagain' timestamp='1303149641' post='4799991']
Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast
[/quote]
This is incorrect. Each ES version was always based on a certain OpenGL version. The 4.1 standard specifically mandates full inter-compatibility between ES and OpenGL.

[quote name='mhagain' timestamp='1303149641' post='4799991']
Factor in driver quality (which can be quite appalling) and OpenGL's portability advantage doesn't look so hot anymore.
[/quote]
We recently ported (read: were forced to port) a large 3D application from Windows to OSX. The fact that the original engine was written for OpenGL saved us a tremendous amount of work and money (Win32 to Cocoa was a whole different story though). In fact, OpenGLs portability is one of its primary advantages. As long as we are talking advanced 3D (ie. Intel is out of the picture), then driver quality is not an issue anymore.

[quote name='mhagain' timestamp='1303149641' post='4799991']
D3D is more tightly coupled to the hardware.
[/quote]
Neither OpenGL nor D3D is tightly coupled to the hardware. You'd be surprised how far the low level of modern GPUs is removed from what either of these APIs expose.

Share this post


Link to post
Share on other sites
mhagain    13430
[quote name='Yann L' timestamp='1303157296' post='4800046']
[quote name='mhagain' timestamp='1303149641' post='4799991']
Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast
[/quote]
This is incorrect. Each ES version was always based on a certain OpenGL version. The 4.1 standard specifically mandates full inter-compatibility between ES and OpenGL.
[/quote]

My point here is that historically ES has always been a subset of full OpenGL. Use any full OpenGL features that are not supported in the ES version you're targetting and you're in rewrite-land. The extent to which you're in rewrite-land varies of course, but in a worst case scenario you may be rewriting your entire rendering backend to go from immediate mode to vertex arrays/vbos. If that's changed in more recent versions then it's a good positive step forward, but for older versions it's certainly not full portability. Portability isn't something that you magically conjure just by using OpenGL - you still have to work for it.

Share this post


Link to post
Share on other sites
Yann L    1802
[quote name='mhagain' timestamp='1303161450' post='4800066']
My point here is that historically ES has always been a subset of full OpenGL. Use any full OpenGL features that are not supported in the ES version you're targetting and you're in rewrite-land. The extent to which you're in rewrite-land varies of course, but in a worst case scenario you may be rewriting your entire rendering backend to go from immediate mode to vertex arrays/vbos. If that's changed in more recent versions then it's a good positive step forward, but for older versions it's certainly not full portability. Portability isn't something that you magically conjure just by using OpenGL - you still have to work for it.
[/quote]
And the main point of interest there is the term historical. We're talking about writing a new engine here, in 2011. Or heck, let's even go back a few years. We are not talking about obsolete 15 year old legacy code bases. If your backend is relying on immediate mode, then ES portability is going to be the least of your worries. Vertex arrays have been available for 16 years in OpenGL (yes, 16 years !). To put that in perspective, that was around the time DirectX 2.0 was released. VBOs have been available since 2005, give it a year more for universal driver adoption. The FFP was officially deprecated since OpenGL 3. Portability is a non-issue nowadays. If a developer uses legacy features that may hinder portability, then this is by choice, not by necessity.

D3D10/11 forces this choice, which may indeed be an advantage, as it helps to not propagate obsolete techniques.

[quote name='Kurasu1415' timestamp='1303160171' post='4800063']
Playstation, nintendo, Android, Apple, Linux. Have you ever heard of these? All of these use OpenGL as opposed to Direct x.
[/quote]
Neither Playstation nor Nintendo consoles use OpenGL. They use their own proprietary low level APIs.

Share this post


Link to post
Share on other sites
tom_mai78101    693
[quote name='Yann L' timestamp='1303165479' post='4800085']
[quote name='Kurasu1415' timestamp='1303160171' post='4800063']
Playstation, nintendo, Android, Apple, Linux. Have you ever heard of these? All of these use OpenGL as opposed to Direct x.
[/quote]
Neither Playstation nor Nintendo consoles use OpenGL. [b][u]They use their own proprietary low level APIs.
[/u][/b][/quote]

Oh wha...!!?!? :( This is a sign of a man with a bad developing path in life.

Share this post


Link to post
Share on other sites
crosstantine    102
As usual, thanks for all your opinions around this subject, I've been educating myself in order to understand some of the advices, now that I read a little bit I got some of your points, As I said before I will start with OpenGL mainly because I'm targeting my 2nd game to android and/or iphone, and both use OpenGL as core graphics API,

It's a little bit overwhelming that most of the tutorials I found are very old... 2005 or older, and most of the tutorials I found about OpenGL ES are written from people who read someone else tutorials and made a new one... with a LOT of mistakes and misleadings, I also looked around and found a lot of books with the same copycat techniques... the documentation found at OpenGL.org is a little bit cryptic and not newbie friendly,

The other thing that was "funny" (lack of a better term) is that the OpenGL ES samples does not run within the emulator provided with Android SDK, after several hours of changing the code and putting some debug messages (and loosing some hairs) I found a forum which claims that emulator does not support OpenGL ES... what a mess... how can I create a game that I need to deploy at my phone every time I need a test? is there a way to create an API abstraction layer to run code in OpenGL at desktop and then port it to OpenGL ES without rewriting all the code again?

Do you have a GOOD tutorial, a proven tutorial that has a NEHE like experience but with a newer versions of OpenGL?

Thanks for your support.

Share this post


Link to post
Share on other sites
mhagain    13430
This page is something of a goldmine when it comes to dealing with OpenGL tutorials: http://www.opengl.org/wiki/Common_Mistakes (yes, even the NeHe tutorials are guilty of many of the mistakes here). By all means follow a tutorial, but keep that to hand a reference for correcting things as you go.

For modern OpenGL it doesn't get much better than this: http://www.arcsynthesis.org/gltut/

Share this post


Link to post
Share on other sites
crosstantine    102
thanks for the links, they're priceless, the common mistakes is really a very nice link to have in my bookmarks :D I think it will save me tons of hours trying to figure out what I did wrong (mainly when you check a tutorial and everything is exactly as the tutorial but you still get the error).

Share this post


Link to post
Share on other sites
NightCreature83    5006
[quote name='Crosstantine' timestamp='1307481622' post='4820695']
As usual, thanks for all your opinions around this subject, I've been educating myself in order to understand some of the advices, now that I read a little bit I got some of your points, As I said before I will start with OpenGL mainly because I'm targeting my 2nd game to android and/or iphone, and both use OpenGL as core graphics API,

It's a little bit overwhelming that most of the tutorials I found are very old... 2005 or older, and most of the tutorials I found about OpenGL ES are written from people who read someone else tutorials and made a new one... with a LOT of mistakes and misleadings, I also looked around and found a lot of books with the same copycat techniques... the documentation found at OpenGL.org is a little bit cryptic and not newbie friendly,

The other thing that was "funny" (lack of a better term) is that the OpenGL ES samples does not run within the emulator provided with Android SDK, after several hours of changing the code and putting some debug messages (and loosing some hairs) I found a forum which claims that emulator does not support OpenGL ES... what a mess... how can I create a game that I need to deploy at my phone every time I need a test? is there a way to create an API abstraction layer to run code in OpenGL at desktop and then port it to OpenGL ES without rewriting all the code again?

Do you have a GOOD tutorial, a proven tutorial that has a NEHE like experience but with a newer versions of OpenGL?

Thanks for your support.
[/quote]
The D3D documentation can be equally cryptic in certain situations and if you pick D3D skip everything before D3D11, if you need to target older hardware(D3D9 and up) use the feature levels in the D3D11 API this will allow you to write you D3D stuff more transparently. The graphics stuff in XNA is D3D9 based but models the D3D11 level closely as in immutable rasterisation state classes and certain other things.

The fact most games support D3D is historical as state before and pre 2005 OpenGL was lacking features that D3D9 did implement and thus most developers switched to this API, nowadays most stuff is done in shaders and HLSL and GLSL offer the same capabilities. If you wish to write shaders that are supported by both OpenGL and D3D use Nvidia's CG language it has backend hooks that make it work on both, side note HLSL and CG are more or less the same language.


Seeing that most stuff now is done in shaders you benefit far more from learning how blending operations work as you need to be able to express them in shader code in most cases.

Share this post


Link to post
Share on other sites
mhagain    13430
I wouldn't quite say "skip everything before D3D11". If you need to target Windows XP then D3D9 is still be best choice, and is a surprisingly clean and elegant API with just a few (but very few) places that make you go "WTF!" Compared to the contemporaneous OpenGL versions (2.0, 2.1) it's definitely much easier to use, more sensibly structured, and needs significantly less lines of code (compare SetVertexDeclaration with the mess of glEnableClientState/gl*Pointer calls, although the VAO extension - if available (which it may not always be at this target level) - balances things off). D3D10 is defintely one to skip though, and if needing to target XP isn't a consideration then going straight to 11 makes sense.

All assuming that one is targetting Windows only, of course.

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