[GEM-dev] Re: GEM shader usage

[IOhannes m zmoelnig]

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