Even when an extension grows up, moving from an EXT to an
ARB (sometimes from vendor straight to ARB) and ?¬?nally into the speci?¬?cation
itself, the older ways of identifying it will still exist. Speci?¬?cally, the OpenGL
speci?¬?cation says this on extension promotion:
ARB extensions can be promoted to required core features in later revisions of
OpenGL. When this occurs, the extension speci?¬?cations are merged into the core
speci?¬?cation. Functions and enumerants that are part of such promoted extensions
will have the ARB af?¬?x removed.
GL implementations of such later revisions should continue to export the name
strings of promoted extensions in the EXTENSIONS string, and continue to support
the ARB-af?¬?xed versions of functions and enumerants as a transition aid.
Now that we??™ve seen the process that an extension goes through from concept
to core OpenGL, what happens in the middle? That is, what does an extension
de?¬?ne and provide, how do you determine what??™s available, and how do you
implement an extension? Let??™s look at these issues in order.
Extension Styles and Types
OpenGL extensions have many different forms and usage patterns. Some
extensions de?¬?ne new tokens for use with existing functions. One example
is GL ARB texture mirrored repeat, which de?¬?nes a new token for
use with the glTexParameter suite of calls, allowing a new type of
GL TEXTURE WRAP style: GL MIRRORED REPEAT ARB.
Pages:
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373