OpenGL enumerations

[StrideColossus]

I have a platform-agnostic core engine that is extended by platform-specific 'back-ends' for Android and LWJGL.  One aspect of this design that I can't make up my mind on is mapping of the various enumerations in the core part (e.g. primitive types, texture filters, etc) to the corresponding OpenGL constants in the back-end implementations (e.g. GL_TRIANGLE_STRIP, GL_CLAMP_TO_EDGE, etc).

Here are the approaches I've considered so far:

1. Map enums to constants in each back-end

Each back-end implementation is responsible for mapping the enumerations to the constants.  Easy to do using a switch statement, but laborious and possibly error-prone to implement (temptation to cut-and-paste), particularly irksome for some of the larger sets such as blending functions, also adds slight over-head of constantly having to perform the mapping.

2. Hard-code OpenGL constants in the core engine

Assume that the constants are the same across all OpenGL implementations (Android and LWJGL) and hard-code them in the core engine - Is this assumption valid?

(Could probably minimise the hard-coding in most cases by using just one value and the ordinal() of the enum since most OpenGL constants are contiguous).

3. Dodgy reflection lookup of OpenGL constants

Use some devious reflection logic to lookup the OpenGL constants by name, e.g. take the enumeration name(), prepen GL_ and reflect through the static GL classes to find the matching constant - Works but feels dirty!

So:

Any other approaches I've not thought of?
Any opinion on the best approach?  (I'm inclined to #2 since that seems the least effort / risk)

Cheers for any thoughts.

- stride

[Danny02]

yes OpenGL constants are constants 

[princec]

What he means is, they are the same, on all versions of OpenGL, on all platforms. No mapping to do!

Cas

Games published by our own members! Check 'em out!

[StrideColossus]

Cool, assumed they were constant across all implementation but just wanted to check before I go ahead.
Ta

[gouessej]

I have a platform-agnostic core engine that is extended by platform-specific 'back-ends' for Android and LWJGL.

Why do you need to do that? Doesn't LWJGL support Android??

[StrideColossus]

I have a platform-agnostic core engine that is extended by platform-specific 'back-ends' for Android and LWJGL.

Why do you need to do that? Doesn't LWJGL support Android??

No, or at least not yet AFAIK.

LWJGL nicely wraps up the underlying OpenGL APIs (and provides some other stuff such as display and mouse/keyboard device management).
Android has this stuff as part of it's core API (depending on version ofc) so they're sort of mutually-exclusive.

I believe most (all?) other libraries/engines use the same approach: LWJGL for Linux / Windows / Mac and OpenGL-ES for Android.

[gouessej]

I believe most (all?) other libraries/engines use the same approach: LWJGL for Linux / Windows / Mac and OpenGL-ES for Android.

OpenGL-ES can be used under GNU Linux too, for example on the Raspberry Pi. The engine backends based on LWJGL work that way because as far as I know it provides no windowing toolkit compatible both with Android and desktop environments which isn't the case of all engine backends and that's why it's possible to use the Raspberry Pi with JMonkeyEngine without making a separate native renderer based on its Android GL backend.

[StrideColossus]

OpenGL-ES can be used under GNU Linux too, for example on the Raspberry Pi. The engine backends based on LWJGL work that way because as far as I know it provides no windowing toolkit compatible both with Android and desktop environments which isn't the case of all engine backends and that's why it's possible to use the Raspberry Pi with JMonkeyEngine without making a separate native renderer based on its Android GL backend.

Cool I didn't know that.  Couple of my work colleagues have Raspberry Pi's that they're fiddling with, will have to target that as well.