Finding appropriate constants in GL and it's subclasses GL2ES2, GL4. is painfull, so much constants. Here is different approach, maybe mixing a tree like organization with heritage GL,GL2ES,GL4,.. could be a solution to obtain something more friendly and reduce errors. partial example : https://bitbucket.org/Eclesia/unlicense/src/tip/engine/engine-opengl-util/src/main/java/un/impl/opengl/GLC.java?at=default
(In reply to comment #1) > Finding appropriate constants in GL and it's subclasses GL2ES2, GL4. is > painfull, so much constants. > > Here is different approach, maybe mixing a tree like organization with > heritage GL,GL2ES,GL4,.. could be a solution to obtain something more > friendly and reduce errors. > > partial example : > https://bitbucket.org/Eclesia/unlicense/src/tip/engine/engine-opengl-util/ > src/main/java/un/impl/opengl/GLC.java?at=default I see, you do a semantic split - manual. However, this cannot be generated, since states can be used for many purposes and I dislike duplication I know the GL* interfaces mix up things .. however, they at least give a notion of what profile is being run. Even though devs still need to validate whether the function / enum is an extension .. and supported.
Allow me to state that we shall not make a fundamental change for 2.3.0. With the upcoming Vulkan, things will be quite different, since states will only remain for internal operation and the user needs to 'invent' own semantics and its code.
in process of closing ..