Comment Feed for Channel 9 - Fall Fury: Part 11 - Hardware Testing & Debugging http://media.ch9.ms/ch9/d2bf/2dea3e0d-559c-4efb-ae2d-a2c49c20d2bf/FallFuryPart11_220.jpg Channel 9 - Fall Fury: Part 11 - Hardware Testing & Debugging Hardware Testing & DebuggingAs previously mentioned, FallFury runs on multiple types of hardware as long as that hardware supports Windows 8. This article describes the project’s general testing and debugging process, including setting the debug configurations and remote debugging. Check out the video for this article at http://channel9.msdn.com/Series/FallFury/Part-11-Hardware-Testing.  For a complete, offline version of this series, you may download a nicely formatted PDF of all the articles. Remote DebugWhen working on an application that targets different machines, it’s probably out of the question to install Visual Studio on each instance and move the solution from one source to another in order to run it and diagnose potential problems. Here is where Remote Tools for Visual Studio 2012 come into play. Microsoft offers you three separate builds—tools for x86 systems, x64 systems, and ARM systems—also known as Surface RT. Once the tools are running on the machine you want to debug, you have two choices. You can either install the remote debugger as a service, allowing it to constantly run in the background, or you can use the debugger on a per-launch basis. From a developer perspective, the choice doesn’t affect how your application is executed on the remote machine. From a security perspective, however, you need to be sure that you properly configure it so that no unwanted apps are remotely deployed. Now you can start the Remote Debugger Configuration Wizard: This works on both the initial start-up and also any subsequent launch as a way to easily and quickly set the necessary remote debugger settings. Specifically, it is useful to configure the machine’s network settings, allowing cross-domain communications for debugging purposes. Once the wizard is completed, launch the Remote Debugger Monitor. Notice that it lists your machine name and the port on which it’s running. This is necessary for configuring the project to send the package to a remote machine instead of the local one: The configuration depends on the network settings on both the local machine and the subnet as a whole. For example, in some cases, and especially on domain-joined machines, remote debugging is better done with the authentication disabled. Windows Authentication is used by default. Since FallFury is a C++ project, the configuration for a remote session is different than, say, that of a C# Windows Store application. To configure the session, right click on the project in Solution Explorer and open the Debugging section. Make sure that Remote Machine is selected as the type of debugger to launch: Next, specify the machine name as well as whether the current session will require authentication: If you cannot specify the machine name, use the direct IPv4 address of that computer, minus the port (unless you’ve explicitly set it to a port other than 4016, which is the assumed default). Once the source machine connects to the remote one, you will see Visual Studio performing the deployment: ConfigurationsAs a matter of convenience, it is always good to have different debug configurations that will define how your projects are built, especially if the project targets multiple platforms (such as ARM and x86). Visual Studio provides a Configuration Manager that can be accessed from the debug target dropdown: FallFury includes two separate projects—the game core, and the C#-based XML reader. Both need to be explicitly associated with separate target platforms in order to be correctly debugged. For that, profiles were created for both local and remote sessions: As with standard Debug/Release configurations, the ones shown above determine whether the project will carry debug symbols and support debugging commands. It is important to mention that as you switch configurations, you must be careful how you configure the graphic shaders. For each shader in the container folder, explicitly set the HLSL shader type and model. Otherwise the application deployment will fail: Remote ProfilingLast but not least, when working with different hardware configurations it might be useful to perform application profiling or performance review. Fortunately, Visual Studio also provides this capability through the vsperf tool, which is already integrated in the IDE if you are using Visual Studio 2012 Professional or above. To initiate a profiling session on a remote device, the Remote Debugger Monitor must be active. Make sure that the Remote Machine debug target is selected, and go to Analyze > Start Performance Analysis: On the remote machine, allow the vsperf process to run with administrative privileges. Once the profiling session completes and the data is analyzed, you can review the same performance indicators as you would when having a standard application run the profiler on the local machine: ConclusionTesting hardware outside the boundaries of a desktop machine is often a necessity, especially if the application relies on specific sensors, such as NFC, touch, or accelerometer. The remote debugging process is fairly streamlined and intuitive, with developing a proper network configuration allowing communication between machines requiring the most significant amount of effort. If you have problems getting the debugger to work, consult this article on MSDN. en Mon, 20 May 2013 08:22:30 GMT Mon, 20 May 2013 08:22:30 GMT Rev9 Re: Fall Fury: Part 11 - Hardware Testing & Debugging posted by Saj

]]> http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-11-Hardware-Testing--Debugging#c634986693437369454 Tue, 12 Mar 2013 07:15:43 GMT http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-11-Hardware-Testing--Debugging#c634986693437369454 Saj Re: Fall Fury: Part 11 - Hardware Testing & Debugging Thank you for your feedback! It can be fairly easy ported to WP8. I'm saying that because WP8 doesn't have full support for D2D, so there might be some roadblocks, but DirectXTK can be quite of some help in this case.

posted by DennisDel

]]> http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-11-Hardware-Testing--Debugging#c634990587408119307 Sat, 16 Mar 2013 19:25:40 GMT http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-11-Hardware-Testing--Debugging#c634990587408119307 DennisDel Re: Fall Fury: Part 11 - Hardware Testing & Debugging posted by Alex Soriano

]]> http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-11-Hardware-Testing--Debugging#c635000842320160370 Thu, 28 Mar 2013 16:17:12 GMT http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-11-Hardware-Testing--Debugging#c635000842320160370 Alex Soriano