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