Hi, my name is Michael B. McLaughlin and I’m a Visual C++ MVP. I’d like to introduce you to several graphics and game development additions and improvements in Visual Studio 2013.
Graphics debugging on remote machines through Graphics Diagnostics is a feature that I’m sure many graphics and game developers have been yearning for (I know that I have). In Visual Studio 2012 you could remotely debug an application’s CPU code using the Remote Tools for Visual Studio 2012. If you wanted to remotely debug graphics, though, then you could only do so programmatically[i].
In Visual Studio 2013 with Windows 8.1 you can now use Graphics Diagnostics to debug apps on remote machines. To do so, first make sure that the appropriate version of Remote Tools for Visual Studio 2013 is installed on the remote computer. Next start the Visual Studio Remote Debugging Monitor on the remote computer (make sure to configure the firewall settings if the settings dialog appears). Then on your development computer, configure your project for remote debugging and then start Graphics Diagnostics. The first time you run a remote graphics debugging session, you will likely get a prompt on the desktop of the remote machine asking you to configure Windows Firewall to allow remote graphics debugging. Configure the firewall settings and switch focus back to the game or app that launched. Then proceed to use graphics debugging on the remote machine just the same as you would use it on your development computer.
Using Graphics Diagnostics on a remote machine does require local access to the machine (it doesn’t run over the Internet and you or someone working with you needs to be there to interact with the program to capture frames). But thanks to the ability to change the playback machine that the graphics code runs on when you debug it, you don’t need constant access to the computer that is exhibiting the problem. If the code runs fine on another machine when played back, it’s possible that the computer that is displaying the problem has a bug in its graphics driver which updating to the latest driver could resolve. It’s also possible that there is a bug in the graphics code but that the computers you had previously been testing the code on still managed to render the scene correctly. Meticulous debugging of the rendering of a captured frame (examining the assets, looking at pixel histories, stepping through shader execution, etc.) will help you isolate and resolve these sorts of insidious bugs.
Previously if you wanted to make use of graphics debugging in Visual Studio, you needed to have a non-Express version (e.g. Visual Studio Professional). In other words, the free versions didn’t have it.[ii] Many developers expressed a desire to have this functionality in Visual Studio Express versions. Microsoft heard us (yes, I was one of those developers) and have responded by including Graphics Diagnostics in Visual Studio Express 2013 for Windows.[iii] This is a great development and I applaud Microsoft and all the folks working on graphics development in Visual Studio for making it happen. It’s nice to know that developers creating Windows Store games and apps with Visual Studio Express can now make use of Graphics Diagnostics to debug their graphics code. To learn more about how to use Graphics Diagnostics, have a look at the Graphics Diagnostics examples on MSDN.
Visual Studio 2013 also now includes compute shader debugging in Graphics Diagnostics. Now you can debug compute shaders in your games and graphics applications in the same way you can debug other shader types. For an overview of debugging a compute shader, see this walkthrough.
As developers, one of the harder decisions we make is whether or not to support a technology that only some users will benefit from. This problem strikes us both with newer and older technologies. Does it make business sense to spend time and money supporting a new technology that only a small percentage of computers have? How about supporting computers that are 5-7 years old (or older) and require special workarounds or even completely different programming paths? While there are right answers to these questions, there aren’t any universally right answers; what is good for one project could easily be disastrous for another. So to me, it’s nice when a technology becomes widespread enough that it’s no longer in either of those grey areas.
Over the past few years, most new computers have included support for Direct Compute (and GPGPU in general). This has created a large enough number of computers which support compute shaders that it now generally makes sense to use this technology when it makes sense and is available. Harnessing the power of the GPU to carry out massively parallel computations (which is what compute shaders and technologies like C++ AMP do) still only makes sense if your program can make productive use of such computations. But it’s no longer a bleeding edge technology. It’s not available on every system but it is nonetheless mainstream. So it makes a lot of sense to learn Direct Compute if you haven’t already. Thanks to the addition of compute shader debugging in Visual Studio 2013, it’s easier than ever to use it to create great user experiences in your games and apps.
Visual Studio 2012 introduced the Visual Studio Image Editor, a modern image editor with support for widely used image formats and many common image editing operations. It also happens to be a great way to convert images to DDS format so that they can make use of a block compression format like BC1 and BC3. This shrinks both the download size and in-app memory usage of your image assets without, in most cases, a noticeable loss in quality.
In Visual Studio 2013 the Image Editor is even better. The image size aspect ratio is now lockable and is locked by default. This makes resizing images much friendlier. Also, the image properties of an image with mipmaps now shows you exactly which mip level you are working with and even lets you change it with a drop down list (in addition to the plus and minus buttons from Visual Studio 2012). And internally the Image Editor now uses premultiplied alpha. Premultiplied alpha is a really great thing since it generates correct results when images with transparency go through a filtering operation (such as rescaling, or mipmap generation) or are converted to a BC format. It avoids the creation of so-called dark halos or fringes around images. So it’s nice to see that the Visual Studio Image Editor is now using premultiplied alpha.
Windows 8 and Visual Studio 2012 let Windows Store developers use certain naming conventions to transparently load resources for different languages and scaling factors without any special code paths. Windows 8.1 and Visual Studio 2013 take this idea a step further by allowing you to create resource packs for each major DirectX feature level (9, 10, and 11). This makes it possible to include images compressed with BC6H and BC7 for users with DirectX 11 GPUs without making users with DirectX 9 or 10 GPUs who can’t use them spend time downloading them and waste storage space on them. Indeed, you can provide feature level appropriate versions of any kind of file-based resource (e.g. images, shader files, and 3D models) such that you can enable users with high-end graphics cards to get the extra benefits their GPU provides while users with power conscious devices or older devices can still enjoy your game or app.
I definitely recommend that you read up on how to create and use resource packs in your Windows Store games and apps. It makes taking advantage of higher powered hardware while retaining support for all types of graphics hardware much easier.
Visual Studio 2013 provides many great new features and improvements for graphics and game developers. In addition to the things I outlined above, there are also improvements to the shader designer and the 3D model editor (and probably several more things I forgot). I think you’ll be pleased with Visual Studio 2013. I know I am.
About the author
Michael B. McLaughlin is a Visual C++ MVP and the proprietor of Bob Taco Industries, a micro-ISV and consulting firm. He was previously an XNA/DirectX MVP and is a retired lawyer. His website is bobtacoindustries.com and his Twitter handle is @mikebmcl .
[i] For those who are wondering, you can still use the programmatic interface for remote graphics debugging. The programmatic interface does not support using Direct3D 11.2 interfaces at this time so if you are using some of the new features like tiled resources or the Trim API then you will need to use Graphics Diagnostics for graphics debugging.
[ii] Students and startups should look in to DreamSpark and BizSpark, respectively. Through them, Microsoft provides software (such as Visual Studio Pro, Premium, and Ultimate) and support for free along with many other free resources designed to help young developers and new companies.
[iii] At this time Graphics Diagnostics is not included in Visual Studio 2013 Express for Windows Desktop. I hope that it will be incorporated into in the future.
is it possible to remotely debug graphics for RT devices yet? such as Surface RT or Surface 2 (RT)?