* This option will now toggle on the behaviour to fill undefined buffer contents
with a marker value, both if they're created without data (it will be zero
filled instead) or mapped with discard (it will keep the old contents
instead).
* There were too many hard to find problems or misconceptions about the buffer
filling for it to be useful. Now it will be opt-in instead.
* This happens at the application's risk since there's no way to know what
effect the vendor extension will have or even if it will work together with
renderdoc's hooking.
* The new function SetCaptureFileComments allows users to add comments to a
capture after creating it at any time.
* We also use anonymous union to remove the need to duplicate API structs for
backwards compatibility.
* This option has always been a mixed bag - when originally written captures
weren't compressed at all so saving the cost of a initial contents on a
gbuffer would have a significant savings.
* Now with compression the savings are lesser, and it's a source of
bugs/confusion for the case where either a bug is caused by leaking data from
the previous frame or worse still the contents are discarded incorrectly.
* D3D11 will now behave as the other APIs will - saving initial contents
whenever needed even if they seem like they might not be used.
* In-application API is bumped to 1.1.0 as a new function pointer is
added to the end of the structure.
* This comes with some caveats - capturing a frame is fairly heavy
weight, so capturing a frame might throw off timing-related bugs you
are trying to capture in subsequent frames. If you know your bug is
every other frame though, capturing two can be a quick way to ensure
you get it.
Notes
======
- With no clean way to do string comparisons in the C preprocessor, have a define per-platform. This avoids the clever string concatenation for determining the OS-specic bits, and allows SN-DBS to distribute builds without custom rewrite rules.
- Fix up instances of WIN32, etc., in non-3rdparty sources to refer to this.
- Move the per-platform specific bits into their own subdirs.
* 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 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.
* Has a couple of limitations - won't check deferred context or
NO_OVERWRITE Map()s except in a captured frame. This could in theory be
implemented but it'd be complex and I don't want to complicate/break
the normal path.
* When an overrun is detected, a messagebox pops up to block the thread,
and if you hit yes, it will debugbreak.
* 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