[GEM-dev] shaders on 64bit systems
Mathieu Bouchard
matju at artengine.ca
Fri Dec 3 05:06:59 CET 2010
On Wed, 1 Dec 2010, IOhannes m zmoelnig wrote:
> - [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 :-(
If shader-IDs don't use all the bits in the GLuint, you may be able to
cast it to float the normal way... you just need to make sure it's always
less than 16777216.
If not, then could you fake it ? Make a table of all the existing IDs and
use ID-indices all over, instead of the IDs themselves. It's a bit like we
have symbols instead of strings.
> 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...
It's easier to just drop the reinterpret_cast. Note that if this were a
float being reinterpreted as an int and back, it wouldn't be a problem,
because the int format has no special values.
> 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 :-(
No, you don't need to turn it into symbols.
> ideas?
yes (sometimes).
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
More information about the GEM-dev
mailing list