-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Well it seems that:
- by avoiding texunit 0 and (probably unnecessarily) 1, I have actually
resolved the weird interactions with [pix_snap]
- I still have stack underflows and overflows printed at each frame
which I'll investigate but it's probably not causing any "visible" issue
- What was still driving me crazy is that I didn't know that I have to
take into account that the texture size is actually the next power of two of the expected image size.
Since using [pix_texture] you don't have to worry about "padded" image size, AND since ALL glsl examples in Gem use 512x512 images, gently "avoiding" the problem, I naively thought that a MxN image used as a texture would simply have its M pixels spanning the [0,1] range in the x axis (and same for N on y).
Is there some "standard" way, some utility function or something, to deal with non-power-of-two size textures? or have I to explicitely write the calculations to get the correct coordinates? I think I can do that, but if I can have the machine do it for me I prefer that :)
use rectangle textures ([rectangle 1( to [pix_texture]).
even better: try the SVN trunk which tries to use normalized texcoords for all texture modes (rectangle, normalized) by setting up the GL_TEXTURE matrices accordingly. i haven't tested it with a shader, so i would be glad if you could do that.
fg,masdr IOhannes