* 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.
* Now you can build the python modules without building the full UI,
which is mostly useful for docs builds so we can do a minimal compile
and still generate the docs.
* 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.
* We search first in specified folders by the user (they can browse to
the android SDK and java JDK).
* If the tools we want aren't found there, we look relative to the UI
as we now distribute the required tools with windows builds.
* If we still don't find them, we prefer to look in PATH since the user
has 'opted in' to any tools found in there. If the tool isn't in PATH
either then we look relative to known environment variables.
* This will enable the last few python list emulation functions, like
index (which needs operator== to find objects) and sort (which
obviously needs operator< to sort).
* This is to support python bindings - the pyside implementation of
QVector, QString, etc is not available to SWIG, so SWIG treates these
all as opaque types.
* Rather than trying to set up bindings that work for rdcarray and
QList/QVector, or implementing separate bindings, we instead just say
that the public interface must use the rdc types. In most cases they
seamlessly convert to/from Qt types anyway.
* In a couple of places we use an array of pairs instead of a map. In
future we probably want an rdcdict or rdcmap with proper dict bindings
in python.
* This is a *very* light-touch analytics system that will track the
simplest and most anonymous statistics that can be useful in
determining which features are most used or perhaps underused, and
where it's best to direct development attention.
* It is entirely implemented in the UI layer, no analytics-gathering
code exists in the library that's injected into programs, and of
course no capture data (screenshots, resource contents, shaders, etc
etc) is transmitted.
* Once it's turned on, it will apply to both development and release
builds. It tracks stats over a month, and then at the beginning of a
new month it sends the previous data.
* When the user first starts up a build with analytics if there's no
previous analytics database then they are informed of the new code and
asked to approve it. They have the option of selecting to manually
verify any sent reports, or just opt-ing out entirely.
baldurk