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.
I've made progress with the problem by passing the indices in directly as the last parameter to glDrawElements, however I am still trying to figure out the reason for the difference between given examples out there and this direct use in Mali.
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
I've passed this onto the tools team to see if they can reproduce the issue. Glad you've got around the issue for now!
Thanks,
Chris
Thanks for your report. I was able to reproduce your problem and I have raised it internally as it looks like there might be an issue with OpenGL ES 2.0 Emulator.
Luckily you have found a workaround.
We will be adding MacOSX support to OpenGL ES 3.0 Emulator, so the issue should be fixed by then.
Jacek
@petehorsman Thanks for the suggestions, sadly I missed tidying up some of the other classes so it has unused code in there. Thankfully I'm not doing anything wrong but the team seem to have responded that it's a bug.
@kubacki Awesome, thanks. I'm pleased it's a bug rather than my own issue, I had about three different book examples doing the same thing failing.
Hi Jacek,
Thanks for the swift response, good to hear that it's a bug.
Will you be releasing another version of the 2.0 emulator with the fix?
I do like the Mali emulator as it lets me learn against OpenGL ES 2.0 with all the possible resources and that I get to decouple myself from IDE's such as XCode. A quick side note is that it'll be great if you guys included a Makefile solution for OSX by default.
Thanks!
I don't think there will be a fix for OpenGL ES 2.0 Emulator as it is being deprecated in favour of the OpenGL ES 3.0 Emulator, which allows the developers to create OpenGL ES 2.0 context if needed.
I have added your suggestion to provide Makefile for MacOSX example to the list of the things to consider while adding MacOSX support to OpenGL ES 3.0 Emulator.
Have a good day,