* Initially add support for spirv-cross and spirv-dis.
* When possible we'll auto-detect the tools in path or in the build's
plugins folder. Otherwise the user can add it and add their
executable path.
* We still use the first disassembler for editing - in future it would
be good to allow selecting the disassembler at edit time (as well
as allowing multiple compilers).
* On windows, the change in a global GIT_COMMIT_HASH define in each
project needing it meant a full rebuild every time the commit changed.
* Ideally we'd set the define only on one file in each project, but
MSBuild doesn't seem to support that. Instead we make a new tiny
project that compiles a single cpp exporting a global var, and
reference that global var in each other project.
* This was fast before but I started noticing the lag. Instead, we can
do it asynchronously when polling for remote host status, every few
seconds. This should still be good enough as people are probably going
to be used to devices taking a moment to appear.
* Mostly used for passing a progress float back during a long blocking
call like opening a capture or doing a copy.
* This is much more feasible for python to bind to.
* In several cases we just use a tiny lambda that updates a float anyway
since we can't push the progress directly into a progress dialog, but
need to let it query from a temporary in-between float.
* We also let an API be active without presenting, and then note when it
starts presenting. This lets us detect the case where an API has been
started up and used, but isn't presenting so we're not able to capture
it. Less confusing than telling the user no API is detected, and lets
us direct them to the relevant documentation.
* There's also a flag indicating if the API can be captured even if it
does present.
* The main addition here apart from some extra stubs is a new rdc type
for date time objects.
* Although the module doesn't do anything and is only used for docs
reflection it is desirable to not have to link against Qt as this
can cause problems when linking the module without unresolved symbols.
* We split the "update available" off to a top-level menu item, instead
of a sub-item under Help. This gives explicit text saying an update is
available.
* Change the icon from an hourglass to a slightly more 'updatey' image.
* We now re-cehck every week even if an update is marked available. That
way people who delay for longer than it takes to release a new version
will get the latest when they do update. It also gives them a reminder
every week so that hopefully those delayers will be less common!
* We enforce a naming scheme more strongly - types, member functions,
and enum values must be UpperCaseCamel, and member variables must be
lowerCaseCamel. No underscores allowed.
* eventId not eventID or EID, and Id preferred to ID in general. Also
for resourceId.
* Removed some lingering hungarian m_Foo naming.
* Some pipeline state structs that are almost identical between the
different APIs are pulled out into common structs. Where something
doesn't make sense (e.g. viewport enable for vulkan) it will just be
set to a sensible default (in that case always true).
* Changed scissors to be x/y & width/height instead of sometimes
left/top/right/bottom
* Abbreviations are discouraged, e.g. operation not op, function not
func.
* Instead of replaying predication, we now always skip it during replay,
so all objects will render. This is much more consistent and
understandable behaviour instead of things mysteriously disappearing
with no obvious reason why.
* We track the predication that would have happened and replay Begin/End
pairs so that we can know if the predication *would* have failed.
* This is displayed in the UI (currently in the raster state, for lack
of a better location) with the pass/fail that would have happened.
* This information can feed into other places for analysis like the
pixel history.
* The UI dialog is now in Qt. We run qrenderdoc.exe with a very minimal
startup to display the dialog and send the report.
* The flow has been simplified to have less text and an easier time to
just click through and send.
* On the first report, the user is gently nudged to enter their email
address for contact and by default the email is saved for next time.
They're not nagged more than once about this.
* Optionally the user can select to upload the capture. This is always
default off, and there is a confirmation dialog making sure the user
intended to select it.
* After the bug is reported, a unique URL is generated and returned
which the user can then click back on to see if there's any update. By
default the UI will also remember the URL and check it every couple
of days and alert the user in the help menu that there's an update.
* Tag the RenderDoc layer with a version string that
matches the host, including git hash.
* In developer builds, check the version when scanning the
application for RenderDoc support.
* Pass the warning back to the UI to offer ways to fix.
* Update APK patching to remove existing layer.
This is part of the work specified by github Issue 586, allowing the
ability to save out the overlay in the TextureViewer. If no overlays
are on then there is no option to save the overlay. Currently there is
no option to remap the overlay to a grayscale or absolute value range
before saving. This can be a future task.
NOTE: the overlay texture resource that's saved out is not the blended
texture that the user will see in the TextureViewer, it is just the
overlay itself. The ability to save out the blended texture would be a
future task.
baldurk