On Jan 12, 2004, at 12:48 PM, ben@ekran.org wrote:
I still don't understand pix_texture "mode 0" though, since I also can't get live video to texture on OSX without it. (geforce cards perhaps?)
"mode 0" is power-of-two texturing where the texcoords are in the range 0..1. "mode 1" is for rectangle textures with texcoords from 0..height and 0..width. that's why using 'mode 1' results in the 'One Big Pixel Syndrome'. only a few objects accept the rectangle coords like square, rectangle and cube, and because pix_texture doesn't know which Geos come after it, there is no way to automagically set this flag. a name change might clarify what the flag does. 'texture type ?' 'texture mode ?' ????
Ah I understand now, Thanks Chris for taking the time to explain it. Now it makes sense. Would we alias one mode for one texture and the other mode for another? pix_texture as 2^x and pix_texture_rect as rectangular textures? Or a method selector for pix_texture could be "rect 1/0" I suppose part of the root of this is that it should be stated in the pix_source helpfile if the output is rect or 2^x . Only pix_film pix_video output rect textures curretly is this correct?
the only way to fix this is to rewrite all of the glu based objects like sphere and cylinder to accept whatever coordinate range defined by pix_texture and not assume that it will always be 0..1. i plan to do this in the near term, and will roll it into the vertex array stuff as well. a nice thing about using arbitrary texcoord ranges is that the entire surface is covered by _any_ size texture and there are no more black gaps caused by subtexturing.
This sounds like the best long-term solution to me, I've had a few headaches with black areas using non 2^x textures. Right on on linux it seems that if the texture is 2^x then those pixels are dropped into a 2^x frame that coveres the whole texture, leaving black, or when switching between 2^x and non 2^x remnants of the last texture... :(
Thanks again Ben
cgc
Thanks for the compliment.
B.