Miller Puckette wrote:
Thanks Chris,
I assume it's all the "shader" functions and dlopen() is only reporting the first one before giving up. I sure wish there were a way only to disable Gem objects using the "shader" extension or even better find out how to get the extension installed on generic hardware...
well i am dreaming of 2 things to solve this:
- use GLEW (which does dynamic (runtime) checking of openGL-extensions
and uses them if possible); chris already had a version of Gem for windows compiled against GLEW, unfortunately there were now checks done to ensure that the used driver actually understood the library calls....basically this means that Gem loads (in w32 land) with whatever openGL-lib installed, but as soon as you are actually using one of the more advanced stuff which happens to be unsupported by your drivers (e.g. shaders) this will crash. it would take some work to not only use the GLEW functions stubs but also to check whether the calls are supported; i guess this work is rather easy but dull
- split Gem into a core library (with almost no objects and
dependencies) and a whole bunch of single-object externals. so if the [glsl_vertex] object uses calls unknown to your driver, this object will refrain from loading but it won't hinder Gem from working.
mfga.sdr IOhanes