textures are gone after some time

[raft]

hi,

i've adapted new version of jPCT to karga. (not online yet) and been playing with mipmapping and multi threading. multi threading definetely increases fps one multi core machines mipmapping works almost identical to previous external MipMapper and i guess performs slightly better. and of course much easier to use. great job

however after some time, some of my textures are gone. it's like we have added an object with a missing texture. below are two shots:



i cannot regularly reproduce it, but i can say it happens with multi cores, mipmapping enabled and MOSTLY while resizing the window (creating a new FrameBuffer). i guess it's a multi-threading issue

any ideas ?

r a f t

[EgonOlsen]

Strange...i'm pretty sure that it's a multi-threading problem. I just can't figure it out ATM. Obviously, the textures are there, just blank. Because otherwise, it would give you a null pointer or similar. Are you by any chance getting some messages like "Could not grab pixels from image!" or something similar?

[raft]

i've just retried it, it happened again and no, nothing is printed.

[EgonOlsen]

Does it go away without multi threading and/or mip mapping used?

[EgonOlsen]

And are you calling dispose() on the old framebuffer and/or are disabling the renderer on it before it goes out of scope when creating a new one? If not, please add that. If it still doesn't help, please give this jar a try: http://www.jpct.net/download/beta/jpct.jar

[raft]

it happened single threaded and mipmapping disabled :/

are both FrameBuffer.dispose and disable renderer necessary ? looking at the code, i call most of the time dispose but not disable renderer..

[raft]

onfortunately neither helped. i also tried the new jar. i dispose the buffer with:

Code Select Expand

        buffer.disableRenderer(IRenderer.RENDERER_SOFTWARE);
        buffer.dispose();
        buffer = null;


maybe this may give you a clue: once this happens, recreating the buffer doesnt help, missing textures remains missing..

[EgonOlsen]

Are you using that advanced blitting method (that one what supports scaling and such)? It looks like as if somehow the textures are replaced by the dummy texture. Can you replace the dummy texture with something else (for example a Texture with the word "dummy" on it) by using setDummyTexture(<Texture>) in the TextureManager to see, if this really is the dummy texture or something else!?

[raft]

no, i do not use blitting at all. i'm happy with swing for such things

it's definetely the dummy texture, i replaced the dummu texture with:

Code Select Expand

    BufferedImage image = new BufferedImage(256, 256, BufferedImage.TYPE_INT_ARGB);
    Graphics2D g2d = image.createGraphics();
    g2d.setColor(Color.WHITE);
    g2d.fillRect(0, 0, 256, 256);
    g2d.setColor(Color.BLACK);
    for (int i = 0; i < 120; i+= 10) {
            g2d.drawRect(i, i, 256-2*i, 256-2*i);
    }
    g2d.dispose();
    return new com.threed.jpct.Texture(image);


and the result is:


an interesting detail is, it always happens to same objects. seldomly on the village to center area and to banks over there, and mostly all of the mushroom club itself.

hope this helps..
r a f t

[EgonOlsen]

How are you handling textures in Karga? Are they loaded once at the beginning, are they added at runtime or even removed? Actually, there aren't much locations in the code that make use of the dummy texture. replaceTexture() is one of them. Any chance that your own mip mapping code is still active somehow (just to be sure...)?

[raft]

How are you handling textures in Karga? Are they loaded once at the beginning, are they added at runtime or even removed?

both. scene textures are loaded when world is first created, avatar textures are created/added/replaced on demand.  remember, users can change dress in karga, most of which is done by creating texture combinations on the fly..

Any chance that your own mip mapping code is still active somehow (just to be sure...)?

i didnt remove my MipMapper code. but it's disabled. to make sure i put some breakpoints and none suspended..

[raft]

i've found it i had overriden World.dispose() and there clear textures specific to that world by name. World.dispose is called when the scene changes. you had a finalizer method in World and you call dispose there too. when that finalizer runs, textures with same name of current world is replaced by dummy texture that mostly happens when resizing window since a call System.gc() after disposing previous FrameBuffer. that's the whole story

i can put a guard to prevent double disposing, but i guess you should do the same. ie: put an internal disposed flag to world.

regards,
r a f t

[EgonOlsen]

I dimly remember adding that finalize-method, because there was some memory leak otherwise when people forget to dispose the world. Too bad that i can't use weak references to stay compatible with 1.1. I've updated the jar above with a version that hopefully prevents double disposing.
Nice bug btw...

Edit: This is the source of all problems: http://www.jpct.net/forum2/index.php/topic,1110.0.html (well, maybe not of all...)

[raft]

thanks. i've also prevented it in my code. well if i were you, i had dismissed 1.1 support long time ago. lucky jPCT users i'm not you

btw, is there a lighting change ? looking at the change log, i can only see a default ambient ligt change which shouldn't effect me, since i explicitly set ambient light.

this is how village looks before (not sure but i guess jPCT 1.17) this is still the online version


this is how it looks with 1.19.


especially the skybox looks darker. it's another world instance rendered to same frame buffer with an ambient light 255,255,255.

what do you think, my fault or ?

[EgonOlsen]

Actually no...i did a comparision of the light calculations back to mid-2007 and i can't find anything that should cause this. Maybe you are calling compile() on objects? That will implicitly set Config.lightMul to 1 (instead of 10, which is default) and doesn't make any sense when using the software renderer either.