Congrats to Gremedy

http://oss.sgi.com/projects/ogl-sample/registry/GREMEDY/string_marker.txt

but it would have been better to have unicode support.

Unicode support? I think it is unnecessary. It is for Debugging purpose only. By the way, the OpenGL functions don’t support Unicode, you can see.

I guess there are people that prefer to write debug messages in their native languages… Although I don’t see why can’t you use utf-8 for that.

Maybe, but this is about markers. They could have just used 32 bit integers and it would have been functional.
Being able to read the marker directly is just a bonus.

FWIW, just a thought, but if this extension becomes widely implemented by various GL “debuggers”, it may provide a simple way for a released production application to detect the presence of such a debugger, and deny execution, thus limiting potential ressource “ripping” and reverse engineering (at least by “low-tech end users”)…

But then I’m sure the next step will be a “disable this extension” switch in the debugger :wink:

What could be useful is an extension that allows an application to register a callback for when an OpenGL command raises an error.

This would allow the application to know something went wrong, instead of the current silent-error philosophy.

Originally posted by GPSnoopy:
[b]What could be useful is an extension that allows an application to register a callback for when an OpenGL command raises an error.

This would allow the application to know something went wrong, instead of the current silent-error philosophy.[/b]
amen brother… amen.

Hi, I integrated this extension into GLIntercept

http://www.geocities.com/vmelkon/intercept.html

Source + binary + readme included

Hi V-Man

Thanks a lot for the warm feedback and for integrating our extension into gLIntercept.

We would like to take the opportunity and thank this forum members and Dirk Reiners from Iowa State University, who suggested this extension to us.

Hi GPSnoopy and flamz

Allows an application to register a callback for when an OpenGL command raises an error
Please try the gDEBugger “Break on OpenGL error” and “Break on detected errors” features.

The gDEBugger team

The error call back discussion has already happened:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=7;t=000499

Either use your own scheme, or use the automated “break on error” support in gDebugger or GLIntercept.

Thanks a lot for the warm feedback and for integrating our extension into gLIntercept.

No problem.
I just tried to break on GL with both software. gDebugger doesn't break on a little test I did but catches other errors like using GL function pointer from another context (interesting).
On closing my program, I get a lot of


Process event - Debugged Process Error:
Function Name: glDetachObjectARB
Error code: AP_OBJECT_NAME_DOES_NOT_EXIST_ERROR.
Error description: 
Shader 1073741825 is not attached to program 2147483649


Something like that for each GLSL shader.
I think my code is alright.

GLintercept has a "step through asm code" issue but I think it's not bad.
Set BreakOnError=True in your gliConfig

Hi V-Man

gDebugger doesn’t break on a little test I did
Did you turn on the “Break on OpenGL error” checkbox? (Breakpoints menu or Breakpoints dialog).
If you did turn it on and the problem reproduces, can we get this test application?

catches other errors like using GL function pointer from another context (interesting).
“Break on Detected errors” is a gDEBugger mechanism that allows you to catch errors:
a. On which OpenGL does not report.
b. Give detailed information on OpenGL errors.
The error you got means that your application called wglGetProcAddress from one context and used the pointer in another context. This is illegal in win32 (See MSDN wglGetProcAddress documentation )

On closing my program, I get a lot of …
We managed to reproduce the problem and we will fix it.

Thanks,
The gDEBugger team

Yes, from menu Breakpoints -> Break on OpenGL error Ctrl+E
“Break on detected errors” “Enable breakpoints” is also active.
I’m going to assume it’s my mistake because certainly, my calls to glGetError show that an error was raised.
gDebugger version is 1.5.0.2600

About wglGetProcAddress, you can use the same funcion pointer from another GL context as long as the pixel format is the same.

Hi V-man

Break on OpenGL errors
We didn’t understand your answer regarding the gDEBugger “Break on OpenGL error” feature:

  • Is it working well?
  • If not, can you please send the test application to info [at] gremedy.com

wglGetProcAddress and gDEBugger detected error
From the MSDN documentation:
a. Extension functions supported in one rendering context are not necessarily available in a separate rendering context.
b. All rendering contexts of a given pixel format share the same extension function addresses.
c. Thus, for a given rendering context in an application, use the function addresses returned by the wglGetProcAddress function only.

As far as we understand it, if both contexts share the same pixel format and they both support the same extensions, you will get the same function pointers when calling wglGetProcAddress in both contexts. But, if one context does not support an extension that the other context supports, you will have a pointer that you should not have. As far as we know, this situation does not exist in current hardware vendors’ implementations, but Win32 does not block implementers from doing it.
Therefore, we think that it’s a good practice to query the available extensions and extension function pointers “per render context”. This is why we added the above detected error to gDEBugger.

What is your opinion here?
Other forum members / hardware vendors opinions?

The gDEBugger team

Remedy,
what I can imagine with “Break on OpenGL error” is “DebugBreak()” on Win32. As you already intercept all, that should be a no-brainer.

Graphic Remedy,
It’s not breaking, although in my code, glGetError shows that there was a GL error. Sample project sent.

wglGetProcAddress:
Since you have a debugger, I think you should leave your product as is. I was just congratulating you. :slight_smile:

In practice, the function pointers are always the same. ATI and NV seem to give the same pointers even when the pixel format is NOT the same, even when one context is for a p-buffer and the other for a window.