Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

If I write a game engine that uses OpenGL 1.5 (not assuming what else I do), is it portable now and is it still portable five years from now or are/will support for OpenGL by hardware and drivers (be) exclusive to their (much more farther along) target OpenGL versions?

Lately I've been looking at a lot of answers on this website that direct users to divert their work towards the most recent OpenGL versions, citing hardware surveys of DirectX support and only recommending earlier versions as a last, final resort (as if to imply there is something wrong with them that makes all usage of them invalid or pointless).

If I only have computers that can provide OpenGL <=1.5 or <=2.1 contexts should I just give up game programming if I can't afford a new computer with hardware and drivers for 3.x and 4.x? Or should I finish my game engine the way I intended to?

Will by the time I get a 4.x supporting setup will there be new versions and a lack of backwards compatibility that trash all usage of 4.x? Will 4.x ever dominate over earlier versions support wise before a new major version is realized and released?

share|improve this question
1  
Can you really not create an OpenGL 3.1 context? This would (imo) be best as you'll start working with new best practices instead of the old crud and OpenGL 3.1 uses a 'forward compatible context'. –  Roy T. Jul 14 at 20:23
    
-1; OP: if you require somebody to tell you what "will" happen, I think you're demanding the obviously impossible. –  vaxquis Jul 14 at 21:20
    
@vaxquis It's hardly unreasonable to think that somebody might know about statements from the Khronos Group on the subject, or that there may be similar past trends which could give some insight into things. There's a very wide spectrum between prognostication and total ignorance. –  Chris Hayes Jul 15 at 2:37
    
@ChrisHayes Khronos group is well known from being unpredictable, both with ARB matters and mainstream API changes. Read about Longs Peak controversy and ARB criticism if you don't believe me. Also, past trends in no way allow to predict the future - while the software development in itself is stochastic, being stochastic in no way means "predictable". –  vaxquis Jul 15 at 10:07
1  
@ChrisHayes since you either don't know or understand the behaviour of neither SGI, ARB nor Khronos (and neither do I, as a matter of fact), unless you're a member one of the said consortiums, your opinion would be purely speculative and lacking any informational value. Yes, people use past trends to predict the future all the time - and they fail. Learn how many times the "OpenGL seers" have already failed before calling something "ludicrous". Since you have proven neither understanding or sensible (if any) opinion of the discussed matter, I don't know how I should respond to your rant. –  vaxquis Jul 16 at 0:32

3 Answers 3

OpenGL 1.x is not likely going to disappear on PCs. A great number of luminaries in the GL community consider the explicit compatibility mode and deprecated features of GL 3.1 to be a mistake. The last time GL was scheduled for a massive break in compatibility, Khronos backed out and delivered an incremental update.

While nobody can see the future, it's very likely that your GL 1.x code will continue working on PCs for some time to come.

Portability problems will arise only if you want to target a platform that doesn't support GL at all, like mobile devices (which use GL|ES, so it's very similar at least) and most consoles (you can get a GL-like API on Sony's consoles, but it's still going to require porting work to support).

concept3d's answer is very right in that you really should abstract your use of the graphics API. Write a thin bit of code that wraps GL textures in your own Texture objects and so on. Then you can later write GL 1.x versions, GL 5.x versions, Direct3D versions, whatever.

share|improve this answer
    
+1 for "nobody can see the future" - that's the main problem with OPs question - he asks us to do some auguring work... –  vaxquis Jul 14 at 21:19

The short answer, OpenGL really changes after version 3.1, that being said don't use OpenGL function calls directly, but actually build a small wrapper around it. One way to do it is to make a class that is responsible for all openGL calls, this can be replaced once you want to upgrade to newer versions. You can for example have a Texture resource class that doesn't rely on OpenGL, the mapping happens in the wrapper class this is what Horde3D does.

On the other hand Ogre3D takes a more complicated approach, instead of implementing a single hardware layer class they provide basic abstract classes for any hardware API (DirectX, OpenGL, OpenGL ES etc) each hardware layer is implemented by overriding this interface, this way you can have multiple API support with a more object oriented (but more complicated approach).

Otherwise if your engine directly use OpenGL calls then you probably need to rewrite a lot of the functions to support newer versions. If you're a beginner and this one of your first projects, my main concern won't be about portability/re-usability but actually about how to make the engine, you will mostly figure out that there are better ways of doing it after your first time.

share|improve this answer
1  
I think the wrapper approach, while in some cases worth-while is a bad fit for something as complicated as a graphics API. Building an application on OpenGL implies one way of approach to problems. Porting yo another graphics library by adapting the wrapper is often impossible since the other API will require quite different information which cannot easily be mapped from the old version. Of course there are engines that do this but they abstract quite far away from the underlying graphics API. Also OpenGL is stable, it is unlikely that it will just disappear. –  Roy T. Jul 14 at 20:21
    
@RoyT. Do you imply that we should directly use the function calls? I agree it's tricky to wrap for all APIs and you will probably want to leak at some point, but I find this much better than calling API function directly in your program. What are the alternatives ? –  concept3d Jul 14 at 20:42
    
If the API is stable and in the proper language, then yes. Why add the extra indirection? (Of course wrappers have their uses, but in this specific case it seems unnecessary) –  Roy T. Jul 14 at 21:22
    
@RoyT. That is what I suggested in my last section. Which I think we agree on this point , but in case the op needs to change the API, he/she may need to consider the wrapper approach. –  concept3d Jul 14 at 21:51

If I write a game engine that uses OpenGL 1.5 (not assuming what else I do), is it portable now and is it still portable five years from now or are/will support for OpenGL by hardware and drivers (be) exclusive to their (much more farther along) target OpenGL versions?

Currently, all of the features provided by any OpenGL version x <= 3.0 are explicitly supported by all versions y such as x <= y <= 3.0, and they (old features) can be enabled in versions >= 3.0 by creating compatibility context and accessing those features through the context.

For example, OpenGL 3.0 includes essentially every feature provided by previous OpenGL versions (some being marked as deprecated) - but you can request OpenGL 1.5 compatibility context from a GPU driver supporting e.g. OpenGL 4.0 natively and use those features (fixed-function pipeline comes to mind).

Also, all the major software vendors (AMD/ATI, nVidia, Intel) provide support to legacy OpenGL features in their newest drivers, though the efficiency is often very low, as they are currently unimplemented in hardware, so software emulation is used instead (nb those drivers quite often use code from Mesa project AFAIR); selection mode, old-style (pre-shader) lighting, automagic mipmap generation, display lists and similar features can be considered as such "potentially unsafe" features (though some of them are still quite fast in some cases, as with display lists for example).

tl;dr - yes, it's portable, and probably will be portable, unless driver vendors suddenly feel the urge to cut the connection with the past (not likely, until now it hasn't happened in case of OpenGL) or some new technology makes old features incompatible (likely, but not in the nearest future). A good example is x86 line - until x86-64, it was almost completely backwards-compatible; with introduction of x86-64, the compatibility was broken and some old apps just wouldn't run anymore.

Lately I've been looking at a lot of answers on this website that direct users to divert their work towards the most recent OpenGL versions, citing hardware surveys of DirectX support and only recommending earlier versions as a last, final resort (as if to imply there is something wrong with them that makes all usage of them invalid or pointless).

I'd say that, if you're using shaders (OpenGL >= 3.0, core profile), the difference is actually only minuscule (new features, allowing better gfx quality). The main difference is between fixed-function pipeline and using shaders - because the gap is huge and old code is basically not portable to the new architecture. DirectX is a different beast - you need to install DirectX 9 even if you have DirectX 11 just to use DirectX 9 features (e.g. Direct3D 9) - it makes complete sense to just skip to new DirectX version to avoid the trouble, both for yourself and the application user.

As far as OpenGL goes - if you want your code runnable on pre-shader GPUs, use e.g. OpenGL 2.1 - it's almost 10 years old already, so basically everything supports it. There isn't anything wrong with that, it's just that you won't be able to extend your code to use shaders etc. without much effort (unless your app is already using vertex memory buffers, i.e. vertex arrays - then it's much easier to port).

tl;dr - no, there's nothing wrong with using old OpenGL versions, as long as you're aware that the limitations of pre-3.0 versions can be severe (no "plug-n-play cool water effects" etc).

If I only have computers that can provide OpenGL <=1.5 or <=2.1 contexts should I just give up game programming if I can't afford a new computer with hardware and drivers for 3.x and 4.x? Or should I finish my game engine the way I intended to?

Give up programming? If you're already more than 50% into it - certainly not. Otherwise, I'd reconsider. Anyway, it'd be good for to to avoid all immediate mode calls and move to glDrawArrays etc, since it is essentially nr 1 of what is needed to shade a geometry - storing the data in a vertex array.

Will by the time I get a 4.x supporting setup will there be new versions and a lack of backwards compatibility that trash all usage of 4.x? Will 4.x ever dominate over earlier versions support wise before a new major version is realized and released?

Nobody can tell that for sure. As already stated above, it's quite unlikely, since backward-compatibility has been largely maintained until now, and, in the worst-case scenario, you can always use a software renderer for old applications -

As a side note: there has been 3D technologies/choices that was expected to thrive (IRIS GL, OpenGL++, DirectX/OpenGL fusion (Fahrenheit project), Glide, GLU, 3dfx GPUs, ARB being the only OpenGL governing body, hardware T&L [it got obsoleted/incorporated into shading model]), while some were expected to fail (DirectX first, due to lack of game/application vendor support, being not portabile to non-Windows systems and existence of Glide, OpenGL then due to... lack of game/application vendor support, being not portable to Windows systems [see Windows 2000/Vista problems with OpenGL! making OpenGL API a redirect to Direct3D calls didn't help, either...], Longs Peak controversy, being governed by ARB and existence of Direct3D [see the pattern?], texture compression was expected to be obsoleted due to increasing memory sizes [it's still used commonly, because texture sizes grow faster than memory sizes], ATI GPUs were considered obsolete by some and expected to die out the same way 3dfx did [but then, suddenly, AMD gave them a hand]) etc etc etc

Also, as far as the very OpenGL API goes (esp. at the times of the all-powerful ARB), there were numerous vendor extensions that have been expected to be incorporated into mainstream API - and they either hadn't been for a long time or not at all, and there were some that appeared with no apparent reason, were seldom used and quickly forgotten - yet nobody exactly knew - why? ...

None of those "prophecies" came true, although some people would literally kill other just to prove they're right about them. Some delusional individuals still spread the FUD around, saying "this technology will die!" and/or "that technology will thrive!" - but that's just that, speculations and opinions.

tl;dr - you can't predict future. Don't ask speculative questions about the future - nobody can answer a question about the future of technology with much certainty; if it was possible, well, the world would be a different place now (we'd probably still have like 10 computers in the world per IBM prophecy, and we'd not even use phones, as they were considered "a mere fad" in the Bell's days...). You can only speculate - and science shouldn't be based on speculation. Don't choose your technology back/front-end based on speculation. Either use old stuff for compatibility, or new stuff for possibilities - you can't have both at the same time. Either stick with what you know and what you can do already, because it allows you to do what you want already, or go forward to learn new stuff, to be able to achieve more.

Source: Wikipedia, google, internet, opengl.com, own experience.

Also, related: OpenGL: What are the adoption rates of the various versions (And what's a reasonable version to use)

share|improve this answer

Your Answer

 
discard

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.