-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks+aP4ACgkQkX2Xpv6ydvTo0gCg8ZixJUsawrohsWxmZ54Ei3N6 JykAoM4JyZl6YUV5sXhQnmfJzHqpWRRq =f5oO -----END PGP SIGNATURE----- _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list