Notes
======
- With no clean way to do string comparisons in the C preprocessor, have a define per-platform. This avoids the clever string concatenation for determining the OS-specic bits, and allows SN-DBS to distribute builds without custom rewrite rules.
- Fix up instances of WIN32, etc., in non-3rdparty sources to refer to this.
- Move the per-platform specific bits into their own subdirs.
* Suggest users to use VS on Windows
* Add a top-level wrapper Makefile and disallow in-source builds
* Support clang
* Centralize compiler flags
* Remove all occurrences of "if(WIN32)..."
* Make qrenderdoc an external project
* When I went to explain to someone why the target was named Profile and
not Debug as you might expect, I realised the reasons were entirely
opaque and historical. So instead, rename it to Development since that
is really what it's for - any profiling would be done in Release mode.
* This is kind of arbitrary at the moment, but in future when D3D12 and
Vulkan drivers appear, not everyone who builds RenderDoc will want to
build all drivers, so making them separate projects makes it more easy
to disable/remove them.
* This means that all APIs pass byte string types. ALL strings everywhere
in the entire codebase must be assumed to be and treated as UTF-8 content
not ASCII.
* Gets rid of all the horrible %hs specifiers that caused warnings on
linux! Hooray.
* We convert to wide strings, or use wide characters, only when necessary
to use the Win32 API. Some windows specific code will stay in wide chars
just for convenience.
* Files are already serialised as UTF-8 strings for linux/windows binary
compatibility, so this change doesn't break backwards compatibility.
* This allows you to hook into processes that are difficult to launch
directly with the existing functionality in RenderDoc.
* This is rather risky, as it modifies the AppInit_DLLs registry key to
inject a small shim dll that checks for the desired process and injects
the full renderdoc.dll. If that registry key got left, or if there was
some incompatibility with the shim dll, you could have problems. It
should only ever be used as a last resort if there's no other way to
capture.
* renderdoc/api/replay/ contains all the headers for using the replay and
analysis side of renderdoc (like in a UI or auto-testing tool)
* renderdoc/api/app/ contains the headers if you wanted to write a
renderdoc-aware application.
* This means people building on VS2013 don't need to rebuild breakpad
locally to link successfully.
* Committed binaries built on VS2012 Update 4 and VS Express 2013 for
Desktop, which will hopefully work for everyone.
* Also for float/unorm texture add an additional "resolved" option that
just does an unweighted average of all samples, which is the behaviour
from before (assuming that's what ResolveSubresource does).
baldurk