hi,
i'm currently debugging a problem with shaders on debian/64bit.
the problem shows as follows: - [glsl_vertex] opens a shader-file, compiles it, retrieves the shader-ID, converts it to t_float using reinterpretation cast (t_float/GLuint union) and sends it out - the shaderID shows as "0", [change] doesn't let it through, thus the shader is not linked and not run :-(
this happens with Gem as shipped with debian/sid (and debian/squeeze!, iirc)
if i compile it myself on the very same machine, the shaderID (GLuint)1 will translate to a t_float of approximately 1.4013e-45, which is distinct from 0, thus [change] let's them trough, and the shader works.
with some little debugging object that does the GLuint/t_float reinterpretation casts within the patch, i see that both times, the translation actually produces the correct result, however: - Gem-0.92.3/debian loaded: "1" -> ~0 - Gem-0.92.3/self loaded: "1" -> ~1.4013e-45
clearly this mainly a problem in debian's way to compile Gem (i guess some SSE-enable/disable/cleanup thing), though if anybody can illuminate me so i can fix it, i would be thankful...
otoh, it also shows that [change] is not good enough for detecting shader-changes. (even though Pd shows "0" for (GLuint)1, it seems like the number is only _very_ small (denormal - ha, that's probably the clue!), but still sufficiently distinct from the "0" produced by e.g. (GLuint)2...
so this means we probably do have to get rid of a numeric representation of the shaderIDs alltogether, and switch to a symbolic representation, which would break about all patches using shaders :-(
ideas?
fgmadr IOhannes