* D3D11 you query for interface with UUID of
{A7AA6116-9C8D-4BBA-9083-B4D816B71B78}. It's just IUnknown*
* GL implements GL_EXT_debug_tool with spec here:
https://renderdoc.org/debug_tool.txt
with DEBUG_TOOL_EXT #define'd to 0x6789, DEBUG_TOOL_NAME_EXT to 0x678A
and DEBUG_TOOL_PURPOSE_EXT to 0x678B. For now, reporting this ext is
enough to identify RenderDoc.
* If CreateContextAttribs is not used to create the context, the overlay
will run in super-duper old mode using immediate mode calls and fixed
function pipeline. This way it should display on (in theory) any GL
app. Capturing will be prevented.
* Compatibility profile contexts are still allowed, but a warning is
displayed in the overlay.
* If CreateContextAttribs is used to create a < 3.2 version context, we
go down the same path as for legacy contexts, except with an accurate
overlay message (just that the version isn't supported).
* Also in many places OpenGL is now advertised as full support, since it
is pretty close by now and needs people to jump on it full-time and
use it in anger.
* This allows you to hook into processes that are difficult to launch
directly with the existing functionality in RenderDoc.
* This is rather risky, as it modifies the AppInit_DLLs registry key to
inject a small shim dll that checks for the desired process and injects
the full renderdoc.dll. If that registry key got left, or if there was
some incompatibility with the shim dll, you could have problems. It
should only ever be used as a last resort if there's no other way to
capture.
* The explanation is in the FAQ but the short explanation is that most
data e.g. normal maps are conventionally displayed as if they contained
SRGB data, so RenderDoc does the same so things look as expected.
baldurk