CODEWITHSUNDEEP
copengl
Joao Pincho
Joao Pincho

Reputation: 979

Compatibility of OpenGL with OpenGLES2

I've been trying to write some opengl code that works everywhere, but without restricting myself too much.
I wanted to use opengles2 on devices that only support it, and opengl core where supported.

Also, I wanted to be able to select which one I'd use, in runtime ( if available, of course ).

My questions are:
if I link my code with OpenGL library every time it is available, and then either create a GLES2 or GL core context, will the GLES2 context behave exactly the same as GLESv2 library? What will be the repercussions of this, header-wise? For example, GLESv2 does not define BGRA texture formats, so I guess I'd have to convert all to RGBA. It's not much of a hassle, but I'm interested in knowing about alternatives.

I've thought of dynamically loading the library and loading all used functions pointers, but that's a huge amount of work for something that maybe has a easier answer. In this case, I would just include glext.h, and declare all the function pointers for the used functions, and populate them. The problem here, is that glext does not define any data types ( glenum, etc ), so I always have to include gl.h. By including both, I get the gl.h function declaration AND my own function pointer declaration, so I couldn't just use the general namespace for the function pointers... And even then, some functions ( like glGetError ) do not seem to have an associated typedef for their function pointer.

I know about GLEW, but unfortunately, most linux distros distribute a version of GLEW that is still not GLES2 compatible ( debian, i'm looking at you ). It just segfaults.

How would you guys do this? Any other approaches for opengl function linking?

Upvotes: 4

Views: 96

Answers (1)

Andreas
Andreas

Reputation: 5301

I´m in aerospace industry where I get to work with all kinds of OpenGL subsets as each hardware provider has its own version. (I´d love to work with a full documented profile of... well... anything.) It would seem we do have similar issues. I´ll give you what I have learned so far.

First of all you will want to develop towards the biggest badest superset of all profiles you can get. Use the latest version of OpenGL headers provided by your hardware vendor. That way your program will at least solve the compiling part.

BGRA macro/enum will be part of your GLESv2 runtime, but you will sure never to use it in runtime should your platform only support RGBA.

Runtime decisions based on platform capabilities are made based on the OpenGL extension list. Compare the extension list with whatever the application use, deactivate unsupported branches and activate supported branches. You are able to distinguish between OpenGL and GLES this way.

Upvotes: 1

Related Questions