Mipmap creates black texture?

Started by Irony, February 09, 2014, 10:38:32 PM

Previous topic - Next topic

Irony

I did setMipmap(true) after loading a texture. Strangely, it turned out black then. I don't get this - isn't mipmapping turned on by default anyway?

EgonOlsen

Yes, it's true by default. I don't see why it should create a black texture. Changing the mipmap setting does trigger a new texture upload, but that shouldn't matter if you are dping this right after creating the texture. Make sure to use the latest release, because it changes the default way in which mipmaps are being created. Also make sure that you aren't using a texture that's not square when you are in OpenGL ES 2.0 mode.

Irony

The black textures are actually non-square. Will try if changing that helps.
But, I am using the latest version and call setMipmap right after loading, so it's still a mystery anyway...

By the way, do you know of any way to detect if a device cannot display non-square, so I can add square ones as a fallback? I'd prefer not to make all textures square per default, e.g. with planet textures that would be very impractical.
And can the blackness also happen to textures that are only used for blitting?

EgonOlsen

That black texture issue is out of the scope of the engine and not limited to any kind texture usage. The problem is that for ES 2.0, there seems to be a lack of definition on how to handle these textures, so the gpu/driver implementation is free to screw it up.
From my experience, it's safe to use textures where width>height but width<height will cause problems (or maybe it's the other way round...i don't remember exactly ATM).

Irony

Thanks Egon. I only have width>=height, and I tested it on devices with a nice bandwidth of the big GPUs brands. It always worked, with the exception of this weird case on the top. So I guess it should be pretty safe. The game won't run on old or exotic devices anyway.