Author Topic: TextureManager - removeAndUnload does not mean get rid off?  (Read 1648 times)

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Hi guys, i have problem with TextureManager,

I am lazy to remember which texture names I used and which I didn't, so I created a "safeLoad" which looks if such name exists and if yes, it unloads it. I am using the getTextureID method to find out if the texture exists or not, but i found out that following code can end in infinite loop... do you know why and what do I have to do differently to find out if the texture is still there or not?

Code: [Select]
while(TextureManager.getInstance().getTextureID(name)!=TextureManager.TEXTURE_NOTFOUND){
TextureManager.getInstance().removeAndUnload(name, AstroRenderer.getFrameBuffer());
};


Thanks,
Darai

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11775
    • View Profile
    • http://www.jpct.net
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #1 on: July 25, 2014, 11:19:04 am »
I'm not sure...it actually shouldn't cause this. How do you populate "name"? Have you tried to use containsTexture(<String>) instead?

May i ask, why you want to remove and unload textures? It's a common problem that people are using this to replace textures, which usually isn't the best idea.

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #2 on: July 25, 2014, 02:09:23 pm »
Well,

I am doing all loading and unloading through this code (I used here your suggestion and it helped, but there is still the issue fo the ID I am describing in the bottom of this post)

Code: [Select]
    public static void safeLoadTexture(String name, InputStream IS, boolean useAlpha, boolean force){
    Log.i("safeLoad","loading:"+name);
    if(force){Util.safeUnloadTexture(name);}
    if((force)||(!tm.containsTexture(name)))
    {tm.addTexture(name, new Texture(IS, useAlpha));}
    Log.i("safeLoad", "newID:"+tm.getTextureID(name));
    HashSet names = tm.getNames();
    Iterator itr = names.iterator();
      while(itr.hasNext()) {
         Object element = itr.next();
     Log.i("safeLoad", "names:"+(String)element);
      }
      System.out.println();
    }
   
    public static boolean safeUnloadTexture(String name){
    Log.i("safeUnload","unloading:"+name);
    boolean cleared = false;
    Log.i("safeUnload", "previousID:"+tm.getTextureID(name));
if(tm.containsTexture(name)==true){
tm.removeAndUnload(name, AstroRenderer.getFrameBuffer());}
    Log.i("safeUnload", "newID:"+tm.getTextureID(name));

return cleared;
    }

Funny part is that right after unloading, the texture manager still sees the texture like if it is still there, at least for the getTextureID method, a moment later it is all right, example is following CatLog from one run of safeUnloadTexture method:

Quote
07-25 07:51:23.962: I/safeUnload(1280): unloading:skydome.png
07-25 07:51:23.962: I/safeUnload(1280): previousID:6
07-25 07:51:23.962: I/safeUnload(1280): newID:6

I am afraid that this may cause some problems during my Texture selecting, because the new object in new scene can select a Texture which is beeing deleted in the same moment. I hope this makes sence.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11775
    • View Profile
    • http://www.jpct.net
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #3 on: July 25, 2014, 09:21:14 pm »
I can't verify this problem. I made myself a test case and it works just fine. You aren't executing this in a thread in parallel to the rendering, or do you (maybe in some touch event listener...)?
And you are using the latest version of jPCT-AE?

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #4 on: July 28, 2014, 09:47:11 am »
Hmm...

Ok, I downloaded the newest JPCT-AE... i had the version 14/05... but it didn't helped.. I am running this command in the onDrawFrame() thread in the renderer, is that correct?

Another thing that could cause this is that I see the problem on the emulator, I can and will werify today if the same problem is also on the real Android device.

Thanks,
Darai

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11775
    • View Profile
    • http://www.jpct.net
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #5 on: July 28, 2014, 12:36:43 pm »
Yes, onDrawFrame seems like a good place to do it. Can you create a test case, that shows the problem? I can't somehow...

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #6 on: July 28, 2014, 03:10:39 pm »
Uff,

I was affraid I will not be able to create one, but at the end I succeeded and it still has the same behaviour, so here is the example:
Code: [Select]
package com.example.loadunloatest;

import java.io.IOException;
import java.io.InputStream;
import java.util.HashSet;
import java.util.Iterator;

import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;

import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.util.Log;

import com.threed.jpct.FrameBuffer;
import com.threed.jpct.RGBColor;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;

public class MainActivity extends Activity {

private GLSurfaceView mGLView;
private MyRenderer renderer = null;
private static FrameBuffer fb = null;
private World world = null;
private RGBColor back = new RGBColor(50, 50, 100);
private boolean loadTest = false;
public static TextureManager tm;
public static MainActivity act;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(getApplication());

mGLView.setEGLContextClientVersion(2);

renderer = new MyRenderer();
mGLView.setRenderer(renderer);
setContentView(mGLView);

tm = TextureManager.getInstance();
act = this;
}
class MyRenderer implements GLSurfaceView.Renderer {

public MyRenderer() {}

public void onSurfaceChanged(GL10 gl, int w, int h) {
Log.i("onChange",">>>>>>>");
world = new World();
if (fb != null) {
fb.dispose();
}
fb = new FrameBuffer(w, h);
try {
MainActivity.safeLoadTexture("tex",act.getAssets().open("pom.png"),false,true);
} catch (IOException e) {
e.printStackTrace();
}
}

public void onSurfaceCreated(GL10 gl, EGLConfig config) {}

public void onDrawFrame(GL10 gl) {
if(!loadTest){
Log.i("onDraw",">>>>>>>");
try {
MainActivity.safeLoadTexture("tex",act.getAssets().open("pom.png"),false,true);
} catch (IOException e) {
e.printStackTrace();
}
loadTest = true;
}
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.display();
}

}
    public static void safeLoadTexture(String name, InputStream IS, boolean useAlpha, boolean force){
    Log.i("safeLoad","loading:"+name);
    if(force){safeUnloadTexture(name);}
    if((force)||(!tm.containsTexture(name)))
    {tm.addTexture(name, new Texture(IS, useAlpha));}
    Log.i("safeLoad", "newID:"+tm.getTextureID(name));
    HashSet names = tm.getNames();
    Iterator itr = names.iterator();
      while(itr.hasNext()) {
         Object element = itr.next();
     Log.i("safeLoad", "names:"+(String)element);
      }
      System.out.println();
    }
   
    public static boolean safeUnloadTexture(String name){
    Log.i("safeUnload","unloading:"+name);
    boolean cleared = false;
    Log.i("safeUnload", "previousID:"+tm.getTextureID(name));
if(tm.containsTexture(name)==true){
tm.removeAndUnload(name, fb);}
    Log.i("safeUnload", "newID:"+tm.getTextureID(name));

return cleared;
    }
}

On my PC Win7 + Emulator it shows this CatLog:
Code: [Select]
07-28 09:01:03.058: I/safeLoad(1365): loading:tex
07-28 09:01:03.058: I/safeUnload(1365): unloading:tex
07-28 09:01:03.058: I/safeUnload(1365): previousID:-1
07-28 09:01:03.058: I/safeUnload(1365): newID:-1
07-28 09:01:03.058: I/jPCT-AE(1365): Loading Texture...
07-28 09:01:03.068: I/jPCT-AE(1365): Texture loaded...16384 bytes/64*64 pixels!
07-28 09:01:03.068: I/safeLoad(1365): newID:1
07-28 09:01:03.068: I/safeLoad(1365): names:tex
07-28 09:01:03.068: I/safeLoad(1365): names:--dummy--
07-28 09:01:03.068: I/onDraw(1365): >>>>>>>
07-28 09:01:03.078: I/safeLoad(1365): loading:tex
07-28 09:01:03.078: I/safeUnload(1365): unloading:tex
07-28 09:01:03.078: I/safeUnload(1365): previousID:1
07-28 09:01:03.078: I/safeUnload(1365): newID:1
07-28 09:01:03.078: I/jPCT-AE(1365): Loading Texture...
07-28 09:01:03.078: I/jPCT-AE(1365): Texture loaded...16384 bytes/64*64 pixels!
07-28 09:01:03.078: I/safeLoad(1365): newID:1
07-28 09:01:03.078: I/safeLoad(1365): names:tex
07-28 09:01:03.078: I/safeLoad(1365): names:--dummy--

So there is still the part: previousID:1, newID:1 (After the call from the onDrawFrame()), which means that it can detect the texture after it was unloaded in the safeUnloadTexture method... If I am right.

Thanks a lot EgonOlsen,
Darai.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11775
    • View Profile
    • http://www.jpct.net
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #7 on: July 28, 2014, 09:45:51 pm »
Thanks for the test case. I'll have a look at it tomorrow.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11775
    • View Profile
    • http://www.jpct.net
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #8 on: July 29, 2014, 05:41:11 pm »
I still can't verify this problem. My output reads like this:

Code: [Select]
07-29 17:38:12.528: I/safeLoad(8832): loading:tex
07-29 17:38:12.528: I/safeUnload(8832): unloading:tex
07-29 17:38:12.528: I/safeUnload(8832): previousID:-1
07-29 17:38:12.528: I/safeUnload(8832): newID:-1
07-29 17:38:12.528: I/jPCT-AE(8832): Loading Texture...
07-29 17:38:12.528: I/jPCT-AE(8832): Texture loaded...1024 bytes/16*16 pixels!
07-29 17:38:12.528: I/safeLoad(8832): newID:1
07-29 17:38:12.528: I/safeLoad(8832): names:tex
07-29 17:38:12.528: I/safeLoad(8832): names:--dummy--
07-29 17:38:12.528: I/onDraw(8832): >>>>>>>
07-29 17:38:12.528: I/safeLoad(8832): loading:tex
07-29 17:38:12.528: I/safeUnload(8832): unloading:tex
07-29 17:38:12.528: I/safeUnload(8832): previousID:1
07-29 17:38:12.528: I/safeUnload(8832): newID:-1
07-29 17:38:12.528: I/jPCT-AE(8832): Loading Texture...
07-29 17:38:12.528: I/jPCT-AE(8832): Texture loaded...1024 bytes/16*16 pixels!
07-29 17:38:12.528: I/safeLoad(8832): newID:1
07-29 17:38:12.528: I/safeLoad(8832): names:tex
07-29 17:38:12.528: I/safeLoad(8832): names:--dummy--

..as you can see, i have a newID:-1 after removing the texture...just like it's supposed to be. And looking at the engine's code, i fail to see any reason why it shouldn't behave this way...
Are you sure that you are using the latest version of jPCT-AE? Please add a log output of Config.getVersion() to see what that returns.

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #9 on: July 30, 2014, 09:29:33 am »
All right,

now I expect that I have an old version, even though I downloaded it 2 days ago from the page
http://www.jpct.net/jpct-ae/

I did the config thing you recommended, it says that I have version 1.28... Where can I find which is the most current version? Ok, I found here in forum your link with the version 14/07/30... but can I (next time) verify the version somewhere without downloading the file and comparing size/date/Config.version?

Code: [Select]
07-30 03:19:48.641: I/onDraw(1487): >>>>>>>
07-30 03:19:48.641: I/safeLoad(1487): loading:tex
07-30 03:19:48.641: I/safeUnload(1487): unloading:tex
07-30 03:19:48.641: I/safeUnload(1487): previousID:1
07-30 03:19:48.651: I/safeUnload(1487): newID:1
07-30 03:19:48.651: I/jPCT-AE(1487): Loading Texture...
07-30 03:19:48.651: I/jPCT-AE(1487): Texture loaded...16384 bytes/64*64 pixels!
07-30 03:19:48.651: I/safeLoad(1487): newID:1
07-30 03:19:48.651: I/safeLoad(1487): names:tex
07-30 03:19:48.651: I/safeLoad(1487): names:--dummy--
07-30 03:19:48.651: I/onDraw(1487): JPCTVersion: 1.28
Thanks,
Darai.

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #10 on: July 30, 2014, 09:33:02 am »
SUCCESS, with the new file 1.29 it works fine, so it was because of the version, thanks for all the effort. A pro po, I have some hints for people fighting with algebra and vectors and spaces I would like to post. Can you recommend a good thread I can post it into?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11775
    • View Profile
    • http://www.jpct.net
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #11 on: July 30, 2014, 10:09:37 am »
I see...i wasn't aware that the fix wasn't part of 1.28 already but only of the current beta.

About the math stuff: The wiki seems to be a better place for this. If that's ok for you, i can create you an account and you can add some page to Code Snippets or some other section.

Offline Darai

  • byte
  • *
  • Posts: 45
    • View Profile
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #12 on: July 30, 2014, 11:52:38 am »
Hmm...

To be blunt, I don't feel like the big expert for this... sure, I am a little bit programmer and little bit mathematician, but with BIG but. That is why I hoped that I will post it to a thread and after some corrections from the proper programmers or math gurus it could be transformed into a proprer wiki page. But if you prefer me to write a prototype of such a wiki page and let the people to do the corrections directly there, I am with you so go for it.

Darai.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11775
    • View Profile
    • http://www.jpct.net
Re: TextureManager - removeAndUnload does not mean get rid off?
« Reply #13 on: July 30, 2014, 09:40:58 pm »
I've send you an account for the wiki. You might want to start a new page without any links from the main page, if you are unsure about the results. We can then have a look at the page and decide if it needs some additional work and where to put it.