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