API function breakpoints: The Breakpoint dialog lets a developer choose OpenGL / ES, WGL, GLX, EGL and extension functions breakpoints.gDEBugger offers a few mechanisms to do that: In the previous section, we asked the developer to "Break the game application run when the character is being rendered." This allows the developer to view state variable values, texture data, etc. gDEBugger's Comparison Viewer will automatically compare the OpenGL's state variable values to the default OpenGL values.ĭisplaying only the state variable values that were changed by the game application helps the developer track the cause of the problem.Break the game application run when the character is being rendered.If, for example, the game does not have a mode in which the character is rendered fine, the developer can: gDEBugger's Comparison Viewer will automatically compare the OpenGL's state variable values to the exported state variable snapshot file values.
Export all state variables and their values into a "state variable snapshot" file.Break the game application run when the character is rendered fine.Using gDEBugger's OpenGL State Variables view, a developer can select OpenGL state variables and watch their values interactively.įor example, if a game has a mode in which a certain character's shading looks fine, and another mode in which the character's shading looks wrong, the developer can: This black box model makes it hard to locate state variable related problems. However, when using a general purpose debugger, a developer cannot view state variable values, cannot put data breakpoints on state variables, and, at least in Microsoft Visual Studio®, cannot put breakpoints on OpenGL API functions that serve as their high-level access functions. These state variables, located inside the graphics system, are treated as "global variables" that are repeatedly queried and changed by numerous OpenGL API functions and mechanisms. State variable related problemsĪn OpenGL render context is a huge state variable container. In this article we will demonstrate how gDEBugger transforms OpenGL application debugging tasks from a black box model to a white box model, letting the developer peer into OpenGL to see how individual OpenGL commands affect the graphics system. But, what happens when something goes wrong? How does the developer locate the OpenGL calls that caused the problem? When a developer works on top of OpenGL, he sees the graphics system as a "black box " the program issues thousands of API calls into it and "magically" an image comes out of the system. It is not designed for ease of debugging. The OpenGL API is designed to maximize graphics performance. Transforming OpenGL Debugging to a “White Box” Model