On Apr 18, 2007, at 3:06 AM, IOhannes m zmoelnig wrote:
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.
Perhaps this is not surprising, but this sounds good to me :). What
would the disadvantages be? It would make Gem behave like the bulk
of libs (minus pdp, pidip, msd, or any others that are optionally
linked into one dll). That would also help with the couple of
remaining name conflicts in Gem, like scale, curve, etc.
.hc
mfga.sdr IOhanes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli