Preservation of GL state for unsupported extensions

a question related to my earlier post…

even though the NV3x does not support EXT_shared_texture_palette, one can still compile code with the GL_SHARED_TEXTURE_PALETTE_EXT identifier, and even execute glColorTable(…) as if the extension is supported. the hardware obviously will not use the table that has been uploaded, but does it exist in the GL state?

that is, if i were to call glGetColorTable(GL_SHARED_TEXTURE_PALETTE_EXT,…), would i get back valid data?

the issue at hand is i am trying to establish a somewhat card-independent means of doing post-filter texture color tables, and while the texture-shader method works on FX cards, there is no convenient way to query the GL state as to what table is currently loaded.

i have an app with a plugin that needs to know what color table is loaded, the color table having been set from another plugin. the 2 plugins do not know about each other, but share a common GL context.

Originally posted by codemonkey76:
[b]a question related to my earlier post…

even though the NV3x does not support EXT_shared_texture_palette, one can still compile code with the GL_SHARED_TEXTURE_PALETTE_EXT identifier, and even execute glColorTable(…) as if the extension is supported. the hardware obviously will not use the table that has been uploaded, but does it exist in the GL state?

that is, if i were to call glGetColorTable(GL_SHARED_TEXTURE_PALETTE_EXT,…), would i get back valid data?[/b]

No, you won’t. And any other calls using constants that are valid only for a certain not-supported extension will fail, too. Of course you can compile code with those constants, since they are defined in header files like glext.h. But that doesn’t mean a function called with such a parameter does anything. You should use glGetError() to check whether a function succeeded.

[This message has been edited by Xmas (edited 07-15-2003).]

>>>would i get back valid data?<<<

You’re joking, right?