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).
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.
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.
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.
I keep the suffixes. You may get name clashes in your headers if you remove them (e.g. glBindProgramNV vs glBindProgramARB).
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.
Sort of, but see below.
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.
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.
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.
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).]
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).]
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).
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.
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
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!
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).
I will only answer to 5, since the rest is obvious.
I DO check the version number and have functions that load needed functions.
Message(“You drivers are inconsistent. Some OpenGL functions are missing.”);
if you have 1.1, it aborts without checking extensions.
I think people with 1.1 have an outdated hardware. Even if you have 1.2, it is most likely outdated. Some vendors release 1 or 2 updates and then stop.
And I dont know if you people knew this, but all the recent Intel, SIS and other crappier cards offer texture_env_combine. Not bad!
Also, if you check for extensions, be sure to check for ARB and EXT versions since on some cards, one or the other is missing.
Thank you all for your answers. Currently I’m doing what Tom N. is doing except I copy extensions by hand. I think I read that Ati still exports gl 1.3 version instead of 1.4.
Should I name my gl arb functions by the sgi gl specs docs but check the extension string? Or should I just use suffixes on everything to make things consistant with EXT/IHV way of things.
So you guys prefer ARB over EXT/IHV. I feel the same way that’s why I asked about it. I prefer simplicity in already complex code base.
Edit: Just thought of something, if I were to usg gl spec’ed name then when new gl version comes along I would have to go back to my code and remove the suffixed name now that the ext. made it into the core. I think I will stick with suffixed names though I have to remember to prefix the names when looking thru sgi gl specs. I’m I correct that promoted to core extensions don’t differ at all, it’s just a name change right? I haven’t had enought exts. exposure to make sure it isn’t. Thanks
[This message has been edited by JD (edited 04-24-2003).]
Originally posted by OneSadCookie: 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).
Can’t you do it the way I hinted in the pseudo code snippet above, i.e. place all function pointers in a struct (makes sure that you will not have any naming/linking conflicts), and then “#define glFunction my_struct.Function”. Perhaps that’s more or less what you are doing?