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

[james tittle]

On Feb 28, 2006, at 12:40 PM, IOhannes m zmoelnig wrote:
> you should never ever "clean up" a pd-symbol (like m_symname[i]);
> however, deallocating the m_symname-table (which only holds references
> to symbols) is fine.

...ok, this could be the prob...?

>> ...also, in getVariables() I've rearranged the order of free-ing
>> variables so that it occurs before we query the gl object parameters
>> (ie. before we reset m_uniformCount to it's new value), but this   
>> wasn't
>> the full answer...any other ideas?
>
> wow. that greyed some of my hair...
> took me till now to find it and it turned out to be a tiny "<="  
> instead
> of "<" in line-101.

...yeh, I fixed that in my previous commit (ie. from "<=" to "<"),  
but I guess my over-free()-ing was a problem:  typical problem of  
changing too many things at the same time?

> i did a lot of other changes which shouldn't affect the behaviour.
> now it works for me (i just committed it)

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

...also, good call on dropping m_name[]:  I didn't realize we were  
actually comparing paramMess()'s to m_symname[]!

> one last question:
> when loading the "Toon"-shader (dunno who sent it, i guess jamie),  
> i get
> active uniform variables like "gl_ModelViewProjectionMatrix" (apart  
> from
> the valid "Phong"); i have no idea where this comes from; anyone...?

...aha, at least something I can answer ;-)  On the one hand, the  
toon shader in cvs is an arb_program, not glsl...but you could do it  
easily in glsl, and it would likely have  
"gl_ModelViewProjectionMatrix" as an active uniform:  this is usually  
set up in the vertex shader and passed into the fragment  
shader...there are actually a whole host of built-in active uniform  
variables that have to do with different parts of gl's pipeline:   
check out the spec, the new red book covering 2.0, or the orange book  
for more info...I don't think these are designed to be manipulated by  
the user, but they could be...

> happy glsling

...well, it's certainly not a cure-all at present time:  I don't know  
if we're just dealing with early drivers or cards that have few pixel  
pipelines that are causing slower performance than expected...at  
least the groundwork is laid...now to get the rest of gem up to gl 1.5!

jamie