[PD] [GEM-dev] gl stack underflow

[IOhannes m zmölnig]

-----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-----