On Win32 emulator (v2.7/WinXP/NVidia) I keep getting GL_INVALID_VALUE from a glUniform4f call to set a simple vec4 color. Tried with glUniform4fv, same result. Did check the glError before the glUniform call too. What's funny is that my color uniform gets set properly. The uniform was initial declared in the fragment shader so I moved it to the vertex shader and now passing its value through a varying to check if it was an issue with the uniforms from fragment shader but I'm still getting the error.
I remember getting the same error a while ago … I came to a conclusion that this is some kind of harmless emulation artifact because, as in your case, things work just fine .
Now that I’m getting more advanced OpenGL ES 2.0 functionality implemented, I too am getting spurious GL_INVALID_VALUE errors in what is otherwise code that is behaving normally. I check values going into the function, and if it’s relevant, I call glGet* functions to make sure values of a program/shader/etc. are legitimate values. (Heck, I even had glBlendColor return a GL_INVALID_VALUE; that’s not a function that has a reason to even return that, esp. given I was passing all 0.0 values to that function.)
Is it a known issue for the emulator to suddenly start returning GL_INVALID_VALUE? If so, are the conditions known? I’m otherwise left with either: a) disabling glGetError calls for all my gl function calls (not so safe in case I miss a real error), or b) putting special-case code around functions that I run into that is returning GL_INVALID_VALUE.jbuck2011-08-16 13:26:11
Gordon, thanks for the response. I’m in crunch mode at the moment, so I can’t narrow down a small test case. I think the simpler cases don’t actually uncover the problems, since I only started really hitting these errors when a sufficient portion of the engine was ported. When I was only calling some of the more trivial gl stuff, I wasn’t hitting these errors.
