[GEM-dev] [glsl_program] getVariables() prob
james tittle
tigital at mac.com
Wed Mar 1 00:49:03 CET 2006
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
More information about the GEM-dev
mailing list