Everywhere I read that glDebugMessageCallback is the better solution to get errors, so I implemented it. So far so good. And I am getting indeed more detailed information about what's going on. Currently on NVIDIA it looks f.e. like this:
DebugLog: In source API, type OTHER, id 131185, severity : NONE, message Buffer detailed info: Buffer object 3 (bound to GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), and GL_ARRAY_BUFFER_ARB, usage hint is GL_STREAM_DRAW) will use VIDEO memory as the source for buffer object operations.
Really nice, indeed- however, I miss one thing- I can't indicate here where exactly this happened.
If I use old style method with a macro like this:
#define CHECK_GL_ERROR() CheckGLError(__FILE__, __LINE__)
and
glGetError()
it's far less detailed and a mess in the code- BUT! I can track it more easily down to the line or call it happened, at least when debugging myself.
Of course, if I reduce the log level to something more severe, it is probably also easier to identify the origin, since there are less functions in question, yet, depending on code I find this a bit imprecise to find a specific function.
So my question is now- is there a way to tell what exactly the callback triggered, the function or the perhaps the line in the code, like in the old method (that is, now without adding a manual breakpoint/debug)??
I would find that very handy, especially when considering a situation in which someone who is maybe just using the software could provide me a log only for a problem I can't reproduce myself.
PS: Could someone enlighten me what "id" is for? I found a lot of tutorials and explanations, also read the docs but I still don't see of what use it is for debugging.