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
