Status of OpenGL (ES) 2.0 on "PC"

Speaking of OpenGL ES development on workstations, does anyone have any actual
data on the status of OpenGL 2.0+ on Windows, Mac and/or Linux?

I’m currently relying on OpenGL 1.4 functionality, but would rather port
everything to OpenGL ES 2.0 and just use that on all platforms. Is there any
real reason to keep OpenGL 1.x support at all these days?–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

It’s possible to keep both, i do so with #defines. Generally the direction is to
move to 2.X+.
OpenGL 2.X is really a subset of 2/3/4 API. In my current project I support 1.X
and 2.X on ES and Desktop vairants of OpenGL. I have not had any major issues so
far with windows or linux as long as they support 2.X and higher. I dont know
about macos, i assume they would be mainstream as opengl is the api of choice.
In my case I still want to support some device that only had 1.X ES, which one
reason to keep 1.X API around.

You will need to write code to handle loading, compiling and choosing with
shader programs to run. Code to handle shader shared variables (uniforms,
attributes, etc). You will have to handle any transformations yourself.
Going through both fixed api is simple to use, shaders can give you more power
but take more handling to use.________________________________
From: david@olofson.net (David Olofson)
To: sdl at lists.libsdl.org
Sent: Wed, March 28, 2012 4:15:34 PM
Subject: [SDL] Status of OpenGL (ES) 2.0 on “PC”

Speaking of OpenGL ES development on workstations, does anyone have any actual
data on the status of OpenGL 2.0+ on Windows, Mac and/or Linux?

I’m currently relying on OpenGL 1.4 functionality, but would rather port
everything to OpenGL ES 2.0 and just use that on all platforms. Is there any
real reason to keep OpenGL 1.x support at all these days?


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It’s possible to keep both, i do so with #defines.

Well, that’s exactly what I want to avoid; any form of alternative code paths
to maintain. I need to work on actual features and content. :slight_smile:

Generally the direction is to move to 2.X+.
OpenGL 2.X is really a subset of 2/3/4 API. In my current project I support
1.X and 2.X on ES and Desktop vairants of OpenGL. I have not had any major
issues so far with windows or linux as long as they support 2.X and
higher. I dont know about macos, i assume they would be mainstream as
opengl is the api of choice. In my case I still want to support some
device that only had 1.X ES, which one reason to keep 1.X API around.

I suspect my final system requirements will still be way beyond any devices
with ES 1.x, so I’m not really concerned with those. What I want is PC, Mac,
Linux, Google NaCl and reasonably high powered Android and iOS devices.

You will need to write code to handle loading, compiling and choosing with
shader programs to run. Code to handle shader shared variables (uniforms,
attributes, etc). You will have to handle any transformations yourself.
Going through both fixed api is simple to use, shaders can give you more
power but take more handling to use.

Transforms are no big deal; in fact the 1.x style API is causing more problems
than it solves right now. And shaders is a most welcome feature.

Either way, I’m planing on moving all direct API access into a native code
engine with a partially persistent scene graph (to off-load the scripting
engine without porting lots of game specific rendering code to C), so details
don’t matter much. I just want to avoid maintaining multiple versions of code
that effectively do the same thing.

Thanks!On Wednesday 28 March 2012, at 22.32.27, Scott Smith wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Because Microsoft has never updated opengl32.dll since OpenGL 1.2, OpenGL 2.0 on Windows pretty much consists of dynamically fetching all the OpenGL functions you want via SDL_GL_GetProcAddress rather
than linking with -lopengl32, this is because of how the OpenGL ICD works - once you initialize a context, you get redirected to a real opengl dll provided by the GPU vendor, and all the OpenGL 2.0
(and often higher) functions exist in there without any EXT or ARB suffixes, so it’s just an init headache but past that it’s totally real.

Note that to check for an OpenGL 2.0 driver you should do some string parsing on glGetString(GL_VERSION) and compare to 2.0 or higher.

For OpenGL 3.0 and higher there is a context version you can demand via SDL_GL which would avoid the need for checking the GL_VERSION string, and in theory it delivers a different API behavior as well
(the OpenGL 3.0 Core Profile rather than Compatibility Profile), similar for 4.0, but even then you still need to use SDL_GL_GetProcAddress.

In general there are a number of platforms where SDL_GL_GetProcAddress is required for access to base functions, and a number of others where it isn’t available (OpenGL ES ones in particular).On 03/28/2012 02:46 PM, David Olofson wrote:

On Wednesday 28 March 2012, at 22.32.27, Scott Smith wrote:

It’s possible to keep both, i do so with #defines.

Well, that’s exactly what I want to avoid; any form of alternative code paths
to maintain. I need to work on actual features and content. :slight_smile:

Generally the direction is to move to 2.X+.
OpenGL 2.X is really a subset of 2/3/4 API. In my current project I support
1.X and 2.X on ES and Desktop vairants of OpenGL. I have not had any major
issues so far with windows or linux as long as they support 2.X and
higher. I dont know about macos, i assume they would be mainstream as
opengl is the api of choice. In my case I still want to support some
device that only had 1.X ES, which one reason to keep 1.X API around.

I suspect my final system requirements will still be way beyond any devices
with ES 1.x, so I’m not really concerned with those. What I want is PC, Mac,
Linux, Google NaCl and reasonably high powered Android and iOS devices.

You will need to write code to handle loading, compiling and choosing with
shader programs to run. Code to handle shader shared variables (uniforms,
attributes, etc). You will have to handle any transformations yourself.
Going through both fixed api is simple to use, shaders can give you more
power but take more handling to use.

Transforms are no big deal; in fact the 1.x style API is causing more problems
than it solves right now. And shaders is a most welcome feature.

Either way, I’m planing on moving all direct API access into a native code
engine with a partially persistent scene graph (to off-load the scripting
engine without porting lots of game specific rendering code to C), so details
don’t matter much. I just want to avoid maintaining multiple versions of code
that effectively do the same thing.

Thanks!


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

[…SDL_GL_GetProcAddress…]
[…glGetString(GL_VERSION)…]

Check: Already doing that anyway. :slight_smile:

For OpenGL 3.0 and higher there is a context version you can demand via
SDL_GL which would avoid the need for checking the GL_VERSION string, and
in theory it delivers a different API behavior as well (the OpenGL 3.0
Core Profile rather than Compatibility Profile), similar for 4.0, but even
then you still need to use SDL_GL_GetProcAddress.

Even relying on 2.0 seems a bit risky to me, and beyond that… Well, I
sometimes get the feeling that nVidia, AMD etc are trying to use developers as
leverage to pressure users to upgrade sooner. Sure, things need to evolve,
high end apps require the new features anyway, and APIs need to be cleaned up
eventually - but it’s frustrating when you basically can’t do things the
"right way" without dropping half of your potential user base, even when you
really just need 1.1 functionality.

I’m still at 3.3 here, and it doesn’t seem to be possible to get 4.0 with
nVidia drivers without replacing the video cards. However, I don’t know if
"OpenGL 2.0" video cards are restricted to the 2.0 API in the same way.On Thursday 29 March 2012, at 01.08.31, Forest Hale wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’