As per another thread, I do feel there is a relationship to:
GLUtils.texImage2D( GL10.GL_TEXTURE_2D, 0, bitmap, 0);
involved as well. but to give a little example, this works in google
api 3:
glGenTextures() // allocate texture Ids
....
// prep an individual texture
glBindTexture( an id we got from glGenTextures()
GLUtils.texImage2D( GL10.GL_TEXTURE_2D, 0, bitmap, 0);
gl.glTexParameterf( GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_WRAP_S,
GL10.GL_CLAMP_TO_EDGE );
....
So, again, in 1.5 that works fine for all textures (total set is about
20 textures).
But in 1.6, about half of those textures end up rendering all white.
And if I enable debugging:
setDebugFlags( DEBUG_CHECK_GL_ERROR | DEBUG_LOG_GL_CALLS );
Then I get a GL check error in the call to
gl.glTexParameterf( GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_WRAP_S,
GL10.GL_CLAMP_TO_EDGE );
But I get that error for every texture, not just the ones that render
white with debugging turned off.
if I remove the texParameter call, then I get an error in whatever the
next thing I do with that texture handle is. But if I remove
the GLUtils() call, then I get no errors at all (but all textures are
white). But it doesn't complain about the handles.
So, it's like some calls to GLUtils.texImage2D() manage to corrupt
things enough to screw up subsequent calls. (though it's not the
source bitmaps, I can scramble those and the error tracks the texture
Id, not the bitmap)
But, others have complained about GLUtils, and the fact that the
GLUtil call generates no logging whatsoever makes me wonder if there
is some context violation there. (and maybe the gl error is just a
red herring due to GLUTil not going through the same wrapper code that
the debugging turns on.)
ANYWAY, since I had nothing better to waste two hours on in the sweaty
102 degree heat... I converted the code to load the pixels into
directallocated byte buffers and use the raw glTexImage2D function
instead. So now I don't use GLUtils at all, and...
it fails in exactly the same way.
Eventually I will be frustrated enough to return to api 3, I imagine.
But it's got to be something extremely simple.
- Dan
On Jun 3, 9:51 pm, Samsyn <d...@synthetic-reality.com> wrote:
> For what it's worth, I started having the identical problem this
> evening, after changing my app to use API4 instead of API3 (where the
> glGenTextures() was working fine)
>
> Now I get the exact same list of goofy texture Ids when I use my phone
> (Droid 2.1), but it's fine in the emulator.
>
> At first I thought maybe it was unhappy with an int[] and really was
> starting to insist on an IntBuffer, but nope...
>
> Now, API4 brings GL11 to play, and I am still using all the GL10
> constants, and
>
> setDebugFlags( DEBUG_CHECK_GL_ERROR | DEBUG_LOG_GL_CALLS );
>
> (which I also turned on this evening) is still giving me some other
> complaints... so I am going to work through those in the emulator and
> see if it fixes the glGenTextures() on its own. The emulator is just
> so painfully slow in GL, it's sort of a drag :-)
>
> And I really don't want to have to sift through for positive
> values.... my code is all clean and neat at the moment and I hate to
> bend it in that way...
>
> - Dan
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
