james tittle wrote:
...picking up this thread again:
...I've now got [glsl_vertex] & [glsl_fragment] working (ie. loading and compiling), but am temporarily stuck at how to pass on the GLhandleARB (which is actually a void*) to [glsl_program]? In
hmm. looking in my glext.h and glew.h it says: typedef unsigned int GLhandleARB; /* shader object handle */
which would be very simple to handle (just like in [pix_multitexture]).
[pix_multitexture] I just used outlets with casts to t_float for the texture ID's, but I'm not sure how we should just pass a pointer to an opaque driver object (guess I need to re-consult IO's "how to write and external")...? Should it be auto-paired with a message, like [vertex GLhandleARB< ? This then would trigger an auto- registration of compiled shader objects in a kind of hash table, which would then be linked if something changed...then if linking goes ok, it would auto-discover the active Attrib and Uniform variables, and output a list of them to console (to remind the user/ programmer), but also set up named/numerical messages to accept...
yes, that sounds ok..
as for linking of the shaders (just an idea): how about sending 2 lists [vertexProg <v1> <v2> ...( and [fragmentProg <f1> ...( to the [glsl_program]; in the next render-cycle, the so changed program would automagically get recompiled and used (until someone sends other fragment/vertex-modules to the object)
if GLhandleARB is really a pointer, we could also abuse the "gpointer"-type (like the GemState-passing); however if the types are different on the platforms (which i doubt), a registration mechanism that can be called with symbolic id's would really be better.
...I figured this method would work better than trying to add some kind of stuff to GemState, because we'd be true to glsl's flexibility in linking...
yes, i agree that it would be better to _not_ add these programs to the GemState (it's already crowded, and it is hard to exchange data between gemchains)
mfg.asdr. IOhannes