* This way it can be used from Qt or any other UI as well.
* The pipes are created internally and just passed as stdin to the
renderdoccmd processes instead of being named pipes.
* We forward a different range of ports to each device so we can pick
and choose which to communicate with based on its index.
* The index is encoded in the 'hostname' like so: adb:X:deviceidhere
* Whenever we want to interact with an android device we always specify
the device, never leave it to a default.
* In python it's not as quick to get ~0U since ints aren't unsigned or
fixed size. Adding named constants makes it easier for people to use
the right values, and C++ users can still pass ~0U.
* By renaming the renderdoc and renderdoccmd projects to something else
(say 'selfhost' and 'selfhostcmd') then they can be used to capture
renderdocui and the replaying that's happening.
* Only supported on development builds and might break down, but it's
handy to have as an easy to enable option.
* There's also a couple of handy python functions exposed -
renderdoc.StaticExports.StartSelfHostCapture(string dllname)
renderdoc.StaticExports.EndSelfHostCapture(string dllname)
which can be used to start and stop the capture around e.g. a shader
debug operation or a pixel history operation or something similar.
* This also fixes the problem of capturing 32-bit programs with 64-bit
RenderDoc failing to properly insert environment variables and
error'ing when it tries to do it directly.
* If the machine idents differ in significant ways that we'd consider
it to be a different platform (currently just OS), and if so mark it
as supported but suggested to be replayed remotely.
* 99% of the time, you'll only have localhost and the application will
be running on the first ident checked which will return a valid socket
almost immediately.
* Instead of continuing to search through each valid port before
returning valid data, we change the enumerate function to just find
the next valid port and return - so we can update the UI as soon as
we have the first result.
* This API is now intended to be forward and backward compatible as much
as possible. Meaning applications should be able to run without
changing on many RenderDoc versions after the one they are built
against without breaking.
* All function pointers are fetched at once in one versioned GetAPI()
function, to save on constant GetProcAddress/dlsym'ing.
* Otherwise, it's largely similar to the previous API.
* 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.
* renderdoc/api/replay/ contains all the headers for using the replay and
analysis side of renderdoc (like in a UI or auto-testing tool)
* renderdoc/api/app/ contains the headers if you wanted to write a
renderdoc-aware application.
baldurk