Tips debugging code which compiles, and gives no errors

Hello, I’m new to modern OpenGL (in the process of taking a course now). Funny enough, I was about to post my code here and ask what was wrong with it but with some dumb luck I ended up catching my mistake in the process of writing this up :laughing:

Despite this, I would like to know some tips / strategies you guys use to debug code which compiles and gives no errors. For example, the code which I was having problems with would compile shaders w/o errors, and it would link them w/o errors but nothing was being drawn to the view port. If everything “looks” good, but something isn’t right, where do you guys begin to look for problems?

Usually I’d simplify the shaders until I get something other than the background colour, then start adding bits back in until it doesn’t do what I expect. If a trivial shader doesn’t produce recognisable geometry then I’d use a debugger to check what data is actually being sent.

However: debugging when you understand both the underlying principles and the OpenGL API is somewhat different to debugging when your understanding of either (or both) is somewhat incomplete. In the former case, the issue is invariably some trivial mistake. In the latter case, even having all of the information in front of you doesn’t necessarily tell you why it isn’t working.

@R_Shobu
If you get no errors on the shaderside and none from glGetError() then you’r likely facing trouble on the matrixes. (It’s hard to imagine a setup without matrixes). I havn’t yet seen a opengl book not mentioning that this matrix-stuff is the hardest part for newbees. … some of us never grows old in this respect …
I’ll parafrase “OpenGL Programming Guide” on the start: don’t let go of your 2d/3d sense of the situation. Stick to it and try out simple situations. Stick to a simple model. On my part, testing input drag or rotate-model() and drag or rotate"camera"() came first … and I was stuck for a long while. I cannot really say why it works, but the code is sane & readable. There is no quick or easy solution by providing projection, view and model-matrixes to the shader … you still have to figure out what they do and how they are proberly composed before you send them there. Writing a matrix is essential, but reading them quickly becomes very usefull too … there’s no way around searching some sources on the topic.
As of now I feel that I can begin composing models using matrixes … independent of the problem of displaying them proberly.

My all-time favorite tool for debugging OpenGL apps is RenderDoc. It’s 100% free and open source, supports Windows, Linux, Android (and Nintendo Switch, I think?) and can profile OpenGL 3+, OpenGL ES, DirectX and Vulkan applications. Basically, you open your app in RenderDoc and capture one or more frames. You can step through all your draw calls, see what’s drawing to buffers, see what textures are currently bound and the current state of the OpenGL renderer. You also can see exactly what data is being sent to your shader uniforms and attributes, see what geometry is being sent to a vertex shader or output from a geometry shader, etc. It’s really, really useful.

Even cooler, you can open up a commercial game in it and capture a frame to see how the game is rendered. Just like your own apps you can see the geometry and shaders (though the shaders will be in SPIR-V/whatever assembly-like code DirectX compiles them to).

Thank you all for your replies! Your advice is greatly appreciated :smile: