[GEM-dev] [glsl_program] getVariables() prob

[james tittle]

On Feb 28, 2006, at 4:47 PM, zmoelnig at iem.at wrote:

> Quoting james tittle <tigital at mac.com>:
>> ...my modem access atm doesn't allow me to get thru to cvs.sf.net   
>> (?), but I looked at your diff and see a variable m_wantLink(0)  
>> which  I don't have:  are we in sync on this file?
>
> well, i moved the actual LinkProgram() to be called from within  
> render() and not directly from the linkMess(). the linkMess() just  
> tells the [glsl_program], that at the next render cycle the objects  
> should be linked.
> probably this does not matter, however i wanted to be sure, that we  
> have a valid GL-context; the only moment we can be sure that there  
> is a valid GL-context is during one of the render()-function calls  
> (this includes postrender(), startRender() and so on)

...ok, just checked it out and it's working great on this end:   
thanks for the cleanup, I always forget and try to do c instead of  
using c++ features such as new[] and delete[] and...

>> easily in glsl, and it would likely have   
>> "gl_ModelViewProjectionMatrix" as an active uniform:  this is usually
>
> are there implicit active uniforms (which i don't have to declare  
> as such) ?

...there are a bunch of built-in uniforms (ex. gl_ModelViewMatrix,  
gl_LightSource[2].spotDirection), attributes (ex. gl_Color,  
gl_Normal), and varying (ex. gl_FrontColor, gl_TexCoord[])  
variables...any opengl state variable can be accessed with the  
reserved prefix "gl_*", and there's obviously some shared between  
vertex and fragment shaders, and some are just plain different...if  
you don't wanna get the orange book, grab the glsl spec:

http://opengl.org/documentation/oglsl.html

> PS: ben, the patch is really the one, jamie sent some weeks ago on  
> this list.
> however, i can send it tomorrow.

...I'm sending it to him again off-list...

back to other things,
jamie