* If buffer wasn't a multiple of 4, a Buffer.BlockCopy call could crash
* Unsigned byte indices (for GL) weren't supported
* Post-transform index buffer was assumed to just be uints, but in fact
it is the same size as the drawcall's existing indices.
* You can't set SplitterDistance unless both MinSize values will be
respected, which needs a big enough window. Smaller than that, we just
have to skip setting the size.
* Note at the time of committing there are still some warnings in MS
headers that you might need to suppress in a couple of files.
* 3rd party code just has the warnings suppressed for ease of merging.
* The majority of warning fixes were for local variables shadowing
other locals, function parameters, or members. In most cases they
weren't a problem, but in some cases it was potentially dangerous!
* What gets listed as a 'drawcall' is a bit fuzzy - previously it was
drawing calls, dispatches and clears, but you could make a good
argument for these to be included as well. As a semi-experiment, these
calls are now included and will be listed in the event browser.
* Other calls can change resources like direct buffer or texture uploads
and Map() type calls, but these remain as API calls listed between
draw calls. Again this is mostly an arbitrary distinction.
* D3D11 logs are backwards compatible, GL logs are not (although it'd
be relatively simple, GL logs will likely break backwards compat soon
anyway, so not worth supporting it now only to break it soon).
* Since RenderDoc is heavily mixed .NET/C++ code, regardless of any
disadvantages this option is practically required (e.g. if building in
profile, the first error message or assert will take the program down
as the breakpoint won't get caught).
* In the UI, enabling this option will always go into csproj.user, but
in fact the option works fine if you manually put it into the csproj,
which means this will be the default for all new clones. Yay!
* Previously for post VS data we could maintain the index buffer by just
doing the stream-out/transform feedback for a point list with each
unique index. To maintain the index buffer we padded out any gaps in
the indices with a single value, so that we could just shift the
indices. This causes severe problems though if the indices start at 0
and contain an invalid value like 0xcccccccc - we'd allocate a huge
array and perform a massively wasteful streamout.
* Instead, we just stream out on the tightly packed list of unique
indices, then remap each 'real' index to where it is in the tightly
packed output buffer.
* When we figure out which event a marker region should jump to if you
select the parent, we want to pick the last valid event ID that isn't
just a label. However previously this was being done by iterating over
the children and picking the last one and assuming there would be a
node of that index - which isn't true in the case where some drawcalls
were entirely omitted. It would either index out of bounds, or index
incorrectly.
* The UAV array is provided as we expect it - with UAVs from 0 onwards
even if their 'slots' are 4, 5, 6 etc or whatever. UAVStartSlot is
the slot of the 0th UAV.
* I doubt anyone will notice the file->open filter unless they look for
it so it's no good for 'discovering' the image viewing capability, but
it might be convenient for people who know about it.
* In D3D11 the RTs and UAVs have the same namespace, but GL has separate
framebuffer attachments and images. This change splits up the concepts
so the D3D11 case is a special case, in a way, and that we can handle
any generic mix of the two nicely.
* For each texture you view, it will reset back to mip 0 and slice 0
as it previously did, and it will also reset the channels back to
RGB only, which is new behaviour.
* Then each texture remembers those settings, so if you choose to view
slice 6 & alpha only of a texture any time you switch back to it
you'll see slice 6 & alpha only.
* It can be disabled in the options, but this is the new default
behaviour. Possibly in future the zoom level and visible range might
be rolled into this, but for now I think they might work better as
global state.
* Since the addition of the normalised UV co-ords the status bar will
flicker in width horrendously when scanning over a texture and it's
impossible to track where you are. Even worse, if the text is wide
enough (or the window narrow enough) you'll end up with the status
bar flickering between one and two lines - which is awful.
* For now I've added some padding for numbers and set a fixed width font
so the only varying element is the actual texel value, which is
unavoidable in the general case. The text is probably wider overall
so I'll need to see what feedback I get.
* glsl and hlsl custom display shaders are kept separate, and only shown
for the appropriate log type.
* The little snippets added in the shader editor aren't updated yet, and
none of the pre-defined shader constants are filled out.
* If hardware support for feature level 11 isn't present, fall back to
the WARP software rasterizer. This will support everything needed, but
it certainly won't run well.
* There are loud warnings - I added a debug message to the debug errors&
warnings window so the status bar will indicate that, and it's in the
title.
* At most once every 3 weeks there will also be a message box pop up
when loading a log, to remind the user so that it isn't forgotten, as
for obvious reasons this is not the intended use-case (hopefully once
per 3 weeks isn't too often to be annoying).
* Client code can enumerate the IDs of counters that are supported -
some of these will be general, some will be IHV specific. It can also
request descriptions of the counters to determine the type of data or
units. This can be used to 'discover' counters that aren't hard
coded into renderdoc. I'll want to at least reserve IHV ranges so that
counter IDs are globally unique, and ideally IHV counters will also be
predeclared where possible.
* Also the refactor removes some ugly rdctype::array use outside of the
replay layer and replaces it just with std::vector, which is a nice
bonus.
* We stream-out or transform feedback the whole instanced draw at once,
producing a buffer containing all N instances in one. Then when the
client requests postvs data, an offset into the buffer is calculated
(in 1/N chunks) and carried through everywhere.
* Since we were using the offset to indicate where the system position
output lay for since-last-clear auto drawing of meshes, we rearrange
the output attribute order so system position is always first in the
list.
* Also since-last-clear now doesn't include the current event, but does
include any previous instances before the current instance.
baldurk