* Should mean the 'target' of the render target will be selected by
default now when clicking to an event, without annoyingly switching
away from what you were looking at.
* I don't know if this is particularly justified, but I think square RTs
are much more likely to be 'data' RTs updated each frame, not leftover
frame data that will be overwritten. That I know of, there are no
square resolution output displays (they're always portrait or
landscape and rectangular).
* 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 fixes shader editing when the entry point file wasn't the first
in the list.
* Might need better detection of the main file than just searching for
the entry point substring - could produce false positives in other
files in a comment or #define or something similar?
* This will easily let an application tell if an instance of the replay
UI is currently connected, and if not launch it and connect. Good for
integrating renderdoc somewhere where you can trigger a capture, and
then have the replay UI pop up to either connect live, or open the
most recently log.
* Some naughty applications assume refcount will hit 0 if they release
all references but keep the object bound to the pipeline, so for
compatibility's sake we preserve this behaviour
* To simplify things we assume there won't be any user swizzling on
luminance or alpha textures, and just apply our own to emulate rather
than attempting to store & stack them.
* An array of resources like SamplerState foo[8]; or Texture2D blah[8];
show up as one entry in the reflection data, so need to be expanded
out to several entries.
* Normally it's OK to overlap two resources in the same bind, as long
as only one gets used - this doesn't matter to us since only the used
one will show up in the reflection data. Unless there's an array e.g:
SamplerState foo[8] : register(s0); // [0] and [5] used;
SamplerState bar : register(s3);
in which case foo[] appears in the reflection data for the sake of [0]
and [5], and bar will appear too (causing an overlap between foo[3]
and bar. Since we know the reflection data is unambiguous, we
prioritise individual entries over array entries by listing them
first and using the first match for any bindpoint.
* External users identify the D3D11 frame capturer by the ID3D11Device *
but if we don't do that cast explicitly the returned pointer is not
correct to what is returned to the user on device creation.
* Normally the cbuffers when listed in resources (to give the bind point
info) and the cbuffers listed with their variables are not necessarily
in the same order, so we match them up by name. It's possible to get
multiple cbuffers with the same name though, so in this case we just
have to assume they come in the same order in both lists.
* We do this by appending _s to each duplicate name (so handling many
duplicates) in both iterations.
When assigning to the void** output parameter in QueryInterface, ensure
that the pointer written into the output is a COM pointer by casting to
the correct branch of the multiple inheritance.
As commit 2558b2cde introducing this functionality claims to return an
IUnknown*, so does this commit.
* Still leaving some upper limit so that typos don't result in a zoom
level of something crazy.
* This also allows 'fit to texture' to zoom in more, but I'm OK with
that.
* The DXBCFile* is new'd in the wrapped CreateShader function and passed
to the wrapped shader instance, and ownership of the pointer lives
with the ShaderEntry in WrappedShader::m_ShaderList.
* On destruction when a shader removes itself from that list, the
DXBCFile* is deleted.
* The same lifespan applies to the ShaderReflection*
* In extreme cases a program can create lots and lots of unique short-
lived state objects, we cache them all and run out of the 4096 state
objects that can be around, then further creates fail out.
* To handle this, if we have 4000 total state objects, we release any
that are purely being held by us (not the program). This isn't an
ideal solution but it's quite simple and non-invasive, and only has
a slight impact on rare Create calls.
* Most programs will either create a few up-front (as intended), or at
worst create a few dozen or even few hundred then re-use them as they
are cached.
baldurk