The SDK 3.5 emulator (on Windows 10 at least) returns the GL_VERSION of the underlying OpenGL desktop. In my case, running on Intel HD 5500 graphics with an OpenGL 4.3 driver, queries on GL_VERSION and related parameters return a major version of 4, minor version of 3 and a context profile with GL_CONTEXT_COMPATIBILITY_PROFILE_BIT set. My application had requested an OpenGL ES 3.0 context from EGL.
This misled my application which, as a result, attempted to load a legacy sized format LUMINANCE8 texture only for the emulator to return GL_INVALID_OPERATION.
Is there a proper bug tracking system where this kind of issue can be reported?
Can you share the entire GL_VERSION string from your machine?
[blockquote]Is there a proper bug tracking system where this kind of issue can be reported?[/blockquote]
At this time, we only have an internal bug tracker. However, I’d be happy to share the bug report number from this system with you once we’ve reproduced the issue and filed it.
The version string when requesting a 3.0 context (i.e. from libGLESv2.dll) is
[pre]“3.0(Host : 4.3.0 - Build 10.18.15.4256)”[/pre]
GetIntegerv for MAJOR_VERSION returns 4 and MINOR_VERSION returns 3.
The OpenGL ES 3.0 spec says
[blockquote]
The VERSION string is laid out as follows:
“OpenGL ES N.M vendor-specific information”
[/blockquote]
So you’re missing the “OpenGL ES” and the space after the minor version, as well as returning the wrong values for MAJOR_VERSION and MINOR_VERSION.
When requesting a 1.1 context (i.e. from libGLES_CM.dll) the version string is
[pre]“1.1(Host : 4.3.0 - Build 10.18.15.4256)”[/pre]
MAJOR_VERSION & MINOR_VERSION return 4 & 3 as before but no error is raised. These queries are not valid in OpenGL ES versions < 3.0 and should cause an INVALID_ENUM error to be raised.
