[GEM-dev] Re: GEM shader usage

[IOhannes m zmoelnig]

james tittle wrote:

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

actually i don't think that this should ever happen. after all openGL is 
cross-platform per se.

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

i thought it more simpler: whenever the [glsl_program] receives a list 
of modules, it will recompile (but only in the next render-cycle, in 
order to be able to get a "full" program into it, before attempting to 
compile)

> 
> ...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, 

yes of course: a method for elements of type A_GIMME calls a function like
glsl_program::vertexPrograms(t_symbol*, int argc, t_atom* argv);
you can savely ignore the "t_symbol*" (it is just "vert_program" or 
whatever the method was); argv points to an array of #argc atoms; and 
you get the numbers out of each atom by atom_getint()

> 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 

oh, i thought that fragment and vertex-shaders are linked differently 
into the program; but now i see that both just call glAttachObjectARB()...

> attach them to a program object, then link that  object...so, I guess 
> the message would better be [shader $1 ... $n<

so that is fine!

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


probably (but i'll have to go to a concert right now)


mfg.asdr.
IOhannes