www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: raft on August 10, 2010, 02:32:54 pm
-
say, i have multi texture object, for example a merged one. when GL surface is recreated textures are gone. in order to restore the object's state, calling Texture.keepPixelData(true) is the only way, right? otherwise, i can't load textures again and call setTexture on the object, because it's a multi texture object.
-
Or create/load everything from scratch...or simply exit the game on pause and stop, which is what i'm going to do... ;D
-
the ability to pause the game seems valuable to me. for example when a call arrives. but cost a bit memory.
-
It has another drawback as well: Vertex arrays are save, but VBOs are bound to the gl context. If that changes, the code that renders the geometry will detect that (hopefully) and revert to plain vertex arrays (there should be a log message telling so). At least the current version can't recover back to use VBOs after destroying the gl context.
-
It has another drawback as well: Vertex arrays are save, but VBOs are bound to the gl context. If that changes, the code that renders the geometry will detect that (hopefully) and revert to plain vertex arrays (there should be a log message telling so). At least the current version can't recover back to use VBOs after destroying the gl context.
I've uploaded a jar that might be able to handle this...i'm not sure, i have no test case...
-
cool ;D i'll give it a try soon
-
I've uploaded a jar that might be able to handle this...i'm not sure, i have no test case...
what should i look for in logs? it seems to work ok. at least there is no problem. the surface gets recreated and everything seems in place.
note: on my phone, a certain way to get surface recreated is to make phone sleep and wake up again
-
It should read something like "context changed...trying to recover" or similar. But that only happens if VBOs are enabled in Config anyway.
-
well, it tries to recover but never finishes it. recreates VBO's for same objects again and again..
I/jPCT-AE (14505): [ 1281529704748 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14505): VBO created for object 'object4'
I/jPCT-AE (14505): [ 1281529704765 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14505): VBO created for object 'object4'
I/jPCT-AE (14505): [ 1281529704780 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14505): VBO created for object 'GeoSphere0_jPCT3'
I/jPCT-AE (14505): [ 1281529704794 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14505): VBO created for object 'object6'
I/jPCT-AE (14505): [ 1281529704822 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14505): VBO created for object 'object4'
I/jPCT-AE (14505): [ 1281529704855 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14505): VBO created for object 'object4'
...
-
I must have done something stupid then...i'll look at it.
-
about the comment in javadoc for Config.useVBO
Makes the engine use vertex buffer objects if possible instead of plain vertex arrays. This may be faster on some hardware. On Samsung Galaxy, it isn't and i can't help but think that causes a crash now and then...which is why it defaults to false.
i didn't noticed any performance difference on N1 neither any crashes. indeed, on N1 i never experienced a crash in native code. on G1 it was happening quite often
-
about the comment in javadoc for Config.useVBO
Makes the engine use vertex buffer objects if possible instead of plain vertex arrays. This may be faster on some hardware. On Samsung Galaxy, it isn't and i can't help but think that causes a crash now and then...which is why it defaults to false.
i didn't noticed any performance difference on N1 neither any crashes. indeed, on N1 i never experienced a crash in native code. on G1 it was happening quite often
I've uploaded a new jar which fixes at least some of the stupid things that i made when trying to recover. Please give it a try.
About the VBO stuff: It actually is faster on N1 at least when judging from the numbers that An3DBench returns. However, it's not used for animated objects or objects with an IVertexController attached anyway, because the VBO simply doesn't update even when created with GL11.GL_DYNAMIC_DRAW...at least not on my phone.
-
it still reports a few recovers for same object but does not last forever. maybe that recovers are for different compiled instances ? other than that everything seems fine ;D thanks..
-
Can you post the log output, please? It might be fine, i just want to be sure...
-
I/jPCT-AE (14867): [ 1281554470189 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14867): VBO created for object 'object11'
I/jPCT-AE (14867): [ 1281554470282 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14867): VBO created for object 'object11'
I/jPCT-AE (14867): [ 1281554470288 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14867): VBO created for object 'object11'
I/jPCT-AE (14867): [ 1281554470311 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14867): VBO created for object 'GeoSphere0_jPCT10'
I/jPCT-AE (14867): [ 1281554470332 ] - WARNING: OpenGL context has changed...trying to recover...
I/jPCT-AE (14867): VBO created for object 'object13'
-
That's fine. It's printed out once for each compiled sub part.
BTW: Can you give a brief overview of what exactly you are doing when the surface gets recreated? It seems to work better than my approaches in the past (which was why i ditched the idea).
-
sure :)
- basicly i create a new FrameBuffer. if one already exists, i first dispose it. if i recall correctly this part is taken your demo
- all my textures has keepPixelData set to true, so they can be automatically recovered by jPCT
- there is a chance that Android creates a new instance of the Activity. i override onRetainNonConfigurationInstance() and return the Activity instance. onCreate(), i re-get it with getLastNonConfigurationInstance(). if not null i copy all game and gui elements from that, o/w load textures and similar stuff
and, not sure it's still so but in your demo you were using a pause mechanism for renderer. i found that unnecessary. simply calling GLView.onPause() and GLView.onResume() do the trick
-
there is a chance that Android creates a new instance of the Activity.
Thanks. That happened to me all the time and i wasn't aware of that onRetainNonConfigurationInstanceLongestMethodNameInTheWorld()-thingy... ;D
Edit: So most things like Textures, Object3Ds etc. are attributes of the Activity and not of the implementation of GLSurfaceView.Renderer, i assume? Or does it survive the pause and just creates a new gl context?
-
Another, not really related question: Does mip mapping actually work on your N1? I'm still not sure if my phone just can't do it or if it's an implementation error on my side that everything becomes white that tries to use it...!?
-
That happened to me all the time..
I've discovered a strange behaviour. maybe helps. when my activity is on front and phone goes to sleep, activity is paused, stopped, destroyed, a new one is created and it's paused. docs says, if a configuration change happens and activity does not support the change, a new instance is created. this may be the reason. when phone wakes up a third instance is created
onRetainNonConfigurationInstanceLongestMethodNameInTheWorld()-thingy... ;D
hahaha ;D
docs say call of this method is not guaranteed so maybe storing last instance in a static field may be the best.
So most things like Textures, Object3Ds etc. are attributes of the Activity and not of the implementation of GLSurfaceView.Renderer, i assume? Or does it survive the pause and just creates a new gl context?
yes, they are attributes of activity not renderer. i always create a new renderer onCreate() but i believe the last one may be reused. this may be even better since the last one still holds a FrameBuffer
-
Another, not really related question: Does mip mapping actually work on your N1? I'm still not sure if my phone just can't do it or if it's an implementation error on my side that everything becomes white that tries to use it...!?
how can i test it ? there in no such option in Config for AE version.
-
You can enable it on each texture by calling setMipmap(true). My phone (as well as the G1) seem to support a kind of ES 1.0/1.1 hybrid where the actually gl instance is 1.1 but doesn't support everything. The N1, however, actually should.
-
may it be deactivated in code somehow? i didn't see a difference. and nothing logged as creating mipMap textures.
-
It won't be logged and it's not deactived. So if you see some textures, they should actually be using mip mapping. It may not be noticable depending on the texture though. At least it's not all white like on my phone...
-
It may not be noticable depending on the texture though.
right, most textures are plain color at the moment.
cool, then it works on N1 ;D
-
Got it working on my phone to a degree too by creating the mip maps in code. But it only seems to work on 32bit textures (everything goes crazy if i try to use it on 16bpp ones...) and even then, the mip map implementation looks actually worse than what we did with the software renderer once... :P