[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