* In a previous update in 2021 many copyright ranges were truncated
accidentally, and some files have been copy-pasted with wrong years. These
dates have been fixed based on git history and original copyright messages.
All places that used is_exr_file already had first four bytes
of the file read into memory. So make is_exr_file work just
like is_dds_file does and check those bytes directly, no need
to hit stdio again.
* UE5 at least currently (as of this commit) re-signs D3D12Core.dll by Epic.
Rather than failing to load all such captures, only fail if the capture is
marked as downloaded since local captures should be implicitly trusted.
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* The timestamp base is queryable from the capture file and settable too, and
conversions preserve un-rebased timestamps. Only rebasing when loading a
capture for replay.
* When we're capturing programs with high-frequency enough API calls, the
overhead of the math & extra function calls over Timing::GetTick() is
measurable. Removing it and serialising pure tick based durations/timestamps
and then converting on replay gives us identical results and saves time while
background capturing.
* We instead always have 3rdparty/ in the relevant include search paths and rely
on that. Each library still has its own unique base dir within 3rdparty to
clarify where the include is coming from.
Added a special chunk flag indicating that chunk size is a 64 bit value.
This allows to handle larger chunks (which heppens quite rarely) while
still maintaining backward compatibility with the majority of traces.
Bumped RDC file version of 0x101 (1.1) to make sure older version cannot
read the new file format.
By default RenderDoc saves captured frame thumbnail image as JPEG which
is lossy compression and makes it difficult to use as a reference image
for testing. Added an option to save thumbnails in different formats.
In order not to change the binary serialization format of .rdc files, if
the thumbnail format is not JPEG, a default JPEG thumbnail is still
saved in the file header as before, while the actual thumbnail is saved
as an additional chunk in the binary sections list. Older versions of
RenderDoc will just ignore this section and still use the legacy JPEG
thumbnail.
Change-Id: Icbf4fbd629719b49868fb785a656f6c7c9946ef9
* In theory all sections of a known type should be written with their
proper normalised name, but just in case a capture is a bit misformed
let's try to look it up by type.
* Previously once we started loading a capture we'd blindly continue
until we loaded it (and then it's assumed to be successful), or we
crash.
* Now errors can be reported during serialisation and bubbled up to
abort the file load process. The next steps are to add error checking
in each function serialise before doing any replay calls to the API
with potentially corrupt data, and on top of that catching API-only
errors when the serialisation is (seemingly) fine, and propagating
those in a reasonable way.
* We also harden the serialisation a bit so that if it reads an
obviously invalid byte length for a buffer or array count, it won't
continue. It's still not perfect as the sizes could still be large and
invalid but within range, but it should catch the worst cases.
* The new serialiser system will not handle the container file itself,
so we've separated it out to deal in sections and stream I/O to read
from and write to sections.
* We also add the ability to choose the compression scheme for a section
instead of always using LZ4. LZ4 will still be used on the fly for
fast write performance, but then RDC files can be re-compressed for
savings offline.
baldurk