Hmm... glu is an addon library, and nobody supports it yet for gles.
Now, to some degree, I can understand - gles is designed for mobile use and thus cuts out the "frills". But for that to work someone needs to be going in and addressing the wounds which are left in the system. In this case, I guess maybe we are just supposed to look up the number (which I have done) - but that also means that https://www.khronos.org/opengles/sdk/docs/man/xhtml/glGetError.xml should either list potential results with their meanings or should link to a list of them. And I guess in a sense it has (since it gives the macro names which correspond to the error numbers). Hmm... -- Raul On Fri, Jun 26, 2015 at 4:03 PM, Brian Schott <[email protected]> wrote: > Raul, > > I am not currently exploring openGL, but I have an old RED printed manual > which says that gluErrorString() [not glGetString ?] should be used with > glGetError(). The following code snippet is from the RED book. > > GLenum errCode; > const GLubyte *errString; > > if ((errCode = glGetErrof()) != GL_NO_ERROR) { > errString = gluErrorString(errCode); > fprintf (stderr, "OpenGL Error: %s\n", errString); > } > > > > > > > On Fri, Jun 26, 2015 at 3:30 PM, Raul Miller <[email protected]> wrote: > >> Conceptually speaking, when working with opengl, if there's an error, >> you should be able to use glGetError and I think glGetString to >> diagnose the error. >> >> > -- > (B=) > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
