* This will allow the adding of things like 'redundant api call' for calls
that have no effect, as well as potential problems like drawing with an
empty viewport, or similar things that are common problems. Reading out-
of-bounds on buffers etc is a good example of 'defined' behaviour that
is probably not desired.
* These heuristics could also identify potential performance problems.
* It also supports adding debug messages after log-load time, so you could
do an additional extra-strength pass, or do a detailed check of one
draw call (e.g. a broken draw, to try and figure out the problem). If
there are any unread debug messages, the status bar will flash and the
debug messages window will show a count as (N).
* This allows 'partial' rows in the mesh viewer, if a vertex input element
references invalid/out of bounds data, but the others are fine (coming
from different streams).
* This way if someone updates their install without clicking the menu item
to clear this flag, it will still detect the update after a few days.
* (And when I forget to update which beta is latest, it will fix itself
eventually. Oops).
* You can choose which component will be used as 'position' when rendering
vertex inputs. Helpful if a position component isn't auto-detected, or
if you want to render UV co-ordinates onto the screen.
* Instead of fixed TEXCOORD0/Color options for solid shading onto the mesh
you can choose a secondary column yourself.
* Also the solid shading options are available on vertex output meshes as
well as inputs.
* Crash report was submitted indicating a crash here, which is either
memory issues or momentarily crazy-large window. We can catch the
exception and just clear to black.
* This was found on a flash stage3d sample, where if the input signature
is stripped, some signature elements can be completely missing, causing
a mismatch when trying to obtain the inputs for pixel debugging.
* In this case, we try to fill in from the previous shader, and if that
fails just inserting a dummy element and hoping for the best.
* Has a couple of limitations - won't check deferred context or
NO_OVERWRITE Map()s except in a captured frame. This could in theory be
implemented but it'd be complex and I don't want to complicate/break
the normal path.
* When an overrun is detected, a messagebox pops up to block the thread,
and if you hit yes, it will debugbreak.
* 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.
baldurk