hi all.
in android.
after stopping and resumption of activity, render the error only after glActiveTexture
GLES20.glActiveTexture(GLES20.GL_TEXTURE0+0);
logErr+="act "+GLES20.glGetError()+"
"; //error 1285
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, texture);
logErr+="bind "+GLES20.glGetError()+"
";//error 0
logErr+="is tex"+GLES20.glIsTexture(texture)+"
"; //true
What GPU and Android device? Are there any other GL or EGL errors being emitted? Be sure to check for success returns from egl calls such as eglSwapBuffers, eglMakeCurrent, etc.
Are you following these guidelines when managing android Activity States?:
[ul]
[li]Fixing Common Android Lifecycle Issues in Games (NVidia) [/li][/ul]
In particular, are you monitoring the onNativeWindowDestroyed and onNativeWindowCreated activity states?
I’ve seen cases where the window system deletes the EGL window surface out from under you on an onResume. In these circumstances, your app is responsible for detaching the window from your context, waiting for an onNativeWindowCreated, and then attaching the new window to the context (assuming you want to keep your context and render to the window surface). Not following this pattern won’t necessary net you a GL_OUT_OF_MEMORY, but it’ll likely result in EGL errors trying to talk to a native window that’s already been deleted through an EGL window surface still pointing to it.
Also, this probably isn’t your problem but (related to GL_OUT_OF_MEMORY returns on Android: ) I’ve seen a GL_OUT_OF_MEMORY kicked back to the app followed later by an EGL_CONTEXT_LOST error when the Qualcomm Adreno driver deadlocks/crashes internally due to a driver bug handling gl_FragDepth in a frag shader (link).
With more details on what GPU you’re using and what specifically you’re trying to do, folks here might be able to offer further ideas and tips.