View Full Version : extensions
03-23-2004, 10:54 PM
what do you use to automatically load extensions?
i have been using glux, its pretty sweet code wise, installation on the other hand is a bit problematic... so im looking for another package to automatically load extensions for GL, ideas?
the good thing about glux also was that it autmatically supported all extensions...so something along these lines would be sweet
03-24-2004, 03:38 AM
My library, GLee (http://elf-stone.com/downloads.php#GLee) , supports Linux as well as Win32 and supports all registered extensions. There's version 3.03 binary and source tarballs for linux, or you can download the 3.04 source zip and compile it if you need ARB_fragment_shader_shadow.
03-24-2004, 03:55 AM
OK, I'm going to ask a dumbo n00b question here. :p
Why is this sort of extension handling necessary on Linux? In all the codes I've written I've used the relevant header file to define the prototypes, then just the linker sort the rest out. Seems to work fine. If nothing else it makes the code easier to read IMO.
So what's the advantage of using the getProcAddress or whatever it is, or some wrapper for it? Cross-platform portability? Or something else I'm missing?
The extensions are because they can be available or not depending on the situation. Say that in some particular system there's a nvidia hardware and in some other system there's an ati one and on third there's something else. The different hardwares have generally different capabilities which are exposed as different GL extensions. If you just link your app directly with the libGL.so you will have a problem when you wish your app to be runnable on the various systems. Get the point? On one system one particular extension's function may be available and so link with it directly, but on some other system the same function may not be available and your app wont run. So instead you'd better do a runtime check for a particular extension's availability and get it's fuctions addresses and then use them only if it's really available. Right?
glXGetProcAddress is used because a symbol may not be exported by libGL, but the driver may support the extension. For example, the standard libGL doesn't export symbols for ARB_vertex_blend (http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_blend.txt) , but the ATI driver support the extension. If you don't use glXGetProcAddress but do try to use that extension, your program won't even load. That's probably a bad thing. :) If you use glXGetProcAddress, your program will load, and you can test the extension string to see if the extension is supported.
03-25-2004, 04:18 AM
OK, that makes sense. None of the stuff I've written in the past required cross-platform or cross-hardware compatibility, which is why I've not had this problem (yet!) :)
But it's not cross-platform or cross-hardware that you have to worry about. It's cross-driver version. Imagine that you write for some feature in driver version N, and someone tries to run you program on version N-1, that doesn't have the feature. Your program won't load, and you'll look bad. Your program won't even have to opportunity to say, "I need feature XYZ, please upgrade your driver."
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.