hello, if things need to be broken, then i suggest not to change glsl_vertex, glsl_ etc, but to create other object. so the current patch will work with 32 bit system. and patch using this new objects will work with both 32 and 64 bits systems.
cyrille Le 01/12/2010 12:44, IOhannes m zmoelnig a écrit :
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 _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
_______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
