* This will easily let an application tell if an instance of the replay
UI is currently connected, and if not launch it and connect. Good for
integrating renderdoc somewhere where you can trigger a capture, and
then have the replay UI pop up to either connect live, or open the
most recently log.
* It's not exactly feature parity but it's a start, and any UI would use
this under the hood.
* This means at least linux has a semi user-friendly way to launch and
capture programs - it's limited but you can just use
$ ./bin/renderdoccmd -c /path/to/program "argument string"
from the root of the repository.
* Logfile and capture options (which can't be set yet, but you could easily
hack in something to set them in renderdoccmd.cpp) are passed via
environment variables to the child process.
* This means that all APIs pass byte string types. ALL strings everywhere
in the entire codebase must be assumed to be and treated as UTF-8 content
not ASCII.
* Gets rid of all the horrible %hs specifiers that caused warnings on
linux! Hooray.
* We convert to wide strings, or use wide characters, only when necessary
to use the Win32 API. Some windows specific code will stay in wide chars
just for convenience.
* Files are already serialised as UTF-8 strings for linux/windows binary
compatibility, so this change doesn't break backwards compatibility.
* 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.
baldurk