unloading texture

Started by raft, February 16, 2013, 05:21:38 AM

Previous topic - Next topic

raft

two things:

1. Desktop and AE behaves differently when unloading a texture.

TextureManager tm = TextureManager.getInstance();

tm.addTexture("box", new Texture("box.jpg"));
tm.unloadTexture(buffer, tm.getTexture("box"));
tm.addTexture("box", new Texture("box.jpg"));


this code creates an error on desktop, saying texture 'box' has been declared twice. it runs okey on AE

2. on Desktop, after removing/unloading and re-adding, we end up with a white texture

TextureManager tm = TextureManager.getInstance();

tm.addTexture("box", new Texture("box.jpg"));
tm.removeAndUnload("box", buffer);
tm.addTexture("box", new Texture("box.jpg"));




EgonOlsen

Two answers: ;)


  • I can't reproduce this. Looking into the code, jPCT-AE should raise the same error and in my test, it does. I've no idea why it shouldn't work and it's correct behaviour if it does.
  • The result depends on the driver. If this code is supposed to replace the texture of an Object3D, this is not how it's working. The manager is actually there to map names/textures to ids and gl "ids". If you remove a texture with a name and add another one with the same one, no object that had the old texture assigned to it will recognize this. They will still use the same old gl "id" as before even if the texture has been unloaded from the gpu. In most desktop drivers, this causes a white texture, which is actually fine. On Android, some drivers don't care and are still rendering using the old, now actually unbound texture. Or in other words: They are still using the same gpu memory as before even if it has been freed and not yet overwritten.

If you want to replace the content of a texture, use TextureManager.replaceTexture(...) instead.

raft

two+1 more then ;)

1. I guess not. Sky Maze uses that code since the beginning, still same behaviour if I didnt messed up the classpath

2. yes, as you described AE (on nexus 7) also ends up with white textures in this case

2+1. got the message. I should use TextureManager.replaceTexture(..). Indeed that code is in place but was commented out for some forgotten reason

thanks :)

raft

Quote from: EgonOlsen
I can't reproduce this. Looking into the code, jPCT-AE should raise the same error and in my test, it does. I've no idea why it shouldn't work and it's correct behaviour if it does.

rechecked the code, you are right, AE version checks for texture first, if exists replaces it