Monday to Friday, a day, 7 am Beijing time on time updates -
All of the examples shown in this book so far have relied on the core functionality of OpenGL (so far the cases are based on the core of the standard OpenGL). However, one of OpenGL's greatest strengths is that it can be extended and enhanced by hardware manufacturers, operating system vendors, and even publishers of tools and debuggers (API extensions, however there are some unique features is a part of the hardware vendor, probably in there is no standard API's). extensions can have many different effects on OpenGL functionality (extension of these characteristics may lead to very different effect)
An extension is any addition to a core version of OpenGL (extension means that additional complement to the core version of the API). Extensions are listed in the OpenGL extension registry on the OpenGL Web site (expanded list which display on the OpenGL Web site). These extensions are written as a list of differences from a particular version of the OpenGL specification, and note what that version of OpenGL is (these extensions may be inconsistent with the implementation of a specific version of the OpenGL standard, you need to pay attention to what version of OpenGL extensions extension). That means the text of the extensions describes how the core OpenGL specification must be changed if the extension is supported (that is to say, if you extend describes the expansion started to realize what will become of OpenGL). However, popular and generally useful extensions are normally "promoted" into the core versions of OpenGL (However, many useful extensions generally will eventually go into the core standards); thus, if you are running the latest and greatest version of OpenGL,there might not be that many extensions that are interesting but not part of the core profile (that is, every update to the latest version of OpenGL time before those extensions may not exist, but were included in the new version of OpenGL standard in). a complete list of the extensions that were promoted to each version of OpenGL and a brief synopsis of what they do is included in Appendix C, "OpenGL Features and Versions." (a complete list of extensions and their related information in Appendix C)
There are three major classifications of extensions: vendor, EXT, and ARB (There are three main extensions: manufacturers, EXT, ARB). Vendor extensions are written and implemented on one vendor's hardware (Extended vendor is implemented on the manufacturers own hardware ). Initials representing the specific vendor are usually part of the extension name- "AMD" for Advanced Micro Devices or "NV" for NVIDIA, for example (usually achieve expression contains the name of the vendor, such as AMD on behalf of Advanced Micro Devices , NV represents NVIDIA). It is possible that more than one vendor might support a specific vendor extension, especially if it becomes widely accepted (there may also be a number of vendors with the achievement of a manufacturer's expansion, especially if that extension widely accepted time). EXT extensions are written together by two or more vendors (EXT extension is an extension was implemented more than two firms). They often start their lives as vendor-specific extensions, but if another vendor is interested in implementing the exten sion, perhaps with minor changes,
This extension process may sound confusing at first (just beginning to hear of promoting the expansion process, they might wonder). Hundreds of extensions currently are available! (Hundreds of extensions can now be used) But new versions of OpenGL are often constructed from extensions programmers have found useful (new OpenGL version is often constructed from a useful extension). in this way each extension gets its time in the sun (in this way, each has an extension that see the sun One day) the ones that shine can be promoted to core (those very Cock extensions will be put into core OpenGL standard to go); the ones that are less useful are not considered (those not very practical it will not be considered ). This "natural selection" process helps to ensure only the most useful and important new features make it into a core version of OpenGL (natural selection can help to filter out the most useful and the most important new features)
A useful tool to determine which extensions are supported in your computer's OpenGL implementation is Realtech VR's OpenGL Extensions Viewer. It is freely available from expandable means the Realtech VR Web site (see Figure 3.6) (a can detect your computer supports called Realtech VR's OpenGL Extensions Viewer, shown in Figure 3.6, it's free)
Enhancing OpenGL with Extensions (Extended Enhanced OpenGL)
Before using any extensions, you must make sure that they're supported by the OpenGL implementation that your application is running on (before using extensions, you need to determine, this extension is currently running on your device are supported). to find out which extensions OpenGL supports, there are two functions that you can use. First, to determine the number of supported extensions, you can call glGetIntegerv () with the GL_NUM_EXTENSIONS parameter (you can, *) to obtain the current through glGetIntegerv (GL_NUM_EXTENSIONS the number of scalable environment support). next, you can find the name of each of the supported extensions by calling (then you can use the following API to get the name of each extension out)
const GLubyte* glGetStringi(GLenum name,GLuint index);
You should pass GL_EXTENSIONS as the name parameter, and a value between 0 and 1 less than the number of supported extensions in index (first argument passed to GL_EXTENSIONS, the second parameter is the first several extensions, this value is less than the previous step extension number obtained). the function returns the name of the extension as a string (this function returns the name of an extension). to see if a specific extension is supported, you can simply query the number of extensions, and then loop through each supported extension and compare its name to the one you're looking for (in order to know whether an extension is supported, you can first get all the extensions name, and then look for the name in there, if there is one you want to look up) . the book's source code comes with a simple function that does this for you (in this course, we encapsulate such a method). sb7IsExtensionSupported () has the prototype (its name is sb7IsExtensionSupported, function as defined below)
int sb7IsExtensionSupported(const char * extname);
This function is declared in the header, takes the name of an extension, and returns non-zero if it is supported by the current OpenGL context and zero if it is not (this function is declared in sb7ext.h, the extension if queried supported, non-zero return, otherwise 0). your application should always check for support for extensions you wish to use before using them (your program you want to use the extended before checking whether the extension is supported)
Extensions generally add to OpenGL in some combination of four different ways (usually extended by some combination of four ways to add to the OpenGL):
They can make things legal that were not before, by simply removing restrictions from the OpenGL specification. ( They can be removed by limiting the number of OpenGL makes the previous unlawful things lawful)
They CAN or the Add tokens at The Extend the Range of values that CAN be passed as parameters to existing functions. ( relative to their existing functions, a wider range of acceptable parameters or token)
they cAN Functionality Extend the GLSL to the Add, Built-in functions, Variables, or Data types. (they can add function, built-in variable or what type of data to enhance GLSL)
they CAN functions to the Add Entirely new new OpenGL Itself (they added a new function for OpenGL)
In the first case, where things that once were considered errors no longer are, your application does not need to do anything besides start using the newly allowed behavior (once you have determined that the extension is supported, of course) (a first case, previously thought to be the wrong call to become properly, in addition to using the new behavior is permitted, you do not need to modify your program). Likewise, for the second case, you can just start using the new token values in the relevant functions, presuming that you have their values (Similarly, for the second case, if you have these parameters, you can begin using the new parameters related to the API). the values of the tokens are in the extension specifications, so you can look them up there if they are not included in your system's header files. (If you can not find in the header file system's case, these parameters in the extended documentation)
To enable use of extensions in GLSL, you must first include a line at the beginning of shaders that use them to tell the compiler that you're going to need their features (GLSL in order to use those extensions, you need to tell in the GLSL compiler, you need to use those features). for example, to enable the hypothetical GL_ABC_foobar_feature extension in GLSL, include the following in the beginning of your shader (for example, to use GL_ABC_foobar_feature extension, you need to write the following in your shader in This sentence):
#extension GL_ABC_foobar_feature : enable
This tells the compiler that you intend to use the extension in your shader (This tells the compiler that you want to use this feature in the shader). If the compiler knows about the extension, it will let you compile the shader, even if the underlying hardware does not support the feature (if the compiler knows this feature, even if the underlying hardware is not supported, the compiler can compile the correct GPU program). If this is the case, the compiler should issue a warning if it sees that the extension is actually being used (if this is the case, then, if this feature is indeed used the shader, the compiler should warn). typically, extensions to GLSL will add preprocessor tokens to indicate their presence (generally speaking, GLSL the expansion will be carried out pre-processing, in order to determine their performance). For example, GL_ABC_foobar_feature will implicitly include (for example GL_ABC_foobar_feature is implicitly included)
GL_ABC_foobar_feature 1 #define
This means that you could code the Write SUCH AS (this sentence shows that you can write the code below)
#if GL_ABC_foobar_feature
// Use functions from the foobar extension
#else
// Emulate or otherwise work around the missing functionality
#endif
This allows you to conditionally compile or execute functionality that is part of an extension that may or may not be supported by the underlying OpenGL implementation. If your shader absolutely requires support for an extension and will not work at all without it, you can instead include this more assertive code:
GL_ABC_foobar_feature #extension: The require
the If does not at The OpenGL Implementation Support at The GL_ABC_foobar_feature Extension, the then IT by Will Fail at The shader and Report to the compile error ON AN at The Line Including at The #extension Directive (if GL_ABC_foobar_feature achieve OpenGL does not support expansion, the shader compiler will fail, and report the nature of the error). in effect, GLSL extensions are opt-in features, and applications must tell compilers up front which extensions they intend to use ( in fact GLSL extension is selective properties, the application should tells the compiler what they want to expand the use)
Next we come to extensions that introduce new functions to OpenGL (Next, we look at those extensions add a new function for OpenGL). On most platforms, you do not have direct access to the OpenGL driver and extension functions do not just magically appear as available to your applications to call (on most platforms, you can not directly access OpenGL drivers, extensions will not be so magical function can be directly access your program). Rather, you must ask the OpenGL driver for a function pointer that represents the function you want to call (more is that you need to find OpenGL drivers to a pointer to a function that you want to visit) function pointers are generally declared in two parts;. (function pointers are usually defined as two portions) the first is the definition ofthe function pointer type, and the second is the function pointer variable itself. (the first part is a pointer type function, the second part is itself a function pointer) Consider this code as an example :( e.g. below)
typedef void
(APIENTRYP PFNGLDRAWTRANSFORMFEEDBACKPROC) (Glen mode, it GLuint);
PFNGLDRAWTRANSFORMFEEDBACKPROC glDrawTransformFeedback = NULL;
This declares the PFNGLDRAWTRANSFORMFEEDBACKPROC type as a pointer to a function taking GLenum and GLuint parameters (PFNGLDRAWTRANSFORMFEEDBACKPROC This defines the type of function pointers, and this function accepts a parameter GLenum and GLuint). Next, it declares the glDrawTransformFeedback variable as an instance of this type (it then defines the actual variables of the function pointer type). in fact, on many platforms, the declaration of the glDrawTransformFeedback () function is actually just like this (in fact, on many platforms, just like show this, glDrawTransformFeedback is so defined). this seems pretty complicated, but fortunately the following header files include declarations of all of the function prototypes, function pointer types, and token values introduced by all registered OpenGL extensions (which looks very complex, but fortunately, following this header file defines all types of functions, function pointers, and those types of parameters):
#include
#include
#include
THESE Files CAN BE AT found at The OpenGL Extension Registry Web Site (these can be found on the website OpenGL extensions). The glext.h header contains both standard OpenGL extensions and many vendor-specific OpenGL extensions (glext. h include standard OpenGL extensions and many manufacturers of expansion), the wglext.h header contains a number of extensions that are Windows specific (wglext.h included is support for the Windows extensions), and the glxext.h header contains definitions that are X specific (glxext.h extension contains the X, X refers to the window system of the Unix or Linux) (X is the windowing system used on Linux and many other UNIX derivatives and implementations)
The method for querying the address of extension functions is actually platform specific (query expansion function access address will differ depending on the platform). The book's application framework wraps up these intricacies into a handy function that is declared in the header file (this book these methods are packed into the frame a function of sb7ext.h gone) the function sb7GetProcAddress () has this prototype (function called sb7GetProcAddress, which is defined as follows):
void sb7GetProcAddress (const char funcname);
Here, funcname IS at The name of at The Extension function that you td width = wish to use (here funcname is the name of the extension function) The return value is the address of the function, if it's supported, and NULL otherwise. (if the extension is supported, the function returns the address of a function, otherwise it returns NULL). Even if OpenGL returns a valid function pointer for a function that's part of the extension you want to use, that does not mean the extension is present ( even OpenGL returned a legitimate function pointer, it was only an extension that does not mean there is extended). Sometimes the same function is part of more than one extension, and sometimes vendors ship drivers with partial implementations of extensions present ( there the same function when multiple extensions are part of, and sometimes the only vendor to achieve a part of the expansion). Always check for support for extensions using the official mechanisms or the sb7IsExtensionSupported () function ( make sure to check before using the extended Whether the extension is supported).
Translations of this day to get here, see you tomorrow, bye ~