RenderDoc Integration

[TheLostInPlace]

Why

Shader and render work on this engine gets debugged by guessing until a capture exists. RenderDoc captures answer those questions directly, but taking one meant launching the game through RenderDoc's UI by first hooking it into MO2 or the global hook (which rarely works) and pressing a hotkey at the right moment (before APi initialization). This makes captures an engine tool: triggered from the console or a script, at the exact frame you want, from a normal launch with an argument (-renderdoc).

How

The engine loads RenderDoc's in-application API when renderdoc.dll is already in the process, or loads it itself from the bin folder when launched with -renderdoc. It negotiates the newest API the host offers (1.7.0 down to 1.1.0) and keeps the engine's own crash handler. Three console commands drive it:

• rdoc_capture [1..60] queues frames
• rdoc_open raises or launches the replay UI on the last capture
• rdoc_overlay 0/1 toggles the overlay (bare prints the state)
• -rdoc_refall and -rdoc_cmdlists set the matching capture options

Captures are stored in appdata\renderdoc\captures\<exe>_frameN.rdc and are logged when they finish. On 1.7.0 hosts each capture carries frame, time, camera, fov, render size, level, the second-viewport flag (not PiP, the default engine's) and the eight shader_param vectors as annotations.

R4's PIX markers get colours through the d3d9 PERF entry points RenderDoc hooks, with ID3DUserDefinedAnnotation as the fallback, and render targets get debug names so they appear under their engine names.

Benefits over RenderDoc injection

• Launch the game normally: the UI can attach to the running process afterwards
• Capture from a script or console at a chosen moment: including a run of frames, instead of a hotkey
• Every capture is self-describing: annotated with where and when it was taken
• Passes are coloured and named: render targets are named, so the event browser reads like the engine's own frame
• Crash handling stays the engine's own. RenderDoc's default F12 capture hotkey still overlaps the engine screenshot key here, there will be a follow-up PR later disables the host hotkeys and adds more tools

Overhead

With no RenderDoc present: one flag read per frame in FrameMove and one in CRender::Render. Marker sites read a per-frame cached listener state instead of the BeginEvent/EndEvent pair each site issued before, so the no-debugger path is cheaper than it was. d3d9.dll is loaded only once something is already listening. Render target naming is a one-off SetPrivateData at creation. R1, R2 and R3 are untouched apart from two launch-flag enumerators, R3 compiles only the naming helper.