* This means when multiple fragments are writing to a pixel you can choose
precisely the one you want to debug, rather than the debugging always
running the approximately last fragment to pass
* Expand the abilities of the GetTextureData in replay drivers
to be able to resolve samples and render down to RGBA8 unorm
for file export to other programs.
* Greatly improve the ability to save textures - in theory any
texture format/type/dimension/etc should now be mappable in
sensible & useful ways to output formats.
* 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).
* http://blog.selfshadow.com/2012/11/12/counting-quads/
* Quad Overdraw based on ScenePS4 from the revised implementation. The
colours are new, up to 20 levels. Picking pixels shows the overdraw level
* Available per-pass and per-drawcall, a pass defined the same way as in
the mesh view, drawcalls since last clear or RT change.
* List of events now passed through to RenderOverlay the same as RenderMesh
* For APIs where the shader namespace/bindpoint (which may be arbitrary
like 'the Nth texture resource' can be mapped, at each event, to the
actual API bind point where the object is.
* On D3D11 this is pass-through, on GL this returns the value of each
uniform.
* This also means GL shader reflection structures are properly immutable
and the variance in the uniform values is handled elsewhere.
* In future this might need to be expanded to support more complex binding
methods, where the mapping returns the resource rather than just mapping
to an integer bind ponit.
* A label is shown at the top of the pixel history showing the range
display and visible channels. The channel visibility behaves the same as
in the texture viewer - 2 or more and the other channels display as black
and 1 channel displays grayscale.
* This means that e.g. decimal separator will always be . and similar
effects, which avoids the need to have culture specific formatting or
special-case handling around CSV export etc.
* The explanation is in the FAQ but the short explanation is that most
data e.g. normal maps are conventionally displayed as if they contained
SRGB data, so RenderDoc does the same so things look as expected.