[size="5"]OpenGL Extensions
As you're aware, the graphics industry has been moving at an alarmingly rapid pace for many years now. Today, consumer-level video cards include features that were only available on professional video cards (costing thousands of dollars) a few years ago. Any viable graphics API has to take these advances into account, and provide some means to keep up with them. OpenGL does this through extensions.
If a graphics vendor adds a new hardware feature that they want OpenGL programmers to be able to take advantage of, they simply need to add support for it in their ICD, and then provide developers with documentation about how to use the extension. This is oversimplifying a bit, but it's close enough for our purposes. As an OpenGL programmer, you can then access the extension through a common interface shared by all extensions. You'll learn how to do that in the "Using Extensions" section, but for now, let's look at how extensions are identified, and what they consist of.
[size="3"]Extension Names
Every OpenGL extension has a name by which it can be precisely and uniquely identified. This is important, because hardware vendors will frequently introduce extensions with similar functionality but very different semantics and usage. You need to be able to distinguish between them. For example, both NVIDIA and ATI provide extensions for programmable vertex and pixel shaders, but they bear little resemblance to each other. So, if you wanted to use pixel shaders in your program, it wouldn't be enough to find out if the hardware supported pixel shaders. You'd have to be able to specifically ask whether NVIDIA's or ATI's version is supported, and handle each appropriately.
All OpenGL extensions use the following naming convention:
PREFIX_extension_name
Table 1 - OpenGL Extension Prefixes Prefix Meaning/Vendor ARBExtension approved by OpenGL's Architectural Review Board (first introduced with OpenGL 1.2) EXT Extension agreed upon by more than one OpenGL vendor 3DFX 3dfx Interactive APPLE Apple Computer ATI ATI Technologies ATIX ATI Technologies (experimental) HP Hewlett-Packard INTELIntel Corporation IBM International Business Machines KTX Kinetix NV NVIDIA Corporation MESA http://www.mesa3d.org OML OpenML SGI Silicon Graphics SGISSilicon Graphics (specialized) SGIX Silicon Graphics (experimental) SUN Sun Microsystems SUNX Sun Microsystems (experimental) WIN Microsoft
[bquote]Caution: Some extensions share a name, but have a different prefix. These extensions are generally not interchangeable, as they may use entirely different semantics. For example, [font="Courier New"][color="#000080"]ARB_texture_env_combine[/color][/font] is not the same thing as [font="Courier New"][color="#000080"]EXT_texture_env_combine[/color][/font]. Rather than making assumptions, be sure to consult the extension specifications when you're unsure.[/bquote]
[size="3"]What an Extension IncludesYou now know what an extension is, and how extensions are named. Next, let's turn our attention to the relevant components of an extension. There are four parts of an extension that you need to deal with.
Name Strings
Name strings are generally the name of the extension preceded by another prefix. For core OpenGL name strings, this is always GL_ (e.g. GL_EXT_texture_compression). When the name string is tied to a particular windows system, the prefix will reflect which system that is (e.g. Win32 uses WGL_).
[bquote]Some extensions may define more than one name string. This would be the case if the extension provided both core OpenGL functionality and functionality specific to the windows system.[/bquote]
FunctionsThe functions defined by the extension follow the naming convention used by the rest of OpenGL, namely [font="Courier New"][color="#000080"]glFunctionName()[/color][/font], with the addition of a suffix using the same letters as the extension name's prefix. For example, the [font="Courier New"][color="#000080"]NV_fence[/color][/font] extension includes the functions [font="Courier New"][color="#000080"]glGetFencesNV()[/color][/font], [font="Courier New"][color="#000080"]glSetFenceNV()[/color][/font], [font="Courier New"][color="#000080"]glTestFenceNV()[/color][/font], and so on.
Enumerants
The new enumerants follow the normal OpenGL naming convention (i.e. [font="Courier New"][color="#000080"]GL_WHATEVER[/color][/font]), except that they are suffixed by the letters used in the extension name's prefix, such as [font="Courier New"][color="#000080"]GL_VERTEX_SOURCE_ATI[/color][/font].
Using new enumerants is much simpler than using new functions. Usually, you will just need to include a header defining the enumerant, which you can get from your hardware vendor or from SGI. Alternately, you can define the enumerant yourself if you know the integer value it uses. This value can be obtained from the extension's documentation.
[bquote]Extensions don't need to define both functions and enumerants (though many do), but they usually include at least one of the two. The few cases where that's not true is when existing functions or enumerants are combined in new ways.[/bquote]
DependenciesSpeaking of documentation, you're probably wondering where you can get it, so let's talk about that next.
[size="3"]Extension Documentation
Although vendors may (and usually do) provide documentation for their extensions in many forms, there is one piece of documentation that is absolutely essential-- the specification. These are generally written as plain text files, and include a broad range of information about the extension, such as its name, version, number, dependencies, new functions and enumerants, issues, and modifications/additions to the OpenGL specification.
The specifications are intended for use by developers of OpenGL hardware or ICDs, and as such, are of limited use to game developers. They'll tell you what the extension does, but not why you'd want to use it, or how to use it. For that reason, I'm not going to go over the details of the specification format. If you're interested, Mark Kilgard has written an excellent article about it which you can read at OpenGL.org. [[alink='ref']1[/alink]]
As new extensions are released, their specifications are listed in the OpenGL Extension Registry, which you can find at the following URL:
http://oss.sgi.com/p...ample/registry/
This registry is updated regularly, so it's a great way to keep up with the newest additions to OpenGL.
For more detailed descriptions of new extensions, your best bet is the websites of the leading hardware vendors. In particular, NVIDIA [[alink='ref']2[/alink]] and ATI [[alink='ref']3[/alink]] both provide a wealth of information, including white papers, Power Point presentations, and demos.
[bquote]Extensions that are promoted to be a part of the core OpenGL specification may be removed from the extension registry. To obtain information about these, you'll have to refer to the latest OpenGL specification. [[alink='ref']4[/alink]][/bquote]
Finally, it's time to learn what you need to do to use an extension. In general, there are only a couple of steps you need to take:
[bquote]Caution: Before checking for extension availability and obtaining pointers to functions, you MUST have a current rendering context. In addition, the entry points are specific to each rendering context, so if you're using more than one, you'll have to obtain a separate entry point for each.[/bquote]
[size="3"]Querying the Name StringIn order to find out whether or not a specific extension is available, first get the list of all the name strings supported by the OpenGL implementation. To do this, you just need to call [font="Courier New"][color="#000080"]glGetString()[/color][/font] using [font="Courier New"][color="#000080"]GL_EXTENSIONS[/color][/font], like so:
char* extensionsList = (char*) glGetString(GL_EXTENSIONS);
[bquote]I'm casting the value returned by [font="Courier New"][color="#000080"]glGetString()[/color][/font] because the function actually returns an array of unsigned chars. Since most of the string manipulation functions I'll be using require signed chars, I do the cast once now instead of doing it many times later.[/bquote]
To find out whether or not the extension you're looking for is supported, you'll need to search this buffer to see if it includes the extension's name string. I'm not going to go into great detail about how to parse the buffer, since there are many ways to do so, and it's something that at this stage in your programming career, you should be able to do without much effort. One thing you need to watch out for, though, is accidentally matching a substring. For example, if you're trying to use the [font="Courier New"][color="#000080"]EXT_texture_env[/color][/font] extension, and the implementation doesn't support it, but it does support [font="Courier New"][color="#000080"]EXT_texture_env_dot3[/color][/font], then calling something like:strstr("GL_EXT_texture_env", extensionsList);
[size="3"]Obtaining the Function's Entry Point
Because of the way Microsoft handles its OpenGL implementation, calling a new function provided by an extension requires that you request a function pointer to the entry point from the ICD. This isn't as bad as it sounds.
First of all, you need to declare a function pointer. If you've worked with function pointers before, you know that they can be pretty ugly. If not, here's an example:
void (APIENTRY * pglCopyTexSubImage3DEXT) (GLenum, GLint, GLint,
GLint, GLint, GLint, GLint, GLsizei, GLsizei) = NULL;
[bquote]Update 4/24/03: For the book, and initially here, I used the function name (i.e. glCopyTexSubImage3DEXT) as the pointer name. A reader pointed out to me that on a number of operating systems (e.g. Linux) this can cause serious problems, so it should be avoided. Thanks, Ian![/bquote]
Now that we have the function pointer, we can attempt to assign an entry point to it. This is done using the function [font="Courier New"][color="#000080"]wglGetProcAddress()[/color][/font]:PROC wglGetProcAddress( LPCSTR lpszProcName );
Let's look at an example, using the function pointer we declared above:
pglCopyTexSubImage3DEXT =
(void (APIENTRY *) (GLenum, GLint, GLint, GLint, GLint, GLint, GLint, GLsizei, GLsizei))
wglGetProcAddress("glCopyTexSubImage3DEXT");
You can make life easier on yourself by using [font="Courier New"][color="#000080"]typedefs[/color][/font]. In fact, you can obtain a header called "glext.h" which contains [font="Courier New"][color="#000080"]typedefs[/color][/font] for most of the extensions out there. This header can usually be obtained from your favorite hardware vendor (for example, NVIDIA includes it in their OpenGL SDK), or from SGI at the following URL:
http://oss.sgi.com/p...ple/ABI/glext.h
Using this header, the code above becomes:
PFNGLCOPYTEXSUBIMAGE3DEXTPROC pglCopyTexSubImage3DEXT = NULL;
pglCopyTexSubImage3DEXT = (PFNGLCOPYTEXSUBIMAGE3DEXTPROC) wglGetProcAddress("glCopyTexSubImage3DEXT");
As long as [font="Courier New"][color="#000080"]wglGetProcAddress()[/color][/font] doesn't return NULL, you can then freely use the function pointer as if it were a normal OpenGL function.
[size="3"]Declaring Enumerants
To use new enumerants defined by an extension, all you have to do is define the enumerant to be the appropriate integer value. You can find this value in the extension specification. For example, the specification for the [font="Courier New"][color="#000080"]EXT_texture_lod_bias[/color][/font] says that [font="Courier New"][color="#000080"]GL_TEXTURE_LOD_BIAS_EXT[/color][/font] should have a value of 0x8501, so somewhere, probably in a header (or possibly even in gl.h), you'd have the following:
[font="Courier New"]#define GL_TEXTURE_LOD_BIAS_EXT 0x8501[/font]
[size="3"]Win32 Specifics
In addition to the standard extensions that have been covered so far, there are some extensions that are specific to the Windows system. These extensions provide additions that are very specific to the windowing system and the way it interacts with OpenGL, such as additional options related to pixel formats. These extensions are easily identified by their use of "WGL" instead of "GL" in their names. The name strings for these extensions normally aren't included in the buffer returned by [font="Courier New"][color="#000080"]glGetString(GL_EXTENSIONS)[/color][/font], although a few are. To get all of the Windows-specific extensions, you'll have to use another function, [font="Courier New"][color="#000080"]wglGetExtensionsStringARB()[/color][/font]. As the ARB suffix indicates, it's an extension itself ([font="Courier New"][color="#000080"]ARB_extensions_string[/color][/font]), so you'll have to get the address of it yourself using [font="Courier New"][color="#000080"]wglGetProcAddress()[/color][/font]. Note that for some reason, some ICDs identify this as [font="Courier New"][color="#000080"]wglGetExtensionsStringEXT()[/color][/font] instead, so if you fail to get a pointer to one, try the other. The format of this function is as follows:
const char* wglGetExtensionsStringARB(HDC hdc);
[bquote]Caution: Normally, it's good practice to check for an extension by examining the buffer returned by glGetString() before trying to obtain function entry points. However, it's not strictly necessary to do so. If you try to get the entry point for a non-existant function, [font="Courier New"][color="#000080"]wglGetProcAddress()[/color][/font] will return NULL, and you can simply test for that. The reason I'm mentioning this is because to use [font="Courier New"][color="#000080"]wglGetExtensionsStringARB()[/color][/font], that's exactly what you have to do. It appears that with most ICDs, the name string for this extension, [font="Courier New"][color="#000080"]WGL_ARB_extensions_string[/color][/font], doesn't appear in the buffer returned by [font="Courier New"][color="#000080"]glGetString()[/color][/font]. Instead, it is included in the buffer returned by [font="Courier New"][color="#000080"]wglGetExtensionsStringARB()[/color][/font]! Go figure.[/bquote]
Its sole parameter is the handle to your rendering context. The function returns a buffer similar to that returned by [font="Courier New"][color="#000080"]glGetString(GL_EXTENSIONS)[/color][/font], with the only difference being that it only contains the names of WGL extensions.[bquote]Some WGL extension string names included in the buffer returned by [font="Courier New"][color="#000080"]wglGetExtensionsStringARB()[/color][/font] may also appear in the buffer returned by [font="Courier New"][color="#000080"]glGetString()[/color][/font]. This is due to the fact that those extensions existed before the creation of the [font="Courier New"][color="#000080"]ARB_extensions_string[/color][/font] extension, and so their name strings appear in both places to avoid breaking existing software.[/bquote]
Just as there is a glext.h header for core OpenGL extensions, so is there a wglext.h for WGL extensions. You can find it at the following link:http://oss.sgi.com/p...le/ABI/wglext.h
[size="5"]Extensions and OpenGL 1.2 and 1.3, and the Future
Back at the beginning of this article, I said that OpenGL 1.2 and 1.3 features can be accessed using the extensions mechanism, which I've spent the last several pages explaining. The question, then, is how you go about doing that. The answer, as you may have guessed, is to treat 1.2 and 1.3 features as extensions. When it comes right down to it, that's really what they are, since nearly every feature that has been added to OpenGL originated as an extension. The only real difference between 1.2 and 1.3 features and "normal" extensions is that the former tend to be more widely supported in hardware, because, after all, they are part of the standard.
[bquote] Sometimes, an extension that has been added to the OpenGL 1.2 or 1.3 core specification will undergo slight changes, causing the semantics and/or behavior to be somewhat different from what is documented in the extension's specification. You should check the latest OpenGL specification to find out about these changes.[/bquote]
[size="5"]What You Get
As you can see, using OpenGL 1.2 and 1.3, and extensions in general, isn't a terribly difficult process, but it does take some extra effort. You may be wondering what you can gain by using them, so lets take a closer look at them. The following sections list the features added by OpenGL 1.2 and 1.3, as well as some of the more useful extensions currently available. With each feature, I've included the extension you can use to access it.
[size="3"]OpenGL 1.2
BGRA Pixel Formats make it easier to work with file formats which use blue-green-red color component ordering rather than red-green-blue. Bitmaps and Targas are two examples that fall in this category. BGRA pixel formats correspond to the [font="Courier New"][color="#000080"]EXT_bgra[/color][/font] extension.
Packed Pixel Formats provide support for packed pixels in host memory, allowing you to completely represent a pixel using a single unsigned byte, short, or int. Packet pixel formats correspond to the [font="Courier New"][color="#000080"]EXT_packed_pixels[/color][/font] extension, with some additions for reversed component order.
Normally, since texture mapping happens after lighting, modulating a texture with a lit surface will "wash out" specular highlights. To help avoid this affect, the Separate Specular Color feature has been added. This causes OpenGL to track the specular color separately and apply it after texture mapping. Separate specular color corresponds to the [font="Courier New"][color="#000080"]EXT_separate_specular_color[/color][/font] extension.
Texture Coordinate Edge Clamping addresses a problem with filtering at the edges of textures. When you select [font="Courier New"][color="#000080"]GL_CLAMP[/color][/font] as your texture wrap mode and use a linear filtering mode, the border will get sampled along with edge texels. Texture coordinate edge clamping causes only the texels which are actually part of the texture to be sampled. This corresponds to the [font="Courier New"][color="#000080"]SGIS_texture_edge_clamp[/color][/font] extension (which normally shows up as [font="Courier New"][color="#000080"]EXT_texture_edge_clamp[/color][/font] in the [font="Courier New"][color="#000080"]GL_EXTENSIONS[/color][/font] string).
Normal Rescaling allows you to automatically scale normals by a value you specify, which can be faster than renormalization in some cases, although it requires uniform scaling to be useful. This corresponds to the [font="Courier New"][color="#000080"]EXT_rescale_normal[/color][/font] extension.
Texture LOD Control allows you to specify certain parameters related to the texture level of detail used in mipmapping to avoid popping in certain situations. It can also be used to increase texture transfer performance, since the extension can be used to upload only the mipmap levels visible in the current frame, instead of uploading the entire mipmap hierarchy. This matches the [font="Courier New"][color="#000080"]SGIS_texture_lod[/color][/font] extension.
The Draw Element Range feature adds a new function to be used with vertex arrays. [font="Courier New"][color="#000080"]glDrawRangeElements()[/color][/font] is similar to [font="Courier New"][color="#000080"]glDrawElements()[/color][/font], but it lets you indicate the range of indicies within the arrays that you are using, allowing the hardware to process the data more efficiently. This corresponds to the [font="Courier New"][color="#000080"]EXT_draw_range_elements[/color][/font] extension.
The Imaging Subset is not fully present in all OpenGL implementations, since it's primarily intended for image processing applications. It's actually a collection of several extensions. The following are the ones that may be of interest to game developers.
The Multitexturing extension was promoted to ARB status with OpenGL 1.2.1 (the only real change in that release), and in 1.3, it was made part of the standard. Multitexturing allows you to apply more than one texture to a surface in a single pass, which is useful in many things, such as lightmapping and detail texturing. It was promoted from the [font="Courier New"][color="#000080"]ARB_multitexture[/color][/font] extension.
Texture Compression allows you to either provide OpenGL with precompressed data for your textures, or to have the driver compress the data for you. The advantage in doing so is that you save both texture memory and bandwidth, thereby improving performance. Compressed textures were promoted from the [font="Courier New"][color="#000080"]ARB_compressed_textures[/color][/font] extension.
Cube Map Textures provide a new type of texture consisting of six two-dimensional textures in the shape of a cube. Texture coordinates act like a vector from the center of the cube, indicating which face and which texels to use. Cube mapping is useful in environment mapping and texture-based diffuse lighting. It is also important for pixel-perfect dot3 bumpmapping, as a normalization lookup for interpolated fragment normals. It was promoted from the [font="Courier New"][color="#000080"]ARB_texture_cube_map[/color][/font] extension.
Multisampling allows for automatic antialiasing by sampling all geometry several times for each pixel. When it's supported, and extra buffer is created which contains color, depth, and stencil values. Multisampling is, of course, expensive, and you need to be sure to request a rendering context that supports it. It was promoted from the [font="Courier New"][color="#000080"]ARB_multisampling[/color][/font] extension.
The Texture Add Environment Mode adds a new enumerant which can be passed to [font="Courier New"][color="#000080"]glTexEnv()[/color][/font]. It causes the texture to be additively combined with the incoming fragment. This was promoted from the [font="Courier New"][color="#000080"]ARB_texture_env_add[/color][/font] extension.
Texture Combine Environment Modes add a lot of new options for the way textures are combined. In addition to the texture color and the incoming fragment, you can also include a constant texture color and the results of the previous texture environment stage as parameters. These parameters can be combined using passthrough, multiplication, addition, biased addition, subtraction, and linear interpolation. You can select combiner operations for the RGB and alpha components separately. You can also scale the final result. As you can see, this addition gives you a great deal of flexibility. Texture combine environment modes were promoted from the [font="Courier New"][color="#000080"]ARB_texture_env_combine[/color][/font] extension.
The Texture Dot3 Environment Mode adds a new enumerant to the texture combine environment modes. The dot3 environment mode allows you to take the dot product of two specified components and place the results in the RGB or RGBA components of the output color. This can be used for per-pixel lighting or bump mapping. The dot3 environment mode was promoted from the [font="Courier New"][color="#000080"]ARB_texture_env_dot3[/color][/font] extension.
Texture Border Clamp is similar to texture edge clamp, except that it causes texture coordinates that straddle the edge to sample from border texels only, rather than from edge texels. This was promoted from the [font="Courier New"][color="#000080"]ARB_texture_border_clamp[/color][/font] extension.
Transpose Matrices allow you to pass row major matrices to OpenGL, which normally uses column major matrices. This is useful not only because it is how C stores two dimensional arrays, but because it is how Direct3D stores matricies, which saves conversion work when you're writing a rendering engine that uses both APIs. This addition only adds to the interface; it does not change the way OpenGL works internally. Transpose matrices were promoted from the [font="Courier New"][color="#000080"]ARB_transpose_matrix[/color][/font] extension.
[size="3"]Useful Extensions
At the time of writing, there are 269 extensions listed in the Extension Registry. Even if I focused on the ones actually being used, I couldn't hope to cover them all, even briefly. Instead, I'll focus on a few that seem to be the most important for use in games.
Programmable Vertex and Pixel Shaders
If you're unfamiliar with shaders, then a quick overview is in order. Vertex shaders allow you to customize the geometry transformation pipeline. Pixel shaders work later in the pipeline, and allow you to control how the final pixel color is determined. Together, the two provide incredible functionality. I recommend that you download NVIDIA's Effects Browser to see examples of the things you can do with shaders.
Using shaders can be somewhat problematic right now due to the fact that NVIDIA and ATI both handle them very differently. If you want your game to take advantage of shaders, you'll have to write a lot of special case code to use each vendor's method. At the ARB's last several meetings, this has been a major discussion point. There is a great deal of pressure to create a common shader interface. In fact, it is at the core of 3D Labs' OpenGL 2.0 proposal. Hopefully, the 1.4 specification will address this issue, but the ARB seems to be split as to whether a common shader interface should be a necessary component of 1.4.
Compiled Vertex Arrays
The benefits gained by using CVAs depend on the data set, the video card, and the drivers. Although you generally won't see a decrease in performance when using CVAs, it's quite possible that you won't see much of an increase either. In any case, the fact that they are fairly widely supported makes them worth looking into.
WGL Extensions
On NVIDIA hardware, the vertex array range extension is currently the fastest way to transfer data from the application to the GPU. Its speed comes from the fact that it allows the developer to allocate and access memory that normally can only be accessed by the GPU.
Although not directly related to the vertex array range extension, the fence extension can help make it even more efficient. When a fence is added to the OpenGL command stream, it can then be queried at any time. Usually, it is queried to determine whether or not it has been completed yet. In addition, you can force the application to wait for the fence to be completed. Fences can be used with vertex array range when there is not enough memory to hold all of your vertex data at once. In this situation, you can fill up available memory, insert a fence, and when the fence has completed, repeat the process.
Shadows
[size="5"]Writing Well-Behaved Programs Using Extensions
Something you need to be very aware of when using any extension is that it is highly likely that someone will run your program on a system that does not support that extension. It's your responsibility to make sure that when this happens, your program behaves intelligently, rather than crashing or rendering garbage to the screen. In this section, you'll learn several methods to help ensure that your program gets the best possible results on all systems. The focus is on two areas: how to select which extensions to use, and how to respond when an extension you're using isn't supported.
[size="3"]Choosing Extensions
The most important thing you can do to insure that your program runs on as many systems as possible is to choose your extensions wisely. The following are some factors you should consider.
Do you really need the extension?
What level of promotion is the extension at?
[bquote]There are times when a vendor-specific extension can be completely replaced by an EXT or ARB extension. In this case, the latter should always be favored.[/bquote]
Who is your target audience?If, on the other hand, you're targeting casual game players, you'll probably want to use very few extensions, if any.
When will your game be done?
[size="3"]What To Do When an Extension Isn't Supported
First of all, let's make one thing very clear. Before you use any extension, you need to check to see if it is supported on the user's system. If it's not, you need to do something about it. What that "something" is depends on a number of things, as we'll discuss here, but you really need to have some kind of contingency plan. I've seen OpenGL code that just assumes that the needed extensions will be there. This can lead to blank screens, unexpected rendering effects, and even crashes. Here are some of the possible methods you can use when you find that an extension isn't supported.
Don't Use the Extension
Try Similar Extensions
Find an Alternate Way
Exit Gracefully
[size="5"]The Demo
I've created a simple demo (see attached resource file) to show you some extensions in action. As you can see from Figure 1, the demo itself is fairly simple, nothing more than a light moving above a textured surface, casting a light on it using a lightmap. The demo isn't interactive at all. I kept it simple because I wanted to be able to focus on the extension mechanism.
Figure 1: Basic lightmapping (click to enlarge)
Table 2 - Extensions used in the demo Extension Usage ARB_multitexture The floor in this demo is a single quad with two textures applied to it: one for the bricks, and the other for the lightmap, which is updated with the light's position. The textures are combined using modulation. EXT_point_parametetersWhen used, this extension causes point primitives to change size depending on their distance from the eye. You can set attenuation factors to determine how much the size changes, as well as define maximum and minimum sizes, and even specify that the points become partially transparent if they go below a certain threshold. The yellow light in the demo takes advantage of this extension. The effect is subtle, but you should be able to notice it changing size. EXT_swap_control Most OpenGL drivers allow the user to specify whether or not screen redraws should wait for the monitor's vertical refresh, or vertical sync. If this is enabled, your game's framerate will be limited to whatever the monitor refresh rate is set to. This extension allows you to programmatically disable vsync to get to avoid this limitation. EXT_bgra Since the demo uses Targas for textures, using this extension allows it to use their data directly without having to swap the red and blue components before creating the textures. ARB_texture_compression Since the demo only uses two textures, it won't gain much by using texture compression, but since it's easy, so I used it anyway. I allow the drivers to compress the data for me, rather than doing so myself beforehand. EXT_texture_edge_clamp Again, this extension wasn't strictly necessary, but the demo shows how easy it is to use. SGIS_generate_mipmap GLU provides a function, gluBuild2DMipMaps, that allows you to specify just the base level of a mipmap chain and automatically generates the other levels for you. This extension performs essentially the same function, with a couple of exceptions. One, it is a little more efficient. Two, it will cause all of the mipmap levels to be regenerated automatically whenever you change the base level. This can be useful when using dynamic textures. The full source code to the demo is included on the CD, but there are a couple of functions that I want to look at.
The first is [font="Courier New"][color="#000080"]InitializeExtensions()[/color][/font]. This function is called at startup, right after the rendering context is created. It verifies that the extensions used are supported, and gets the function entry points that are needed.
bool InitializeExtensions()
{
if (CheckExtension("GL_ARB_multitexture"))
{
glMultiTexCoord2f = (PFNGLMULTITEXCOORD2FARBPROC)
wglGetProcAddress("glMultiTexCoord2fARB");
glActiveTexture = (PFNGLCLIENTACTIVETEXTUREARBPROC)
wglGetProcAddress("glActiveTextureARB");
glClientActiveTexture = (PFNGLACTIVETEXTUREARBPROC)
wglGetProcAddress("glClientActiveTextureARB");
}
else
{
MessageBox(g_hwnd, "This program requires multitexturing, which "
"is not supported by your hardware", "ERROR", MB_OK);
return false;
}
if (CheckExtension("GL_EXT_point_parameters"))
{
glPointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
wglGetProcAddress("glPointParameterfvEXT");
}
if (CheckExtension("WGL_EXT_swap_control"))
{
wglSwapIntervalEXT = (PFNWGLSWAPINTERVALEXTPROC)
wglGetProcAddress("wglSwapIntervalEXT");
}
if (!CheckExtension("GL_EXT_bgra"))
{
MessageBox(g_hwnd, "This program requires the BGRA pixel storage"
"format which is not supported by your hardware", "ERROR", MB_OK);
return false;
}
g_useTextureCompression =
CheckExtension("GL_ARB_texture_compression");
g_useEdgeClamp = CheckExtension("GL_EXT_texture_edge_clamp");
g_useSGISMipmapGeneration =
CheckExtension("GL_SGIS_generate_mipmap");
return true;
} As you can see, there are two extensions that the demo requires: multitexturing and BGRA pixel formats. Although I could have provided alternate ways to do both of these things, doing so would have unnecessarily complicated the program.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3