glGetError joy

At the end of every frame I check glGetError, and print an alert if anything is wrong. Only problem is that when I DO find an error, it’s nearly impossible to track down in code. glGetError really might as well be

GLboolean glProblemLightIsBlinking( void );

for all the good it does me. I could start sprinkling/doing a binary search through all my code with little error checks, but this is really not very time effective. Isn’t there some way a person can ‘debug’ a gl app in a fashion? I realize this is kind of an old question but I’m hoping there are some new solutions out there.

-Jeff

You should do it after each gl command, not at the end of the frame. Also, it is only usefull for the debugging, the release codes should be free from glGetError.

Yes, there are solutions.

glIntercept is one tool that can help you track down the function that generated the error.

gDEBugger is another tool, though i think it is commercial (30 day trial).

I have never really used them extensively, so i cannot tell you how good they actually are, but from what i heard the tools are pretty useful.

Good luck,
Jan.

Oh, and as the wegpage of glIntercept mentions, there is another tool glTrace.

FYI: If you use GLIntercept with the Author Std profile - and run from visual studio, you will get a breakpoint hit whenever a glError occurs.


// in utils.cpp
void GLDBG_err(char* file, char *str, int line)
{
 int err;

 err=glGetError();
 if (err!=0) 
 {
 Log.AddLine(file, "GLERR: [%5d]  %s: %s", line, str, gluErrorString(err));
 }
}

...
// in utils.h file
extern void GLDBG_err(char* file, char *str, int line);

#ifdef GLDEBUG
#define GLCALL(a) {(a); GLDBG_err(__FILE__, #a, __LINE__);}
#else
#define GLCALL(a) a
#endif


Enclose all gl calls in GLCALL macro… for example GLCALL(glEnable(GL_BLEND));
<u>except</u> glBegin and glEnd and calls between glBegin and glEnd

You can adjust GLDBG_err function according to your needs. At beginning of c/c++ file just define GLDEBUG and all enclosed glcalls will be checked for errors.

This metod have pros anc cons.
Cons are that programmer can forgot do disable (delete or remove #define GLDEBUG) error checking and affect application perofrmances… and its difficult to enclose all gl calls in large projects.

Pros is that you can build application beta-test (enable GLDEBUG) version and send to beta-tester. Beta tester can run app without advanced gl debugging tools (like glIntercept or glDebbuger). Sometimes different driver version can cause problem… ie some piece of code works with older drivers but not with new drivers.

yooyo

We use the same debugging model, I hope, it’s most simple. But we tie to _DEBUG macro, not creating our own, so release version is free from checks.

P.S. Kosovo is serbian land!

yooyo: yes ive used a similar macro style check before, but found even that kind of cumbersome to work with. (i’d have to go back through much of my code and add this all over the place). It does work, though.

jan: i very much like the sounds of glIntercept, I think I will have to try that.

Thanks all!

@Jackis:
Thank you for support!

@Jeff Russell:
Some advanced search/replace can do a good job. Something like in Visual Studio:
Find: gl[^;]*
Replace: GLCALL(\0)
And dont forget to check using Regular Expression.

This example will not catch gl calls splitted in several lines. Maybe someone who is more versatile with regular expressions can solve this puzzle. One more issue… GLCALL macro should be avoided between glBegin and glEnd calls, but this regexp doesnt check that case.

BTW, it’s simple to write such a class, that handles begin-end, and disables error checking, and then in macro instantiate this class.