Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm writing a game engine, and when I use a perspective camera I get a black screen. I am not going to ask exactly why this is because there would be a lot of code to share and, frankly, I think that's a bit petty a question even to bother you all with.

The trouble is that I don't know how to debug it. All that changes is my projection matrix, and if my projection matrix looks fine, I don't know why it doesn't work. Ideally I'd print out the values of various things as the shader did its calculations, but GLSL inconveniently doesn't have a printf() function.

So my question is: how do I debug my problem? The only thing I can think of is checking as many values as I can client-side and then programming by permutation, but I've done that and gotten nowhere. Is there a way I can see what's happening in the video card? Is there a completely different technique I could be using?

I'm using GLSL version 420 (and features specific to that version), so I don't think that glslDevil is an option, considering that it was last updated in 2010.

EDIT

I managed to solve my problem through some completely unrelated debugging.

share|improve this question
add comment

4 Answers 4

up vote 1 down vote accepted

You can also use a program like glIntercept, which is like PIX but then for OpenGL. Next to intercepting and logging all calls it also let's you display shader usage and edit the shaders at run time. This last option (editing the shaders at runtime) could be extremely helpful when debugging because you can keep editing in parts until something goes wrong and you can quickly debug a value by outputting a color.

http://code.google.com/p/glintercept/

share|improve this answer
    
That does seem useful. I'll test to see if it works with GLSL 4.20 EDIT: for a few reasons, I don't think it's going to work. It relies on a lot of characteristics of OpenGL that are deprecated and thus not in my shader code. –  Avi Aug 17 '12 at 7:19
    
Ah too bad, I didn't know it was that old. There has to be some sort of debugger for GLSL4.2 though. I'll ask around. In the meantime, this might work? developer.nvidia.com/content/nvidia-shader-debugger#Features –  Roy T. Aug 17 '12 at 8:14
    
Only works for Cg shaders :| –  Avi Aug 17 '12 at 8:18
add comment

Although I am not sure, NVIDIA Nsight should be able to debug Shaders, at least I think it supported GLSL in some previous version (that you should be able to find). It integrates quite OK with Visual Studio, is not easy but has loads of useful things, but in the older versions you needed 2 machines with a GPU each to debug shaders through a network (while the latest version says it allows "local" debugging). Also, check Shader Designer [2] which seems to be an useful IDE (but lacking GLSL debugging).

[1] http://developer.nvidia.com/content/nvidia-nsight-visual-studio-edition

[2] http://www.opengl.org/sdk/tools/ShaderDesigner/

share|improve this answer
add comment

Personally I still use RenderMonkey. However it's not entirely suitable for this exact question because it's only a facade of a real app and therefore has some odd limitations. It's well out of support but I've just not found anything better for debugging GLSL.

share|improve this answer
    
I'm not sure rendermonkey is what I want here, particularly as things like the camera movement are going to rely on modifying gl_ModelViewProjectionMatrix, which I don't use. –  Avi Aug 17 '12 at 9:51
add comment

Unfortunately debugging opengl is not easy. Here are things that I found useful:

  • use glGetError after every call
  • try to use the new debug extension (ARB_debug_???)
  • use gDebugger to see what's drawn on the screen after each call
  • use apitrace to see what happens after each opengl command
  • modify your shader to output different colors based on the current input and try to understand why it shows a certain color
  • disable every opengl functionality that limits drawing capabilities: scissor test, depth test, backface culling, etc.
share|improve this answer
1  
This doesn't actually answer my question. It's helpful for debugging client-side OpenGL calls, but not for debugging the shader programs. I know how to debug client-side OpenGL calls. –  Avi Aug 17 '12 at 7:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.