0

I am writing an Android app and am trying to maximize device support as much as possible. This means (for me at least) supporting both OpenGL ES 1.0 and OpenGL ES 2.0, depending on which is available.

Shader compiler support in OpenGL ES 2.0 is optional, but required for my app (unless I use OpenGL ES 1.0, of course), and so far I haven't been able to find any information about availability. So, I need to check whether compiler support is available and, if not, fall back to OpenGL ES 1.0.

The problem is that if I call GLES20.glGetIntegerv(GLES20.GL_SHADER_COMPILER, ...) to check for support before my onSurfaceCreated(...) method is called, it returns GL_FALSE (if I call it inside onSurfaceCreated, it returns GL_TRUE).

This means I need to create my GL20 Renderer and commit my GLSurfaceView to use GL20 via setEGLContextClientVersion(2) and setRenderer(myGL20Renderer) before I can figure out whether that's really what I want to do.

Is there any way around this other than throwing all that setup away again and basically starting over or accepting the fact that my app might crash on systems that say they support GL 2.0, but don't offer shader compilation?

Community
  • 1
  • 1
Markus A.
  • 12,349
  • 8
  • 52
  • 116
  • I think you may better do this create es2 renderer check for capabilities if not ok fall back to es1.x at the beginning of your app – unique_ptr Aug 11 '15 at 21:30
  • @RiadhHAJAMOR I am not fully following your suggestion, sorry. Are you saying there is a way to do the check without creating a GLSurfaceView, setting its Renderer and waiting for onSurfaceCreated to be called? If so, that is exactly what I am looking for. If you know how to do this, can you elaborate a bit and maybe turn your comment into an answer so I can give you credit for it? Thanks. – Markus A. Aug 11 '15 at 21:34
  • What I meant is that your approach seems ok: in your onSurfaceCreated test the capability – unique_ptr Aug 11 '15 at 21:39
  • @MarkusA. I'm confused - are you checking for shader compile capability (after you've required ES 2.0 in your manifest) which the shader code could either be text (pretty much everyone) or binary (I think GPU specific formats). Realize that Vulkan would standardize intermediate binary format - http://android-developers.blogspot.com/2015/08/low-overhead-rendering-with-vulkan.html – Morrison Chang Aug 11 '15 at 21:43
  • @MorrisonChang The problem I'm trying to address is exactly that I haven't found any information yet on what "pretty much everyone" means. It would be much easier for me to just use OpenGL ES 1.0 instead of opening the can of worms of trying to support binary shaders. So, if the shader compiler isn't available, i.e. I can't use text-shaders, I'd rather not use OGLES 2.0 at all. I don't really need 2.0 since my app runs almost perfectly in 1.0, except that it leads to some very minor graphics errors on large displays due to rounding errors, so I would PREFER 2.0 where available. – Markus A. Aug 11 '15 at 22:20
  • @MorrisonChang (I don't require ES 2.0 compatibility in the manifest) – Markus A. Aug 11 '15 at 22:21
  • @MarkusA. Just wrote out a wall of text on your first question: http://stackoverflow.com/questions/31887263/android-opengl-es-shader-compiler-support – Morrison Chang Aug 11 '15 at 22:27
  • @MorrisonChang Thanks! :) Let me read that. – Markus A. Aug 11 '15 at 22:32
  • @RiadhHAJAMOR That would surely work, but it would be quite far from elegant... So I'm just trying to find a better solution... Or the piece of mind of convincing myself that I don't need to worry about it... :) – Markus A. Aug 11 '15 at 22:33
  • You need an OpenGL context for making the `glGetIntegerv()` call. There's no need for a `GLSurfaceView` if you create the context using the underlying EGL API. My answer here has complete code for creating contexts: http://stackoverflow.com/questions/26985858/gles10-glgetintegerv-returns-0-in-lollipop-only/27092070#27092070. – Reto Koradi Aug 12 '15 at 03:02

0 Answers0