* 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.
* For now, just redirect to 127.0.0.1 and assume the user has proper
port forwarding set up, but in future we'd do this ourselves and maybe
parse out a device name after the adb:
* 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.
* Tweaked flycam a bit too, but not much.
* Refactored the API/C# side camera classes to avoid exposing a ton of
stuff just to do relative rotations in the arcball via quaternions.
* The arcball lookat position can also be dragged with alt-click or
middle click.
* Also supports other elements as position not just magically-selected
"POSITION" element.
* 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.
* The core class is now responsible for tracking the active window and
cycling through, so it can cycle through multiple APIs.
* For GL we only set up associations for capturable windows, and only
those that present (since helper windows are often created). Since
GL doesn't really have a 'this window is done rendering' call, we just
decay old windows that haven't presented in >5 seconds.
* Also on GL, legacy/uncapturable windows aren't associated so they will
not cycle to at all.
* The embedding API now expects a device pointer and window handle to
set active window or start/end a capture. You can still pass NULLs if
there is only one API active.
* To remove renderdoc (e.g. if the API version doesn't match what is
expected), user code can call RENDERDOC_Shutdown() to remove the running
thread and undo any library hooks, then unload the dynamic library.
* This still isn't recommended as there could be unexpected side-effects,
and it will definitely break if this happens after any APIs have been
initialised, but it's an option.
* 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.
* Plugins/apps that build against the header (and so get the
RENDERDOC_API_VERSION macro) can call this to verify that they're running
against compatible API functions. If the versions don't match, the app
should immediately quit.
* The functionality is exposed via dllexported functions so that apps can
call it to tweak renderdoc's behaviour when injects.
1) Can now turn bits of the overlay off, or hide it entirely.
2) Can also manually start and stop a capture on a given window. This
skips the need for swapping between active swapchains, and allows the
app to define the exact region of D3D11 calls to be captured (could in
fact be many frames).
The window provided determines the swapchain used for thumbnail, and
also implicitly specifies the device to be used for capture.
baldurk