How can a program developed a version of OpenGL be made to work with lower versions as well?
For e.g. can program developed using open gl 3.0 also run on machine with driver for 2.0
For e.g. can program developed using open gl 3.0 also run on machine with driver for 2.0
Only if
[ul]
[li]the driver implementing OpenGL 2.0(or more likely 2.1) has already had a core feature which has not been removed from the 3.0 (actually 3.1+) specifications or [/li][li]provides extensions which have been backported to OpenGL 2.1, i.e. have been designed with 3.0+ in mind but work with GL2 capable hardware - however, you’d have to use the extension and not the 3.0 core feature to make it portable [/li][li]your application keeps to only using what’s still left of the GL2 era - which wouldn’t be a wise decision [/li][/ul]
I’d personally advise against trying to write a GL3 app with GL2 compatibility in mind. However, you can write a GL2 app which will work on GL3 hardware if the driver implements both specification flavors. Currently, at least AMD and NVIDIA provide full implementations of stone-age OpenGL and current GL in one driver.
What’s your use case? Please bear in mind that at some point, there will not be a recognizable amount of hardware left to support which doesn’t do GL3.
Quite easy. The simplest thing to do is query the OpenGl version once you have requested the context - use glGetString(GL_VERSION).
Let’s say for arguments sake you fully support GL 3.3 and GL returns 3.0, then you know that some features/function won’t be there; you code must check the GL version and take the appropriate code path. See OpenGL FAQ / 23 Extensions and Versions
The hardest bit is creating the correct context in the first place. You need to create a temporary context (Gl 2.1) and then check to see if you can create a GL 3.x context, otherwise fall back to the ‘temp’ context if you can’t. Cache all these results and then you app can take the correct action along the various rendering paths.
The way I read it, the thread starter seems to go for a write once run on any GL2/GL3 hardware approach. Otherwise I fully agree.
thanks for the reply. I will evaluate the approach of having multiple paths based on opengl version but I would certainly be more interested in solution / feasibility for ’ write once and read on any GL hardware approach’. I would also like to extend my question to include OpenGL ES.
I would also like to extend my question to include OpenGL ES.
In that case I guess there is no way around multiple code paths. Can you be more specific with what you try to do?
Or just write using GLES2 subset (with few gotchas).
My product is targeted for multiple platforms - desktop as well as hand held devices. I am targeting Intel I7, Atom, OMAP3730 processors. The graphic support for them vary. Intel I7 ones will support OpenGL 3.0 and beyond, Atom will support upto OpenGL 2.0 and OMAP3730 will support OpenGL ES 2.0. How can I write the code which will work on all these platforms? Is it feasible?
Is it feasible?
You tell us. 
If you’ve got the requirement to support all three(I assume you’ve got some clients demanding what you propose) then you’ll simply have to deal with it.
How can I write the code which will work on all these platforms?
You’ve got the option to
[ul]
[li]do it kyle_'s way and use only what’s supported by GLES2 - on all machines. This should work, since GLES2 is specified against desktop OpenGL 2.0 (IIRC)[/li][li]implement a renderpath for GLES2 and GL2 - the latter will be shared by all desktop machines, even if they are GL3 capable[/li][li]implement three different renderpaths for GLES2, GL2 and GL3 (core)[/li][li]implement some freaky codepaths using all kinds of extensions, even vendor specific ones - this is probably the least favorable[/li][/ul]
The 1st option is the safest route to have it all happen with a single code path but severly guts your possibilities on GL3 hardware and even in part on GL2 hardware. The 2nd option at least lets you use everything desktop GL2 has to offer for all desktop machines. The 3rd option has the benefit of being able to use as much core features as the underlying hardware permits - this would be my favorite, albeit a more work intensive one. The 4th option is out - period. 
Thanks for guidance.
The third option seems more appropriate. I want to take advantage of the underlying hardware to the best possible extent. But it does not appear to be as simple as ‘if … else’ . It can affect the way we design it. It will be helpful to see sample if someone has done it.
Also, I would like to know how to handle the case when there is no graphic hardware support available at all? How to ensure that application still runs without exiting? Are there any 3d software libraries which can do the rendering in software in absence of hardware? I read about such libraries in Android but not aware of windows platform.
Unity 3D supports everything and anything, so you should be able to do it as well.