Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm familiar with OpenGL 1.x. I typically use SDL with OpenGL 1.4 on Linux, and I've never run into problems, even on my modern system.

I've read on the OpenGL site about deprecation and compatibility contexts, but I'm still unclear as to whether it's safe to continue to use old versions of OpenGL, as opposed to using old features in newer versions.

When functionality is marked deprecated ... future versions of OpenGL may remove it.

Does deprecation simply imply that those functions can't be used alongside newer features?

More specifically, are there any systems today (other than embedded) where OpenGL 1.x isn't available? The old-skool stuff like, glBegin, glEnd, glDrawPixels, etc.

Note: I'm not a professional games developer, so you'll have to excuse my ignorance. I'm working on a mostly 2D game that I would like to keep multi-platform, supporting at least Linux, Mac, and Windows.

share|improve this question
up vote 7 down vote accepted

First of all you need to establish the split between desktop GL and mobile GL. Mobile GL (OpenGL ES) is in fact quite a different animal; it has a separate specification, different levels of functionality, different versioning, and can better be viewed as a separate API that is modelled after desktop GL, shares similar naming, but is just not the same thing. That's going to have implications for your plans to go multiplatform beyond the "big 3" in the desktop space.

For the purposes of discussing deprecation in desktop GL, OpenGL ES is irrelevant.

In desktop GL deprecation is complex and not fully implemented (if at all) by any GPU vendor. NVIDIA have publicly stated that they have no intention of removing anything at all.

In summary though, the deprecation model is chosen at context creation time and essentially boils down to one of two choices: a "core context" (i.e. one with all of the deprecated functionality removed) or some other form of context that still implements the deprecated functionality.

If you want a core context you must explicitly ask for one, otherwise you still get all of the old stuff. I believe that OSX is however different here and will only give you a core context, but don't quote me on that (edit - confirmed; see comment below).

The older (deprecated) functionality may or may not coexist cleanly with newer GL functionality; in some cases it makes absolutely no sense whatsoever (VAOs with glBegin/glEnd calls are nonsensical; that should be obvious to all), in some cases it just won't work (a modern shader requires generic attribs but you can't provide them unless you use the generic attrib calls), in others it just continues to work fine.

What all of that means is that if you want to mix-and-match functionality you need to get down and start reading the documentation, figure what works and what doesn't, and make decisions about what you can keep and what you need to change. That's if you want to mix-and-match; if not, then you can just continue as you are and everything should still work.

Fortunately there are some easy migration paths available. You can for example use glVertexAttrib3f instead of glVertex3f (and friends) and begin using generic attribs in modern shaders right now, while retaining your old glBegin/glEnd style code. From the other side, you can migrate your glBegin/glEnd code to vertex arrays (glVertexPointer and friends) without having to cope with the additional upset of also needing to implement shaders and generic attribs all at once.

In other words making the move can be quite a pain-free experience since you only need to change one thing at a time (and have only one place to go looking for problems if you break anything).

OK, so I've digressed a little from the specific question in the last part there, but I believe that it's relevant given your cross-platform ambitions and given the more limited functionality provided by OpenGL ES.

share|improve this answer
Thanks, that helps a lot. In my case, it should be quite easy to migrate since I have an abstraction layer above all the OpenGL-specific code. On the note of Apple, you guys are saying that there's no OGL1.4 on OSX? – QuasarDonkey Oct 5 '12 at 16:19
"on MacOSX, you can't get a compatibility profile" - thanks for confirming - post edited. – 21st Century Moose Oct 5 '12 at 18:26
It's true you can't get a compatibility profile on OSX, but you can still get a 2.1 context (which is fully compatible with 1.4 features AFAIK) if you ask for one. The absence of a compatibility profile just means you can't mix 2.1 and 3.0+ features, you have to choose. – Nax Apr 13 at 9:03

WebGL and embedded are both based on OpenGL 2 and don't support any of the immediate-mode or fixed-pipeline OpenGL 1.4 operations. So you can forget anything on mobile - those vendors are not likely to add obsolete OpenGL support.

On desktops, I doubt very much whether OGL 1.4 is going to disappear, but you should probably not use it for new work.

In general you will want to use a higher level library to do useful stuff, which will make the OpenGL 2 / OpenGL ES stuff essentially transparent, you won't notice it at all.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.