OpenGL worth the try?

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.

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.

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.

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.

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.

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: http://blog.wolfire....and-not-DirectX

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 lengthy article/rant 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.

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

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,

Not really. OpenGL and D3D offers a similar level of abstraction. The reasons why D3D is preferred in current game development has several reasons, many of them historical and logistical. As a quick and dirty summary, until a couple of years ago, OpenGL used to be very badly managed. It was not clear where OpenGL would be heading, because as the committee-driven API it used to be, everybody was pulling into a different direction. DirectX, being under sole control of Microsoft, had a clear evolutionary path. This, coupled with the fact that some hardware vendors were unable or unwilling to deliver stable OpenGL drivers (Intel and ATI before it was acquired by AMD) pushed the industry towards D3D, which was (rightfully) perceived to be more 'stable' and reliable from a vendor support point of view.

Nowadays, things have cleared up. OpenGL management has been streamlined and future development of the API is much more transparent. Except for Intel, drivers are now as good and reliable as D3D drivers. Current OpenGL has feature parity with D3D11. So all in all, one could just as well use OpenGL for a modern AAA game. It's not yet widely done because of existing D3D code bases of course. But the emerging Mac game market might partially shift development back to OpenGL (especially if/when OSX Lion is finally going to support OpenGL 3.x)

Now, even before that, OpenGL was never a 'learning API'. It has always been, and still is, the most widely used API for industrial 3D, such as CAD/CAM, medical imaging, military applications, flight simulators, etc.

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

OpenGL code being slow is a sign of incorrect usage by the developer. Correctly written OpenGL code is just as fast as equivalent D3D code. The bottleneck is the hardware here. In fact, OpenGL is usually significantly faster than D3D9 (due to not doing the user space/kernel transitions D3D9 does). D3D10/11 have eliminated this bottleneck, making OpenGL and D3D pretty much identical performance wise.

Slow OpenGL code is probably using immediate mode, which is an 'easy' but completely obsolete (and deprecated) way of using the API.

XNA [...] Microsoft's tentacles.

DirectX and XNA are good frameworks, and so is OpenGL. You should choose your technology based on objective assessments of your requirements and your intended target audience. Don't let ideology trouble your objectivity.

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 .

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.

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, SFML 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 GLFW (plus BASS or OpenAL for sound). It offers similar functionality to GLUT or freeglut 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.

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?

To answer the original 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 both 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.

OpenGL is hardware accelerated too right?

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

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

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?

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.

Portability. In any non-trivial project the 3D API-specific portion of your code is going to be quite small.

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.

Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast

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.

Factor in driver quality (which can be quite appalling) and OpenGL's portability advantage doesn't look so hot anymore.

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.

D3D is more tightly coupled to the hardware.

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.

Playstation, nintendo, Android, Apple, Linux. Have you ever heard of these? All of these use OpenGL as opposed to Direct x.

[quote name='mhagain' timestamp='1303149641' post='4799991']
Mobile devices mostly don't use OpenGL, they use OpenGL ES which is a quite different beast

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.

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.

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.

Playstation, nintendo, Android, Apple, Linux. Have you ever heard of these? All of these use OpenGL as opposed to Direct x.

Neither Playstation nor Nintendo consoles use OpenGL. They use their own proprietary low level APIs.

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

Neither Playstation nor Nintendo consoles use OpenGL. They use their own proprietary low level APIs.
[/quote]

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

DirectX is designed only for Windows/Xbox
So if you plan to develop a cross-platform product, use anything else

Cheers