glDebugMessageCallback更详细的信息

时间:2017-06-01 12:56:06

标签: c++ opengl

好吧,无论我在哪里读到glDebugMessageCallback都是获得错误的更好解决方案,所以我实现了它。 到现在为止还挺好。而且我确实得到了有关正在发生的事情的更详细信息。目前在NVidia上它看起来像f.e.像这样:

  

DebugLog:在源API中,键入OTHER,id 131185,severity:NONE,   message Buffer详细信息:缓冲区对象3(绑定到   GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB(0),和   GL_ARRAY_BUFFER_ARB,用法提示是GL_STREAM_DRAW)将使用VIDEO   内存作为缓冲区对象操作的源。

真的很好,确实 - 但是,我想念一件事 - 我无法在这里指出究竟发生了什么。

如果我使用像这样的宏的旧样式方法:

#define CHECK_GL_ERROR() CheckGLError(__FILE__, __LINE__)glGetError()

它的细节要差得多,而且代码很乱 - 但是!我可以更容易地跟踪到线路或调用它,至少在调试时我自己。

当然,如果我将日志级别降低到更严重的程度,可能也更容易识别原点,因为问题较少的函数,但是,根据代码我觉得找到一个特定的有点不精确功能

所以我现在的问题是 - 有没有办法告诉究竟回调触发的内容,函数或代码中的行,就像在旧方法中一样(即现在没有添加手动断点/调试) ??

我会觉得非常方便,特别是考虑到一个可能只是使用该软件的人只能为我提供一个我无法自我复制的问题的日志。

PS:有人可以告诉我什么" id"是为了?我发现了很多教程和解释,也阅读了文档,但我仍然没有看到它用于调试的用途。

1 个答案:

答案 0 :(得分:7)

有两种方法可以帮助您确定错误的来源:

首先,您可以glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS)确保在产生错误的函数范围内抛出错误。现在,当您在错误回调函数中设置断点时,您将看到出现错误的callstack。

第二:OpenGL允许您将名称和范围与每个OpenGL对象相关联。这允许您指定名称,比如说,缓冲区。有关详细信息,请查看here