This happens on both Win32 and Solaris9, so I suspect it's not a driver problem. If anyone can suggest anything wrong with my texture loading code, I'd appreciate the feedback. Note that this code is overriding all mipmap data to be white pixels, and I'm still seeing the unexpected 'red'.

If anyone can explain to me how to attach a screen grab here, I'll happily show what I'm seeing.

I don't have a lot of time to figure it out for sure. But the one thing that is jumping out to me is that the buffer is ARGB which is 4 byts, not 3. Thats unless you set up your buffered image to be backed by a sperate alpha raster, which is unlikely.

Check out my TextureLoader in the Xith3D project (com.xith3d.loaders.texture.TextureLoader) and the DirectBufferedImage in com.xith3d.image.

If might be somethig like that. The 'input' BufferedImages are all TYPE_INT_ARGB. I don't care about the alpha channel, so I'm trying to discard it and only give the RGB bits of the data to JOGL in a direct ByteBuffer where the data is laid out RGBRGBRGB... etc.

This is working nicely for all the 'large' mipmap levels 128x128,64x64,32x32 etc, but seems to break for 2x2 and/or 1x1.

If I change this to give JOGL the full RGBA data (and change the code to specify GL_RGBA) I get no corruption. I don't see why the first approach doesn't work though, and I'd prefer not to be incurring a 33% overhead on my texture storage.

If the input buffered images are ARGB then you either have to convert them to RGB or send the data to the card as ARGB. To convert them, just create a buffered image of RGB then write into it from the other.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org