# The Importance of Good Debugging Tools
Robert L. Glass wrote an interesting article "Frequently Forgotten Fundamental Facts about Software Engineering". While I am aware he is far more experienced than me and he has sources to backup his opinions, I dare to disagree with following paragraph:
T1. Most software tool and technique improvements account for about a 5- to 30-percent increase in productivity and quality. But at one time or another, most of these improvements have been claimed by someone to have "order of magnitude" (factor of 10) benefits. Hype is the plague on the house of software.
I think that having good tools is one of the most important (and sometimes underrated) factors in programmers' efficiency. From comfortable chair, through fast desktop PC, big monitors, fast Internet connection, to good software, including IDE (editor, compiler, debugger etc.) and auxiliary applications (like Total Commander for file management) - they can all make big difference in how developers feel about their job and how fast the work is going.
Of course, "tools" is a broad term. If by choosing good tools we mean changing used programming language or libraries in the middle of the project, then sure it is usually a bad idea. Writing a script to automate some task that can be done manually in just few minutes or even an hour is usually not worth doing as well.
But what is always worth investing time and money in (either buying or developing your own, learning to use them) are tools that help with debugging. As debugging is the hardest and most time consuming part of programming, any improvement in that process can make as big difference as between minutes and weeks - often in the most critical time, close to the deadline.
So in my opinion, being able to interactively debug executing program (or its trace) - to setup a breakpoint and preview current value of variables (as opposed to relying only on some debug text prints, analyzing logs or some command-line tools) is an absolute minimum to be able to call any programming environment reasonable, mature and eligible to write any serious software in it. If you are the one who writes a program and you have to treat that program as a black box while it is running, without a possibility to peek inside, then something is wrong. AFAIK that is the case with some technologies that deploy program to a server or an embedded device.
How is it in graphics programming? John Carmack once tweeted:
gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins.
While I share his frustration with such primitive methods of debugging, the reality of today's GPU programming is not all that bad as we could only render red pixels to see any debug information. NVIDIA Nsight offers debugging of a GPU, and so does Intel Graphics Performance Analyzers (GPA). Finally, there is a vendor-agnostic debugger for DirectX developed by Microsoft. Originating from Xbox (that is where its name comes from - Performance Investigator for Xbox), PIX used to be available for free as a standalone application. Recently, they have integrated it as part of Visual Studio called Graphics Diagnostics. It was available in commercial versions of Visual Studio only and not in free Express edition (very bad news for all amateur DirectX game developers), but finally they shipped it for free together with the new, fully-functional Visual Studio Community edition.
With these tools, there is no explanation for whining "nothing renders and I don't know why" - just go debug it! :) The future also looks bright. DirectX 12 will offer Debug layer. Vulkan also claims to support debugging tools and layers and LunarG company even started working on such tool - GLAVE.
# Nothing Renders - Why?
"I have a blank screen" or "nothing is rendered" is probably the most frequent bug in graphics programming. It's also quite hard to debug because there are many possible causes. Graphics pipeline is compilated, so there are multiple things that can be wrong at each stage. Few years ago I've written a short article about this, in Polish, titled Nic nie widaŠ. This is translation of that article. It provides a list of questions you should ask yourself while considering the most frequent reasons for why nothing appears on the screen. It is dedicated for Direct3D 9, but it can also be applied to OpenGL (only some things are named differently) and, to some degree, to newer graphics API-s.
First of all, please clear your background to some color other than black, e.g. gray or blue. Maybe your geometry is rendered, but it is black. It is a frequent bug, especially if you have lighting enabled (and it is enabled by default) while you didn't setup any lights.
Are you sure you correctly setup all matrices - world, view and projection? Did you create them using correct functions? Is the camera located in the right place and looks in the desired direction? Maybe your object is in the same position as camera or behind the camera, which is pointing backward?
Is the size and position of your object correct? Is your object too close or too far from the camera, relative to the minimum and maximum Z value set in projection matrix? Isn't it too small to be visible?
Do all the calls to DirectX functions return a value meaning success? Do you even check that value? Please also launch "DirectX Control Panel", enable Debug Layer for your application and analyze Output for any error or warning messages.
Do you use correct vertex format? Did you define a structure describing your vertex correctly and compatible with the FVF/vertex declaration that you use? Are all the fields in the correct order and of the right type? Do you tell DirectX what vertex format you want to use by calling SetFVF/SetVertexDeclaration before rendering?
Do you pass correct parameters to the rendering function? In the most basic case, all offsets should be 0 and "stride" is the size of your vertex structure, in bytes, like sizeof(SMyVertex). Do you pass correct number of primitives to render?
Do you fill your vertex and (optional) index buffer correctly? Do they have correct number of elements? Do you fill all of them? If you use transformed coordinates XYZRHW, the RHW component should be set to 1.0 and never to 0.0.
Maybe your geometry is totally transparent. Is the alpha channel set to maxium (1.0 or 0xFF, depending on type) and not to minimum in all of these: vertices, texture, material (only if you use lighting)?
Maybe the triangles you want to render are ignored as "back facing" the camera, because they have wrong winding (clockwise or counterclockwise)? Try to disable backface culling to check that.
Did you setup blending on all texture stages correctly? Did you correctly setup all rest of the states of graphics pipeline? Maybe the problem appears only when you render some objects in a specific order? That means states set before rendering one object remain in the pipeline and break rendering of the next one.
If you use some advanced rendering features, your graphics card may not support them. Set reference software rasterizer during creation of the device object (D3DDEVTYPE_REF instead of HAL). Your program will run very slowly, but everything should be drawn as expected. Query device object for capabilities of your GPU (device caps).
If you use depth buffer, remember to clear it as well, together with backbuffer. In 3rd parameter of Clear function bitwise OR following flag: D3DCLEAR_ZBUFFER. Without it, you won't see anything on the screen or you will see artifacts. Value to clear Z-buffer to is 1.0f (not 0.0f).
Finally, there are ways you can actually debug how data and state look like on subsequent stages of the graphics pipeline while this bugged draw call is executed, using Graphics Diagnostics in Visual Sudio or other GPU debugging tool.
# Installing Visual C++ Redistributable Package from Command Line
You may think that unless you explicitly use some external library (like FMOD), your program will not require any additional libraries to work, but when coding in C++ using Visual Studio, this is not the case. The functions of standard C/C++ library are implemented in a package of DLL-s called Microsoft Visual C++ Redistributable Package. Each version of Visual Studio has their own set. For example, version for Visual Studio 2013 (Release configuration) consists of files: msvcr120.dll, msvcp120.dll.
You can make your application not requiring this library by setting your project options in Configuration Properties > C/C++ > Code Generation > Runtime Library to "Multi-threaded [Debug]" without the "DLL" part, which makes it statically linked. Alternatively, you can distribute these DLL files (although I'm not sure if this is legal) or the whole library installer together with your application. The library is small and free, available to download from Microsoft website:
The question is: can you launch the installer of these packages with some special parameter so the user doesn't have to go through all the setup wizard, confirming each step? The answer is yes, but as Microsoft likes to change everything very often :) the exact command line is different depending on version. Here is the whole set:
Visual Studio 2005:
Visual Studio 2005, x86 (32-bit version):
vcredist_x86.exe /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /i vcredist.msi /qn""
Visual Studio 2005, x64 (64-bit version):
vcredist_x64.exe /q:a /c:"VCREDI~2.EXE /q:a /c:""msiexec /i vcredist.msi /qn"" "
Visual Studio 2005 SP1, x86:
vcredist_x86.exe /q:a /c:"VCREDI~3.EXE /q:a /c:""msiexec /i vcredist.msi /qn"" "
Visual Studio 2005 SP1, x64:
vcredist_x64.exe /q:a /c:"VCREDI~2.EXE /q:a /c:""msiexec /i vcredist.msi /qn"" "
If you would like to install it in unattended mode (which will show a small progress bar but not require any user interaction), you can change the "/qn" switch above to "/qb". Unattended mode + disabled "Cancel" button is "/qb!".
Visual Studio 2008: Just pass one of these parameters:
/q - quiet mode, no user interface.
/qb - unattended mode, shows progress bar but no user interaction required.
/qb! - unattended mode with "Cancel" button disabled.
Visual Studio 2010 and 2012:
/q /norestart - quiet mode
/passive /norestart - passive (unattended) mode
Visual Studio 2013, 2015, 2017:
/install /quiet /norestart - quiet mode
/install /passive /norestart - passive (unattended) mode
To quickly install all of these libraries on the machines where lots of different applications are launched that may require them, I gathered all the libraries in one directory and I have written following BAT script:
"2005 SP1\vcredist_x86.exe" /q:a /c:"VCREDI~3.EXE /q:a /c:""msiexec /i vcredist.msi /qb"" "
"2005 SP1\vcredist_x64.exe" /q:a /c:"VCREDI~2.EXE /q:a /c:""msiexec /i vcredist.msi /qb"" "
"2008 SP1\vcredist_x86.exe" /qb
"2008 SP1\vcredist_x64.exe" /qb
"2010 SP1\vcredist_x86.exe" /passive /norestart
"2010 SP1\vcredist_x64.exe" /passive /norestart
"2012 Update 4\vcredist_x86.exe" /passive /norestart
"2012 Update 4\vcredist_x64.exe" /passive /norestart
"2013\vcredist_x86.exe" /install /passive /norestart
"2013\vcredist_x64.exe" /install /passive /norestart "2015 Update 3\vc_redist.x86.exe" /install /passive /norestart "2015 Update 3\vc_redist.x64.exe" /install /passive /norestart "2017\vc_redist.x86.exe" /install /passive /norestart "2017\vc_redist.x64.exe" /install /passive /norestart
Update: I also prepared a full package with my script and "pirated" copy of all these installers for your convenience: Microsoft Visual C++ Redistributable Package.zip (77.9 MB).