mirror of
https://github.com/baldurk/renderdoc.git
synced 2026-05-06 01:50:38 +00:00
baldurk
88 lines
5.2 KiB
XML
88 lines
5.2 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<topic id="0dd6fe0d-4130-46f4-b2ea-9565de13111d" revisionNumber="1">
|
|
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
|
|
<introduction>
|
|
<para>Capturing logfiles is the starting point to using RenderDoc. Although the
|
|
basic use is very simple, there are various customisations and more advanced uses.
|
|
More information on these can be found in the details of the
|
|
<link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" /> window.</para>
|
|
</introduction>
|
|
<section address="capturing">
|
|
<title>Capturing logs</title>
|
|
<content>
|
|
<para>The basic process of capturing logs is fairly straightforward.</para>
|
|
<para>Opening the capture window from the menus via File -> Capture Log, the
|
|
typical capture setup simply requires you to enter the executable location.</para>
|
|
<para>By default the working directory remains empty and defaults to the directory
|
|
that contains the executable location.</para>
|
|
<mediaLink>
|
|
<caption placement="after" lead="Capturing">Capturing a logfile specifying its executable path and command line.</caption>
|
|
<image xlink:href="CapturePathCmdline"/>
|
|
</mediaLink>
|
|
<para>Likewise, the default options generally work well for most situations, however
|
|
there are a few common options to customise:</para>
|
|
|
|
<list class="bullet">
|
|
<listItem><para>Allow Fullscreen/Allow VSync aid in debugging by preventing the app from switching
|
|
into fullscreen (or vsynced) display modes, which makes them easier to attach to from a debugger
|
|
on the same computer.</para></listItem>
|
|
<listItem><para>Seconds attach delay causes RenderDoc to pause for a certain number of seconds after
|
|
launching the process to allow you to attach in the debugger - so that the debugger can be present
|
|
to catch any problems from the beginning of the application, in case there is an issue very early
|
|
in initialisation.</para></listItem>
|
|
<listItem><para>Collect callstacks allows you to get callstacks at the site of each API. There are
|
|
more details available in <link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" />.</para></listItem>
|
|
</list>
|
|
|
|
</content>
|
|
</section>
|
|
<section address="injecting">
|
|
<title>Injecting into a Process</title>
|
|
<content>
|
|
<para>It is possible to inject to an already running process. By selecting the "Inject to Process"
|
|
entry in the File menu, the capture dialog will modify to list the running processes rather than
|
|
asking for an executable and command line parameters.</para>
|
|
<para>This can be useful if launching your application from a single exe is non-trivial and it's
|
|
easier to inject into the process after it has been launched.</para>
|
|
<mediaLink>
|
|
<caption placement="after" lead="Injecting">Injecting to a selected existing process.</caption>
|
|
<image xlink:href="Injecting"/>
|
|
</mediaLink>
|
|
|
|
<alert class="caution">
|
|
<para>The important thing to note about injecting is that RenderDoc can only inject to processes that
|
|
<legacyBold>have not initialised or used the target API</legacyBold>. If this is the case RenderDoc can
|
|
insert its hooks before any use of the API and work as normal. If the API has been used or initialised
|
|
the results are undefined and likely RenderDoc will simply not function as it's too late to hook in.</para>
|
|
</alert>
|
|
|
|
<alert class="note">
|
|
<para>If RenderDoc is not running as administrator, it cannot inject into processes that are running with
|
|
elevated permissions. In this case you can either run RenderDoc as administrator (not recommended unless
|
|
necessary), or re-run the process as the normal user running RenderDoc.</para>
|
|
</alert>
|
|
|
|
</content>
|
|
</section>
|
|
<section address="capfiles">
|
|
<title>Capture setting files</title>
|
|
<content>
|
|
<para>Commonly in development, the capture parameters don't change. In fact most likely the
|
|
same application or couple of applications are launched in exactly the same way repeatedly
|
|
as development iterates.</para>
|
|
<para>To make this process easier RenderDoc supports saving and loading configuration sets to a
|
|
file. While on the capture dialog, click 'Save' to save to a .cap file which contains both the
|
|
executable, working directory and command line - as well as the options that are selected.</para>
|
|
<para>This .cap file can be executed when RenderDoc's file associations are set up, and RenderDoc will
|
|
load this file and present you with the capture dialog on startup.</para>
|
|
<para>You can also use the "Auto start" option - when this option is enabled then a .cap file
|
|
will immediately launch the program when it is loaded. This can allow you to configure a .cap
|
|
which will open RenderDoc and launch the target application with the pre-configured settings
|
|
in one click. If you wish to disable this, just uncheck the option and re-save to the same .cap file.</para>
|
|
</content>
|
|
</section>
|
|
<relatedTopics>
|
|
<link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" />
|
|
</relatedTopics>
|
|
</developerConceptualDocument>
|
|
</topic> |