Extensions?

[JD]

Got couple of questions for you guys:

1)Do you name your gl core function pointers the same as in sgi's gl specs or do you keep extension suffixes?

2)Do you prefer ARB/EXT over IHV extensions and why or why not?

3)Do you write you own gl/glext headers to include extensions from multiple IHVs?

4)Do you create a extension function loading library so you don't have to write function loading code ever again?

5)Do you check gl version then grab function pointer and check it for null or do you search extension string for the extensions supported on your card then grab function pointer?

Just wondering what others are up to

[marcus256]

1) I usually remove the extension suffixes - IF there are multiple extensions or functions that work the same way (e.g. multitexture can be ARB extension, or integrated into core GL 1.3+). That way I can use one code path for diffrent extensions, provided that they use the same tokens etc (check the token definitions in the include file(s) to see if they match).

2) Yes, ordered like this: ARB best, EXT OK, IHV last resort (of course it depends from case to case). In general, IHV extensions means having more code paths, less future compability and much more work reading up on several vendors specifications etc.

3) I use a modified version of the official glext.h file (modified becaues the official one does not support OpenGL 1.4 for instance). I have made it official, and you can find it here: http://hem.passagen.se/opengl/getstarted (click on GL Includes). It does not have all the most recent IHV definitions, but ARB_vertex/fragment_program + GL 1.4.

4) Have you seen Lev's library? When I work with small applications that only use a subset of all the extensions, I usually write a new extension loader (well, based on old code - just change the extensions and so on). I am a sucker for portability, so I tend to avoid peculiar extensions as long as I can, meaning that my extension loader is usually very compact.

5) Both. E.g (pseudo, error checking left out):

struct {
  PFNGLACTIVETEXTUREPROC ActiveTexture;
} my_gl_ext;
 
#define glActiveTexture my_gl_ext.ActiveTexture;
 
 
if OpenGL version >= 1.3
  my_gl_ext.ActiveTexture = glfwGetProcAddress( "glActiveTexture" );
else if has ARB multitexture
  my_gl_ext.ActiveTexture = glfwGetProcAddress( "glActiveTextureARB" );
else
  my_gl_ext.ActiveTexture = NULL;

[This message has been edited by marcus256 (edited 04-24-2003).]

[Tom Nuydens]

1) I keep the suffixes. You may get name clashes in your headers if you remove them (e.g. glBindProgramNV vs glBindProgramARB).

2) I prefer cross-vendor extensions, obviously, but that doesn't necessarily mean that they have to have the ARB/EXT prefix. NV_occlusion_query is a good example. I still use vendor-specific extensions if there is no better alternative.

3) Sort of, but see below.

4) Yes, and moreover I wrote a utility which can generate the glext header and extension loading library for me automatically by parsing the extension specification documents.

5) I check the extension string.

-- Tom

[PH]

1) See Tom's post.
2) See Tom's post.
3) I maintain my own with the extensions that I use.
4) As part of my glext.h file I have a function that loads and binds all the extensions.
5) I check the string ( and only use the extension(s) if all functions are exported with the correct names ).

I statically with with OpenGL 1.1 and use extensions for everything else ( that is, I don't load functions for 1.2, 1.3 etc if available ).

[marcus256]

Tom Nuydens, PH:

So you do not use the GL version at all, meaning that you assume that if a certain GL version is supported, all corresponding extensions are also exported? Is this safe?

Regarding extension suffix removal, I'd like to clarify that I only do that for very obvious cases, where the same functionality exists under two or more different names (e.g. ARB + core GL, or EXT + ARB + core GL), AND there are no other conflicts. It makes life so much easier when coding.

[Tom Nuydens]

Marcus, I never look at the GL version at all, and don't assume anything. If I want multitexturing, for instance, I look for the GL_ARB_multitexture string and retrieve the function pointers with the ARB suffix.

Technically this means that if a driver were to support GL 1.4, but not expose the GL_ARB_multitexture extension, my code would stop working. I don't think that's very likely to happen, though.

-- Tom

[PH]

Technically this means that if a driver were to support GL 1.4, but not expose the GL_ARB_multitexture extension, my code would stop working. I don't think that's very likely to happen, though.

Same here. Quake3 does pretty much the same thing ( I believe ). That is, it requires OpenGL 1.1 and uses (if present) extensions such as ARB_multitexture, EXT_compiled_vertex_array, etc.

[PH]

Regarding extension suffix removal, I'd like to clarify that I only do that for very obvious cases, where the same functionality exists under two or more different names (e.g. ARB + core GL, or EXT + ARB + core GL), AND there are no other conflicts. It makes life so much easier when coding

I do this only for EXT_texture3D where I define the functions and tokens with and without the EXT ending.

Edit: But the function pointer(s) that I retrieve from the driver are still the EXT version ( just in case ).

[This message has been edited by PH (edited 04-24-2003).]

[marcus256]

I agree that there is probably little or no chance of an extension being left out of a driver if the corrsponding functionality is supported thtough core GL functionality.

I also think that the whole concept of new OpenGL revisions is kind of "lacking edge" due to the situation with Microsoft, plus you can always (?) get the same functionality through extensions.

The good thing about new OpenGL revisions though are:

- IHVs are forced to support the same standard (and agree on that standard)
- You get a well defined "package" - you know that if you have this, you also have that
- It's much easier for a developer to slap on a "Requires OpenGL 1.whatever" tag than saying "Uh, you need this and that extension, in combination with this, OR this other combination over here, which incidentally seems to work well on this line of cards".

Currently I am working on something that might become a 64k demo (only the future will tell), and then it is much nicer to be able to say "requires OpenGL 1.3", and only check for GL version and then get all the necessary function pointers, without intermediate checks for different extension names etc. It saves space in two ways: less code for checking for extensions, and less overhead in the actual code since I only have to have a single code path (plus, I save three bytes per function name, since I use the core names ).

If you think about it, it is pretty much the same thing as saying things like "Requires DirectX x.y or higher", which about every DirectX program in the universe does (obviously, since they do not have extensions).

IMO, this is not a very bad method (checking for GL version, I mean), if IHVs supply up to date drivers with the latest GL versions. Even my NT4 station at work, with an Intel Brookdale-G accelerator, has OpenGL 1.3 (I never thought of Intel as an active OpenGL supporter).


[This message has been edited by marcus256 (edited 04-24-2003).]

[OneSadCookie]

1) I don't use extension function pointers; I program on the Mac When I have to use function pointers (eg for Windows or compatible Linux), I make very sure not to name them as the spec, usually adding a prefix to the name (so as to avoid static link clashes on Mac & Linux).

2) ARB by a long shot. Usually I won't consider an extension unless it's ARBed (or at least EXTed); particular cases (APPLE_client_storage, NV_point_sprite, &c) excepted, of course.

3) When writing cross-platform code I've been forced to write my own version of glext.h. Fortunately, I've never had to write cross-platform code that has to work with both NVidia & ATI cards

4) For cross-platform development, I've written an extension-loading library. It presents a nice enough interface, but boy is it messy under the hood!

5) Always check either the GL version or the extension string (whichever is appropriate for the symbol you're trying to load)! On the Mac, you'll often get a non-NULL function pointer for an unsupported function (it'll crash if you call it).