libgdx sprites show up as white blocks

OpenGL Development
#1

I’ve been busy making a new version of my ‘hyper-blazer’ game; ‘hyper-blazer 2’ if you will. This time with lots more eye-candy :slight_smile:

I’m using libgdx, which so far is great. Running on both desktop and android Just Works, awesome! :slight_smile:

I’m using 2 cameras; one for 3D and one for 2D.
First I render the 3D scene using the perspective camera, which works fine.
Then I switch to the ortho camera and use SpriteBatch to draw my overlays (virtual sticks for Android in this case).

Now the problem is that the textures I want to draw just show up as white blocks.
The problem is not the textures themselves; in a simple standalone test they show up fine.

I read that SpriteBatch requires a ‘clean’ OpenGL state, so I disable culling, lighting etc before using the SpriteBatch, but this didn’t seem to help.

Any hints?

#2

update: it seems the problem only appears with textures with alpha. Textures without alpha show up fine…

#3
  1. are your textures in a base 2 dimention? with some devices if you texture is not 128x128 or 256x256 etc… then they will be rendered in all white…
  2. make sure you have blending enabled… and set the correct blending func
  3. make sure you enabled texture 2d
#4

Thanks for your response!

  1. Yes, the textures are in base2 dimension. They show up fine in a small trivial test program, and I can also see these textures in the 3D scene.
  2. Blending is indeed enabled. Interestingly in my small test program I didn’t explicitly enable blending, yet the texture shows up fine still (and with blending).
  3. Texture2D is also enabled. Textures without alpha show up fine.

I guess I’ll have to check in the SpriteBatch source to see what it’s actually doing. I have the feeling there is something in my OpenGL state when I use SpriteBatch that it doesn’t expect, but so far I couldn’t deduce what it actually is that is screwing things up.

#5

Disable depth, disable alpha test, disable lighting, ensure that face culling is properly set, ensure that GL_TEXTURE0 is active, etc. Basically: check your states.

#6

it now looks like this:


        Gdx.gl.glDisable(GL10.GL_ALPHA_TEST);
        Gdx.gl.glDisable(GL10.GL_DEPTH_TEST);
        Gdx.gl.glDisable(GL10.GL_LIGHTING);
        Gdx.gl.glDisable(GL10.GL_CULL_FACE);
        Gdx.gl.glEnable(GL10.GL_BLEND);
        Gdx.gl.glEnable(GL10.GL_TEXTURE_2D);
        Gdx.gl10.glActiveTexture(GL10.GL_TEXTURE0);

        sprites.setProjectionMatrix(Engine.GLOBAL.cam2D.combined);

        sprites.begin();
        sprites.draw(texStick, recStickL.x, recStickL.y);
        sprites.draw(texStick, recStickR.x, recStickR.y);
        sprites.draw(texThumb, recThumbL.x, recThumbL.y);
        sprites.end();

…still just white blocks for the textures with alpha channel (or nothing at all)…
I’m a bit stumped, but I’ll check if I can get it to work without SpriteBatch and with straight openGL code.

#7

Do you cache the texture manually, for example on Map rather depends on Atlas cache? or you use AssetManager and called dispose() rather unload()?

#8

It turned out to be a general OpenGL issue that had nothing to do with SpriteBatch (a really stupid bug in my code in the way I binded textures), which I eventually found by putting LWJGL in debug mode.
Now all works fine :slight_smile:

Anyway, thanks for the responses.

#9

Strangely enough it only works the first time on android (on desktop it’s all fine).
When I start the game a second time without re-installing, no textures are rendered at all ??? (as if enabling textures is completely ignored; it’s all just coloured blocks)
If I re-install, it looks fine again…

#10

maybe it’s the time for you to post the code.

#11

Yes, well it’s a bit much code to post now, so I’ll first try to deduce the issue myself.
I’ll post when I’ve got something small that has the issue and I still can’t figure it out.

#12

Ok, found it.
My engine was a singleton implemented as an enum. It seems Android doesn’t necessarily re-initialize this enum when the app starts, so its state was all wrong the second run. Now I initialize the engine in the resize() method and all is fine now.

#13

What do you mean “reinitialize an enum”?

#14

Probably that static blocks aren’t run when Android reuses an existing VM to launch a new app.

#15

exactly that, yes
More specifically, the enum’s constructor wasn’t called again the second run; it was just reused, leaving the enum in the state it was when the previous run of the app was stopped.

#16

Ouch, I could see that biting me, since I also use the Holder pattern in my code for singletons. Or maybe not, since the singleton I’m statically initializing is literally a solid white texture ;D

#17

Yes, android has some gotchas to be aware of.
Another thing that bit me in the past is that static values can just be reset at any time, so for example a traditional singleton or a class with static values doesn’t really work in Android (not reliably anyway).