16
Support / Re: Replacing a texture leads to (Native memory leak)
« on: February 08, 2015, 06:40:35 pm »BTW: Log level should be debug, not just verbose.
Tried with both, wasn't sure which was most important
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
BTW: Log level should be debug, not just verbose.
But that's not the complete log or is it? It doesn't contain anything about uploading the new texture either. Both should happen during the next render pass.
_textureManager.unloadTexture(_buffer, _elementsTexture);
_elementsTexture = new Texture(_elementsImage);
_elementsTexture.setMipmap(false);
_elementsTexture.setGLFiltering(false);
_textureManager.replaceTexture(ELEMENTS_TEXTURENAME, _elementsTexture);
If it runs atIsn't there something missing?
Apart from that...maybe. Have you printed out the actual values that you are getting? You can always try to make the calculations on your own as doubles and only feed the result back into the SimpleVector for the translation. If accuracy is a problem, that might help. Another option is you blow up your complete scale by some factor, but depending on your scene setup, this might require some work...
_translation.set(_currentDirection);
_translation.scalarMul((_currentSpeed * time) / 1000f);
_object.translate(_translation);
Yes, vertices will be shared by default. You can disable it on an Object3D by calling disableVertexSharing();, but you have to create the mesh yourself then by using addTriangle or it will have no effect.If I had only known this (AKA read the javadoc before coding
Updating a texture is expensive in terms of performance. Are you actually creating new texture instances? In that case, consider to use an ITextureEffect implementation to update an existing texture instead of creating a new one.
Or use blitting from a texture that contains all letters to create your text output. Have a look at raft's GLFont class, that does a pretty good job with that.
:-[Many small ones sound better to me in this case, because you are only updating some of the text at a time, if i got that right. Is it possible that all 32 objects are visible at once? If not, then maybe you can pool the plane objects and won't need all 32 of them.
If you don't update the textures at runtime, one large one might be better. But as AGP already said: It's unlikely that it really matters.