| You forget untimely requests :-).
|
| I have one borderline [sic] ABI issue left. With portability
| and backwards compatibility in mind, it's more of an inquiry.
|
| GLenum (at least the Mesa version) maps multiple enum names
| to the same value, e.g.
|
| GL_TEXTURE_INTERNAL_FORMAT, GL_TEXTURE_COMPONENTS
| GL_TRUE, GL_NONE, GL_ONE
| GL_FALSE, GL_ZERO,
you mean,
GL_TRUE, GL_ONE
GL_FALSE, GL_ZERO, GL_NONE
| GL_LOGIC_OP, GL_INDEX_LOGIC_OP
|
| It's a bit of a nuisance for the GLTrace-like composable
| QGL pipeline I am working on (spits out valid GL code
| where possible, for convenient posting and testing).
|
| Is there a good reason for this duplication. Just accidents
| now protected by virtue of legacy?
some are consequences of evolution, e.g., GL_TEXTURE_COMPONENTS
was generalized to GL_TEXTURE_INTERNAL_FORMAT, but we don't
break compatability by removing stuff. Same for GL_LOGIC_OP,
GL_INDEX_LOGIC_OP. The others have the obvious numerical
values, which was probably considered more valuable than
making them unique.
This is part of the OpenGL standard and is quite separate
from oglbase.
-db
