Libgdx rendering white instead of an image

[Ultroman]

Hey guys.

I was just getting excited about creating a tower defence game in libgdx, and everything was going well, but then I realized my backgrounds weren't being rendered correctly on my Samsung Galaxy S2 (Android 4.0.3).
They are replaced by nothing but white (with OpenGL 2.0 it gets all black instead). I clear with black color.
The towers, which are rendered in the same way just after the background, render just fine. The stage on top of it all also renders neatly.

The weird thing is that it all works and looks perfect on desktop (see image below).

What could be causing this?

I'm using TexturePacker to pack my png's, and batch.draw() to draw them.

[sproingie]

The desktop environment is a lot more forgiving, especially if you have an nvidia card.  How big are your backgrounds?  One common reason for a bad texture on a phone is that it's too big.

[Ultroman]

The desktop environment is a lot more forgiving, especially if you have an nvidia card.  How big are your backgrounds?  One common reason for a bad texture on a phone is that it's too big.

Really? Well, my background-texture is 2048x8192. It holds 6 different backgrounds. I thought I was being helpful to the system
Well, I'll split them up, and report back.

Thanks for the tip!

Games published by our own members! Check 'em out!

[Ultroman]

That was the problem! All fixed!

Thanks a lot!

I would've thought I would get some kind of error if the images couldn't load, but I got nothing.

[matheus23]

2048x8192.

Woah f**k... as soon as I read that I just hardly face-palmed... my head hurts...

But yeah, even some desktop environments only support texture with sizes up to 4096*4096...

[theagentd]

2048x8192.

Woah f**k... as soon as I read that I just hardly face-palmed... my head hurts...

But yeah, even some desktop environments only support texture with sizes up to 4096*4096...

OGL 4 supports up to 16k x 16k textures.

Batching the textures in your case probably won't win you anything at all. The main reason to combine smaller textures into atlases is to avoid having to bind textures between each draw call so you can batch them to improve CPU performance. For a fullscreen background, that texture bind is almost nothing compared to the GPU time it takes to actually render it, so it's definitely a premature optimization to say the least.

There is a way to check if your texture was loaded correctly but it's pretty much a simple hack. After calling glTexImage2D() and creating the texture, you can then read that texture's width or height and see if it's the correct value. If it's 0 (or was it -1?), that means it failed to load. Hacky, but it might be worth putting it into your Texture class to avoid the same problem again, especially on Android since it's only run at load time and of course almost free anyway.

[Ultroman]

There is a way to check if your texture was loaded correctly but it's pretty much a simple hack. After calling glTexImage2D() and creating the texture, you can then read that texture's width or height and see if it's the correct value. If it's 0 (or was it -1?), that means it failed to load. Hacky, but it might be worth putting it into your Texture class to avoid the same problem again, especially on Android since it's only run at load time and of course almost free anyway.

Well, I don't think that command is available to me in libgdx, but I could do something similar with my AtlasRegions I think. I might try that out later. For now, this is working perfectly.

I've packed all my backgrounds into 2 different images now, which are combined in an atlas-file. You're saying it won't give me much of a boost, which makes sense when the images are so big. The 2 packed images use up about 200kb more space than the separated background images (probably because of the extra transparent space), so is the minimal boost enough to merit this minimal increase in bulk?

[davedes]

There is a way to check if your texture was loaded correctly but it's pretty much a simple hack. After calling glTexImage2D() and creating the texture, you can then read that texture's width or height and see if it's the correct value. If it's 0 (or was it -1?), that means it failed to load. Hacky, but it might be worth putting it into your Texture class to avoid the same problem again, especially on Android since it's only run at load time and of course almost free anyway.

GL_INVALID_VALUE is generated if you try to use a width/height greater than GL_MAX_TEXTURE_SIZE. I think you are thinking of GL_PROXY_TEXTURE_2D.

The idea is that GL_MAX_TEXTURE_SIZE is a rough estimate, since you may be using different format and type parameters. So you can more safely check by loading a proxy texture first; then read back the width or height values with glGetTexLevelParameter -- if zero, it means the texture will fail.

Easiest thing to do is just ensure your textures are a reasonable size, no larger than GL_MAX_TEXTURE_SIZE.

LibGDX might have a utility for this already, but if not:

1   2   3

IntBuffer buf = BufferUtils.newIntBuffer(16); Gdx.gl.glGetIntegerv(GL10.GL_MAX_TEXTURE_SIZE, buf); int maxSize = buf.get();

I've packed all my backgrounds into 2 different images now, which are combined in an atlas-file. You're saying it won't give me much of a boost, which makes sense when the images are so big. The 2 packed images use up about 200kb more space than the separated background images (probably because of the extra transparent space), so is the minimal boost enough to merit this minimal increase in bulk?

At the expense of startup time (should be pretty speedy), you could pack your textures together on the fly. I believe LibGDX includes this in one of their TexturePacker utility classes.