Originally posted by Humus: This is not an especially good idea. If it’s in the driver but isn’t exposed there’s probably a good reason for that, most likely not completely implemented yet and/or not working.
Good point, but that should only be an issue on beta drivers. Publicly released ones should be fixed up … and if their not … kaboom!
I’m currently using the very same method as zecken.
The way I did it is I created some global functions for extension groups. For example if you want multitexturing, I call
GetMultitexturingExtensions()
And it tries to get all the relevent function pointers and returns error flags.
Originally posted by Humus: This is not an especially good idea. If it’s in the driver but isn’t exposed there’s probably a good reason for that, most likely not completely implemented yet and/or not working.
Might be, I don’t know.
EXT_texture_3d on a Geforce 2 could be one of these cases if glTexImage3DEXT is exported by the driver.
I didn’t have to deal with these cases so far. I’ll think about it
Oh, and if it’s not working at all, why should it be in the export table? There may be cases like this but they’re probably temporary solutions that get fixed with a driver revision. Which is exactly where the responsibility lies, I think.
[This message has been edited by zeckensack (edited 10-25-2002).]
The only way this validator could fail is if an extension name is above 128 characters…and that will NEVER happen. The only thing this validator doesn’t do is search for tabs, linefeeds and carriage returns. As far as I know the extensions are suppose to be seperated by single spaces ’ ’ not white space.
sNameString is where the extension name is stored. It’s checked to see if it’s matched with sext. sext is the extension name you provide.
If querying glGetString is slow, then my method is slow…oh well .
Der, I could pass the pointer returned by (S3Dchar*)glGetString(GL_EXTENSIONS) to a char data type pointer. In that case my validator would be full proof and fast.
[This message has been edited by WhatEver (edited 10-26-2002).]
[This message has been edited by WhatEver (edited 10-26-2002).]
I initially wrote something very similar to your code, but then got paranoid about extensions that have some odd PRE-fix. You can easily add that by testing the character before the match, unless the match is the first character of the input string. Add these special cases and you end up with what I posted
Also, whitespace means tab, return, space, horizontal tab and linefeed… unless by the ambiguous word “space” they mean literally the ASCII character with value 32 (decimal).
Originally posted by jwatte: Also, whitespace means tab, return, space, horizontal tab and linefeed… unless by the ambiguous word “space” they mean literally the ASCII character with value 32 (decimal).
They don’t. I’ve had problems with Wildcats that turned out to be due to newline characters in the extension string. In fact, they’re the only cards I’ve ever encountered with more than one whitespace character between extensions and/or with whitespace at the start of the extension string.
They also expose the imaging subset as “ARB_imaging” instead of “GL_ARB_imaging”, but I imagine not too many people are going to lose any sleep over that one
Originally posted by zeckensack: Oh, and if it’s not working at all, why should it be in the export table?
Well, the driver team needs them for testings. The only really “safe” method is to check the extension string.
The way I do things is to have one huge function in a glExtensions.cpp file I share between projects that initalizes every extension I’ve decided to add to it. Like this:
I initially wrote something very similar to your code, but then got paranoid about extensions that have some odd PRE-fix. You can easily add that by testing the character before the match, unless the match is the first character of the input string. Add these special cases and you end up with what I posted :-)[/b]
Hmm, that’s true, but probably not very common though. Maybe if someone creates a GL_GL_EXT_blabla extensions or something it might fail.
Hmm okay, let’s not turn this into a “My ext loading code is bigger than yours” contest. Btw, mine handles leading spaces and multiple spaces, and can properly seperate GL_funky from GL_funky_too
ahem
The purpose of these snippets in the context of this thread would be to demonstrate that you can at least recognize and use exts without ever copying the extension string to another buffer. Which is why I personally don’t mind big and littered extension lists. Shouldn’t cause a clean app any trouble.
This of course kind of nullifies the point of removing extensions (or not introducing new core features as extensions).
No problem -> no solution required. At least that’s how I feel about it.
> Oh, and if it’s not working at all, why
> should it be in the export table?
Because most vendors write ONE GL driver for MANY different products. Suppose the GF2 and the GF3 both use the same OpenGL DLL. The export table clearly needs to contain all the GF3 functions, but the driver can choose to publish only extensions for what it wants to expose at run-time.
Some control panels even contain check boxes for which extensions to export (such as KTX_buffer_region).
Originally posted by jwatte: Some control panels even contain check boxes for which extensions to export (such as KTX_buffer_region).
That’s probably because the driver needs to do some behind the scene job for such extensions, so it could be for efficiency or something.
Otherwise, there’s no point in giving the option to swicth it off.
The question is, if it’s not advertized in GL_EXTENSION, does GetProcAddress return a valid address. Is searching for a string really important if you can just use GetProcAddress?
Originally posted by mcraighead: You must check the extensions string to write a correct application.
How do you check for wglGetExtensionsStringEXT & wglGetExtensionsStringARB ?? I currently do it by checking if wglGetProcAddress returns NULL or not.
I know I’m lazy, but I also do this for wglSwapIntervalEXT. What are the chanses for my code failing if wglGetProcAddress(“wglSwapIntervalEXT”) returns a proper address, and I call the function?
Originally posted by marcus256:
[b] How do you check for wglGetExtensionsStringEXT & wglGetExtensionsStringARB ?? I currently do it by checking if wglGetProcAddress returns NULL or not.
I know I’m lazy, but I also do this for wglSwapIntervalEXT. What are the chanses for my code failing if wglGetProcAddress(“wglSwapIntervalEXT”) returns a proper address, and I call the function?
[/b]
This is an exception from the rule, as stated by the spec:
Applications should call wglGetProcAddress to see whether or not wglGetExtensionsStringARB is supported
For other WGL extensions though you’ll have to call wglGetExtensionsString and parse it like you’d do with normal extensions.
Originally posted by jwatte:
[b]> Oh, and if it’s not working at all, why
> should it be in the export table?
Because most vendors write ONE GL driver for MANY different products. Suppose the GF2 and the GF3 both use the same OpenGL DLL. The export table clearly needs to contain all the GF3 functions, but the driver can choose to publish only extensions for what it wants to expose at run-time.
Some control panels even contain check boxes for which extensions to export (such as KTX_buffer_region).[/b]
NVIDIA drivers will generally not expose extension functions through wglGetProcAddress() if the corresponding extenion is not supported, even if such functions are present (for other devices) in the unified driver. I wouldn’t rely on that behavior, though.
Vulpine has released a patch for their GLmark benchmarking utility that allows it to be compatible with the upcomming NV30. The NV30 specific update:
Extension Strings longer than 2048 Bytes are now allowed (required for NV30 compatibility)
You can almost believe that it’s a feature they added or something. Why didn’t they just tell they fixed a mammoth bug in their app?
Tell me they didn’t simply replaced "char [2048] by “char [4096]”.
