* The exact contents depend on the API - on D3D11 this is the bytecode
blob, on Vulkan it's the SPIR-V. On OpenGL it is just a concatenation
of all the source files passed in sequence.
* If there's no replay context we can still use the live connection to
copy and delete captures remotely. Try to use that whenever possible
and warn the user when it's not possible (i.e if the program has been
closed and there's no replay context, we have no way to access the
files anymore).
* If the user tries to open a remote log without a replay context,
prompt them either to swithc to a replay context on that host or to
save the log locally.
* This lets us detect when a remote server has been disconnected and
needs to be restarted, as well as alerting the user if this happens in
the middle of a replay session.
* Pinging other hosts means the context switcher is reasonably up to
date if one of them comes up.
* 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.
* This includes an enum for unsupported (but recognised) image formats
instead of just a generic 'file corrupted' or misleading 'API
unsupported' error.
* This is primarily for vulkan, which supports either xlib or xcb (and
not necessarily both). GL still only supports xlib, windows and
android only support one system regardless of API.
* This should also support xlib again for fetching keystates etc.
* Previously it was treating maxfigures as the required length of the
fractional part, so you'd get a lot of pointless 0s. it should be the
number of significant figures, so we pretty much reuse the non-exp
formatter.
* 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.
* This is only applicable really on D3D11 where the underlying texture
can be typeless, and a default interpretation as unorm/float won't
necessarily how the texture is actually being used.
* Since the Vulkan views are tighter and more strictly specified, we can
always safely use the view format (in the non-mutable case it must
exactly match the underlying resource's format).
* Only one major piece of functionality is unimplemented and stubbed out
- WriteToSubresource and ReadFromSubresource in concert with passing
a NULL D3D11_MAPPED_SUBRESOURCE parameter to ID3D11DeviceContext::Map.
baldurk