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

[OpenGLES 2.0 Emualtor] [OSX] Trouble with glDrawArrays GL_INVALID_ENUM

Hi all,

I've been following a few examples such as the WikiBooks one here: OpenGL Programming/Modern OpenGL Tutorial 05 - Wikibooks, open books for an open world to get myself up to speed with OpenGL 2.0. I really appreciate how awesome the Mali emulator is.

However I've run into a problem when trying to run the above example, I've got to the point of loading the indices but I get GL_INVALID_ENUM when running glDrawArrays. I've attached a project that should work in OSX if you have the Mali emulator installed.

Running is pretty straight forward, do Make and then ./bin/cube

Any help would be appreciated.

gl_cube.zip
Parents
  • Hi pbrooks,

    not certain about the answer to this one, but I did notice one thing I thought looked suspicious in main.mm

    In the draw() function, I think you are declaring local, stack-based storage space for the vVerticies[] array. I think that memory will go out of scope as soon as the function exits and potentially be overwritten by any later stack operations in the program. My worry is that if the OpenGL ES driver didn't read the data until the eglSwapBuffers() elsewhere in the program then garbage data might be read. It might be better for this example to either use an array in global memory, or malloc() some space from the heap and use that pointer as the memory is guaranteed reserved until you free() it.

    I also noticed there isn't a GL_CHECK() macro around the glDrawArrays() so could you be seeing an error from a different call instead? Might be worth adding the macro to all the GL calls, to be sure any error is reported to you as soon as it occurs.

    I've seen this kind of GL_INVALID_ENUM error before when people have used GL_INT as the type in the glVertexAttribPointer() call. It's not a supported type in OpenGL ES 2.0 but I think it might be in OpenGL so some implementations don't always catch it as a spec violation. Unfortunately, that doesn't seem to be the case in your scenario so I'm a bit stumped as to your problem.

    Can you have a go at moving the vVerticies[] array and adding the GL_CHECK() macros and see if the reported error moves?

    HTH, Pete

Reply
  • Hi pbrooks,

    not certain about the answer to this one, but I did notice one thing I thought looked suspicious in main.mm

    In the draw() function, I think you are declaring local, stack-based storage space for the vVerticies[] array. I think that memory will go out of scope as soon as the function exits and potentially be overwritten by any later stack operations in the program. My worry is that if the OpenGL ES driver didn't read the data until the eglSwapBuffers() elsewhere in the program then garbage data might be read. It might be better for this example to either use an array in global memory, or malloc() some space from the heap and use that pointer as the memory is guaranteed reserved until you free() it.

    I also noticed there isn't a GL_CHECK() macro around the glDrawArrays() so could you be seeing an error from a different call instead? Might be worth adding the macro to all the GL calls, to be sure any error is reported to you as soon as it occurs.

    I've seen this kind of GL_INVALID_ENUM error before when people have used GL_INT as the type in the glVertexAttribPointer() call. It's not a supported type in OpenGL ES 2.0 but I think it might be in OpenGL so some implementations don't always catch it as a spec violation. Unfortunately, that doesn't seem to be the case in your scenario so I'm a bit stumped as to your problem.

    Can you have a go at moving the vVerticies[] array and adding the GL_CHECK() macros and see if the reported error moves?

    HTH, Pete

Children