We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1291 - OpenGL ES 2 context creation is broken on Android
Summary: OpenGL ES 2 context creation is broken on Android
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: ARM Android (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-26 03:49 UTC by Tim Angus
Modified: 2011-10-14 04:03 UTC (History)
2 users (show)

See Also:

Attachments
Support for OpenGL ES 2 on Android (1.63 KB, patch)
2011-08-26 03:49 UTC, Tim Angus 		Details | Diff
Support for OpenGL ES 2 on Android (1.63 KB, patch)
2011-08-26 05:16 UTC, Tim Angus 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Angus 2011-08-26 03:49:05 UTC 
Created attachment 683 [details]
Support for OpenGL ES 2 on Android

There are a couple of things missing from SDL_Activity.java that are necessary to support OpenGL ES 2 context creation. The contextAttrs part is from Forest Hale via the mailing list. He says:

"On an OpenGL ES 2 capable device, it is not enough to pick a config that supports ES2, it is necessary to specify an EGL_CONTEXT_CLIENT_VERSION of 2 when one is wanted...  I have revised the eglCreateContext call as shown below in my local copy.

I also think the eglChooseConfig is busted, the first config reported on my device has EGL_DEPTH_SIZE 0 which makes it rather useless for a 3D game, I uncommented the request for EGL_DEPTH_SIZE 16 in my local copy for this purpose, the alternative would be to request a large number of configs (I got over 20 unique ones in testing...  so a larger number is required) and picking the "best matching" one.

This is just a bland snippet of revised code for android-project/src/org/libsdl/app/SDLActivity.java - sorry for any inconvenience with it not being a directly applyable patch.

             int EGL_CONTEXT_CLIENT_VERSION=0x3098;
             int contextAttrs[] = new int[]
             {
                 EGL_CONTEXT_CLIENT_VERSION, majorVersion,
                 EGL10.EGL_NONE
             };
             EGLContext ctx = egl.eglCreateContext(dpy, config, EGL10.EGL_NO_CONTEXT, contextAttrs);"





I've also changed the constant passed to eglWaitNative as it was causing console spam on every buffer flip. The man page states:

"Parameters

engine

    Specifies a particular marking engine to be waited on. Must be EGL_EGL_CORE_NATIVE_ENGINE."

So I've used this constant instead and the console spam goes away.
Comment 1 Tim Angus 2011-08-26 05:16:14 UTC 
Created attachment 685 [details]
Support for OpenGL ES 2 on Android
Comment 2 Gabriel Jacobo 2011-08-26 05:54:33 UTC 
If I may add a report on this, on a Asus Transformer device (Android 3.2, Nvidia Tegra), I see the OpenGL ES 2 process fail at GLES2_CreateRenderer.
Specifically, it fails when it queries

glGetIntegerv(GL_NUM_SHADER_BINARY_FORMATS, &nFormats);
glGetBooleanv(GL_SHADER_COMPILER, &hasCompiler);

and 

glGetIntegerv(GL_SHADER_BINARY_FORMATS, (GLint *)rdata->shader_formats);

(By the way, nFormats and hasCompiler should be initialized to 0 and false, in my case I found it hard to figure out because nFormats had for some reason a value of 3, so the code kept going assuming the call was successfull).

The gl error in all those calls is GL_INVALID_ENUM
Comment 3 Ryan C. Gordon 2011-10-13 21:18:21 UTC 
Tim's patch is now hg changeset 75c796a375e1.

What's the fix for Gabriel's GL_INVALID_ENUM? Are we supposed to be checking for an extension before those queries?

--ryan.
Comment 4 Gabriel Jacobo 2011-10-14 04:03:55 UTC 
This is fixed AFAICT, I'm not sure if it got fixed because of the proper context creation from this patch or because of the GetProcAddress implementation from #1290, but the thing is it works so let's not look at it too closely for fear of breaking it!