This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Messed up texture coordinates on Mali-T628 (not using mediump...)

We recently released our game on Google Play, and it is going great.

Though on devices with Mali T628 (Galaxy Tab S, Galaxy Note 3) there is an issue with texture coordinates..

Works fine on all other platforms.

I found a post here about there being an issue with mediump, but we are using highp in our shader.

I'm attaching a screen shot here, and the relevant shaders.

Any ideas what could go wrong?

This shader is for the environment (not working):

+++

Loaded vertex shader: bmxshaders/MultiTextureT0T2.vsh - ID: 4

precision highp float;

attribute vec4 a_position;

attribute vec2 a_texCoord0;

attribute vec2 a_texCoord2;

varying vec2 v_texCoord0;

varying vec2 v_texCoord2;

uniform mat4 u_matWVP;

void main()

{

     gl_Position = u_matWVP * a_position;

     v_texCoord0 = a_texCoord0;

     v_texCoord2 = a_texCoord2;

}

---

Loaded pixel shader bmxshaders/MultiTextureT0s1d0T2s2d0.fsh - ID: 5

precision highp float;

varying vec2 v_texCoord0;

varying vec2 v_texCoord2;

uniform sampler2D s_texture0;

uniform sampler2D s_texture2;

void main()

{

     vec4 color0;

     vec4 color1;

     color0 = texture2D(s_texture0, v_texCoord0);

     color1 = texture2D(s_texture2, v_texCoord2);

     gl_FragColor = color0 * color1;

}

+++

This shader is for the bike (seems to work fine):

+++

Loaded vertex shader: bmxshaders/LightingSimpleDirNoScaleNormals.vsh - ID: 16

precision highp float;

struct light

{

  vec3 position;

  vec4 ambient;

  vec4 diffuse;

  vec4 specular;

  // only directional light is supported

};

const float c_zero = 0.0;

const float c_one = 1.0;

uniform light u_light0;

attribute vec4 a_position;

attribute vec3 a_normal;

attribute vec2 a_texCoord;

varying vec2 v_texCoord;

varying vec4 v_color;

uniform mat4 u_matWVP;

uniform mat3 u_matWVNormals;

void main()

{

  float ndotl;

  vec3 n;

  n = u_matWVNormals * a_normal;

  v_color = vec4(0,0,0,1);

  v_color += u_light0.ambient;

  ndotl = max(dot(u_light0.position.xyz,n), c_zero);

  v_color += (ndotl * u_light0.diffuse);

  gl_Position = u_matWVP * a_position;

  v_texCoord = a_texCoord;

}


---

Loaded pixel shader bmxshaders/Lighting.fsh - ID: 17

precision highp float;

varying vec2 v_texCoord;

varying vec4 v_color;


uniform sampler2D s_texture0;

void main()

{

    gl_FragColor = texture2D(s_texture0, v_texCoord) * v_color;

}

+++

  • For the benefit of anyone else who finds this post:

    The problem was caused by an invalid assumption made by the game engine that the locations of uniforms for a shader would maintain the order in which they were declared in the shader source code.  This was causing the wrong textures to be bound to the shader causing incorrect lookups.  On other platforms, including Mali400, it was the case with this application that the uniforms were being returned in the order declared in the shader source, however, this was not the case for this particular version of the Mali-T6XX device mentioned.

    From the GLES API Reference pages for glGetUniformLocation: "The actual locations assigned to uniform variables are not known until the program object is linked successfully."

    It is, therefore, always necessary to get the location of uniforms in a program using glGetUniformLocation before attempting to set them, and so the behavior seen is still fully compliant with the Khronos Spec.