[GEM-dev] Re: GEM shader usage

[james tittle]

On Nov 22, 2005, at 5:12 AM, IOhannes m zmoelnig wrote:

> 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]).

...grrr...well, this platform gl discrepancy is a first for me!  But,  
it seems to work if I do:

outlet_float(m_outShaderID, (t_float)(unsigned int)m_shader);

...so we'll go with that until something breaks ;-)

> 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)

...yeh, that's kind of what I was thinking, tho I was thinking of  
using a [link< to indicate that it needs re-linking, because I assume  
that creating/destroying a compiled shader object will just recycle  
the same ID/GLhandleARB, and that'd be hard to detect if one changed...

...so, I'm not really familiar with dismantling a list  
programmatically, so can you point me to some example code?  I bet  
it's easy, and even tells ya how long the list is n'stuff ;-)  Even  
better, we don't need to have seperate vertex/fragment inputs to the  
linker, since they'll already be compiled;  all glsl_program will  
need to do is attach them to a program object, then link that  
object...so, I guess the message would better be [shader $1 ... $n<

...maybe I can get this going today?!?

james