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