* The majority of GL calls that create objects are pretty failure proof
since they don't really do anything apart from create/allocate. In the
case of glCreateShaderProgramv though it requires the call to be valid
e.g. the type enum to be correct, so it can actually return 0 if that
happens.
* If we don't check for this then we end up creating an ID and program
for name 0 which causes all sorts of problems.
* Thanks to build-master general @aras_p for the tip:
https://twitter.com/aras_p/status/841287101907910656
* The projects are still defined with the usual platforms Win32 and x64,
this only affects the naming in the solution configurations.
* Previously on VS2010, the DIA2 library wasn't properly supported on
64-bit, so it needed a separate program that always ran 32-bit and
proxied operations over a named pipe.
* Now DIA2 will load correctly in 32-bit and 64-bit, so we can do the
work in-process without needing the separate exe.
* We still need to distribute dbghelp.dll and symsrv.dll, so these now
live alongside renderdoc.dll in the build/install folder with matching
bitness.
* At the same time fixed a bug I noticed where the 0-based module index
would return 0 for the first valid module and be treated as invalid.
* Truly, this is a sad day. But unfortunately many dependencies are just
not supported and it's increasingly difficult to stay on VS2010.
* In an ideal world, the IDE and compiler would be decoupled, but that's
not the case.
* This is useful if the build doesn't happen within a git checkout and
you want to pass in the hash anyway, but it also allows adding
suffixes like -official etc.
* This happens with atidxx64.dll which gets loaded as a stub and a real
thing. If we hook the wrong dll then we might not intercept some calls
that go to the real thing.
* In particular, LiquidVR tries to use the AMD extensions and if we
don't properly block those calls, it will lead to a crash on replay.
* We don't support self-hosted captures this way, and this prevents a
crash if the user accidentally left the env var set when running the
replay program.
* The drawcall may modify some pipeline state - e.g. we want to fetch
append/consume counter values after the draw to be consistent with the
rest of the UI, and if the draw is a renderpass boundary we want to
fetch the bindings after the renderpass has started, not before.
* This most commonly happens launching an Android program that takes a
while to launch, or if you're launching a program with the delay for
debugger option set.
* Instead of the whole UI hanging, you'll get a progress dialog to
appear while it's waiting.
baldurk