hey guys, here’s some code that’s been around since … well, for a while anyways:
http://www.opengl.org/resources/tutorials/sig99/advanced99/notes/node395.html
If I recall correctly strstr is very poppular approach in string checking. I’ve seen it in a lot of places, & I doubt it’ll mysteriously go away, though lets hope it will.
It’s bad that other OS’es returns not NULL…
BTW I’m still not convinced to add *.lib to project options + check for available *.dll or smthn else for other OS just to check extension string.
You’re right strstr is very popular for this kind of thing, it’s even used in the article idr recommended as doing “the right thing” TM.
http://www.gamedev.net/reference/articles/article1929.asp
Sqrt, you’re right about the crossbar thing getting resolved when put into the core, the spec was changed to say that invalid params produce undefined results instead of white, and obviously the extension string isn’t needed when the core version is sufficient.
@dorbie: but I only check for the extension string and not for the OGL version number. this is because most drivers provide their hardware supported extensions via the ext string in additon to the OGL version number. But if an extension is not provided in the ext string you could assume it is not supported in hardware and using it will hit a software pass (e.g., GL_ARB_clamp_to_border on GF4MX :mad: )…
@Hampel, that is the way it is supposed to work, however there have been examples in the past where this is explicitly not the case, and not just for beta exotic new stuff.
Originally posted by dorbie:
[b]You’re right strstr is very popular for this kind of thing, it’s even used in the article idr recommended as doing “the right thing” TM.
I didn’t read that article, but the following statement is in the section discussing extensions:
… One thing you need to watch out for, though, is accidentally matching a substring. For example, if you’re trying to use the EXT_texture_env extension, and the implementation doesn’t support it, but it does support EXT_texture_env_dot3, then calling something like:
strstr(“GL_EXT_texture_env”, extensionsList);
is going to give you positive results, making you think that the EXT_texture_env extension is supported, when it’s really not. The CheckExtension() function in the demo program included with this article shows one way to avoid this problem.
You will note that the CheckExtension() function does NOT use strstr, so I would not recommend that anyone use that method if they want to avoid bugs in their application as was first stated.
–tranders
P.S. Note that in the quoted example the author has inverted the strstr arguments and should read as:
strstr(extensionsList,"GL_EXT_texture_env");
Originally posted by Korval:
[quote]How about wglAllocateMemoryNV? This function doesn’t belong to any extension!!!
Yes, it does. It belongs to NV_vertex_array_range. Check the VAR spec.[/QUOTE]Well, take a look in wglext.h and you’ll see it belong to WGL_NV_vertex_array_range.
WGL_NV_vertex_array_range are not listed in WGL ext list returned from driver.
yooyo
Well, take a look in wglext.h and you’ll see it belong to WGL_NV_vertex_array_range.
The header is meaningless; the extension specification tells you where things come from.
tranders, sorry you’re right, I didn’t read the article either, I just did a quick grep for strstr without checking the context. My bad, still I’ve seen plenty of examples similar to mine.
You can use strstr, and I think glutIsExtensionSupported does. You just have to check that the string returned by strstr exactly matches the desired string. In terms of lines of code, this is about the shortest, correct (I haven’t actually tested this code, caveat emptor) function I can think of.
</font><blockquote><font size=“1” face=“Verdana, Arial”>code:</font><hr /><pre style=“font-size:x-small; font-family: monospace;”>GLboolean is_ext_supported( const char * ext_wanted, const char * ext_string )
{
const size_t len = strlen( ext_wanted );
while (ext_string != NULL) {
ext_string = strstr( ext_string, ext_wanted );
if ( ext_string != NULL ) {
if ((ext_string[len] == ‘\0’)
Yup, I forgot about extensions that doesn’t use fn’s, like: BGR, CUBE_MAP. There is no way but to parse string. After thinking more I can imagine why API check could have been dropped. Unfortunately there are some things that just can’t be fixed under OpenGL, usually they are ones that should have been there from the very beginning. I hope that this trend will never make GL too broken to fix.
However, I will skip extension test for things like GLSL (4 extensions), NV texture combiners etc. under Win32, as it seem to be overkill to do 4x check.
GLSL case:
the rigght way
1)Check GLSL support
2)Check SHO support
3)Check VSHO support
4)Check FSHO support
//get pointers
4)Check for NULLS
the wrong (my) way
//get pointers
1)Check for NULLS
Might get little bit more complicated when SHLANG 1xx comes out
Sigh…
GLboolean is_ext_supported( const char * ext_wanted, const char * ext_string )
{
const size_t len = strlen( ext_wanted );
while (ext_string != NULL) {
ext_string = strstr( ext_string, ext_wanted );
if ( ext_string != NULL ) {
if ((ext_string[len] == '\0') OR (ext_string[len] == ' ')) {
return GL_TRUE;
}
else {
ext_string += len;
}
}
}
return GL_FALSE;
}
Thanks that’s exactly what I am using for years now 
shouldn’t it be:
if ((ext_string[len] == '\0') OR (isspace(ext_string[len]))) {
Hample,
Using isspace would work, but the spec is clear that only spaces are used to separate extension strings. At the top of page 254 (page 268 of the PDF) of the 2.0 spec says:
The EXTENSIONS string contains a spec separated list of extension names (the extension names themselves do not contain any spaces).
Since it says “space separated” and not “white space separated”, it is safe to assume that only the ASCII space character is used.
Wow, how pointless was that thread?
Now I feel empty inside.
Originally posted by Tom Nuydens:
glIsExtensionSupported()? Oh puh-lease! We’re talking about 25 lines of code here :rolleyes:
I meant to say that it does not solve the problem of having to parse the extension string manually. Since it is an extension, you have to read it from the string and then init.
So, apps with fixed-buffers (which are crashing now) still crashes while apps wich manage the ext string correctly probably won’t use the extension at all.
As dorbie says, it’s redudant. I would also add that sometimes, some string cooking may be needed so, for example to split the string in substrings and compile (in the sense of showing) a list of supported extensions.
As for the extension-loading libraries, I don’t like them. More in general, I don’t want to link to external libaries unless they are hard to implement. For example, I use my own extension loading procedures but I happly link to libvorbis.
I raccomand everyone to have the ext-loading mechanism in the program and not in an extenral library. Sure it’s grunt work but someone must do it.
By the way, why this is in advanced?
Just use GLEW and be done with it (or one of the other extension loaders).
glewInit();
if ( GLEW_ARB_texture_env_combine )
// Do stuff....
This thread is not even beginner anymore, just a BS.
I wanted to know what’s professionals point of view in case of extension loading. That is is it viable solution to skipp ext string parsing if I must check function pointers later anyway.
ANSWER:
Yes I can if I use WIN32 as it allways returns nulls in case of unsupported extensions, from FM. Results can be that app may crash if ext is still in debug phase, or it may work fine even when string says it shouldn’t.
If I use Linux, MAC or something else, it might not work (must RTFM)
If extension doesn’t have functions then I must parse the string anyway.
Checking for GL ver number might kick you in the *** as NV supports GL1.5 but doesn’t have crossbar. Still If I would call for fn pointers I’d get them (I guess) & this stuff would work with one exception (if I have a bug in my program) output can get white which is not undefined as undefined may mean it can be red, mixed or nothing…