* It's required for replay applications to call InitialiseReplay() before doing
any work, and to call ShutdownReplay() once they're finished.
* This lets us do more heavyweight shutdown work before global destructors are
being invoked and the RenderDoc instance is being destroyed.
* Anything that needs to be shut down during capture still has to happen in
RenderDoc::~RenderDoc since we obviously can't get the application to call a
shutdown function in that situation.
Converting std::wstring to std::string by constructing the latter with
wchar_t iterators result in implicit conversion of wchar_t to char which
trips Visual Studio 2019 compiler into throwing a warning of potential
data loss during conversion. Use conv() helper function to do the
conversion and please the compiler at the same time.
* This means it outputs natively/properly to stdout/stderr and its output can be
redirected with pipes.
* It does mean we need to be very careful whenever it's run internally to not
pop up a command window, which happens by default.
* 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.
* This means we won't get an ugly console window popping up when running
renderdoccmd on windows, but if we run it from a terminal then we'll
get output as normal.
* One downside is that cmd.exe seems to snoop the exe type (GUI or
console) and if it's a GUI application it returns to the prompt
immediately. bash for example though waits for process termination.
* The other is that pipe redirects to file don't work properly.
* This way it can be used from Qt or any other UI as well.
* The pipes are created internally and just passed as stdin to the
renderdoccmd processes instead of being named pipes.
* The functions are still exported and that's all renderdocui cares for.
* The interface is no longer to be used so gets in the way of the
generated SWIG bindings.
* This gives a little nicer syntax, a bit better type safety, and also
reflects better for SWIG bindings. Overall it's a minor change but
better.
* We don't update the C# UI at all, since it's soon to be removed and
not worth the effort/code churn.
* For now so we're ABI compatible with C#, all enums are uint32_t, but
that is an obvious optimisation in future to reduce struct packing.
* We avoid 'None' as an enum value, because it's a reserved word in
python so will cause problems generating bindings.
* Using OS-specific append writing functions instead of simple fopen/
fwrite/fclose we can guarantee that multiple processes writing to the
same log file won't trash or interleave their log output.
* To make the logs readable the PID is now included along with the
project/timestamp.
* After that, we make sure that when we launch a program we set the
output log to the same file as the parent UI. This keeps all the logs
together and removes user confusion over which logfile is needed.
* We also move all of RenderDoc's temporary files under a RenderDoc
folder in the temp folder, instead of scattering the files in the root
* 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.
* Previous versions accessing the http URLs will be redirected soon (as
of time of writing this). The POST /bugsubmit won't be redirected as
it's not feasible to redirect POST requests, but that will continue
working.
baldurk