* Next step is to display VS and other stage inputs on the input panel.
* Also need to tidy up the fetching of highest mip/array slice etc to
use the same codepath.
* This seems way more reliable and smaller than shipping a compiled .dll
* For some reason I didn't find this method before (I only knew that
you could ship the loose files which wasn't a good solution).
* Tweaked flycam a bit too, but not much.
* Refactored the API/C# side camera classes to avoid exposing a ton of
stuff just to do relative rotations in the arcball via quaternions.
* The arcball lookat position can also be dragged with alt-click or
middle click.
* Also supports other elements as position not just magically-selected
"POSITION" element.
* The option will enable monospaced fonts for all data displays, like
the list of events, API calls, etc as well as pipeline displays, entry
of filename/directory in the capture window and many other places.
Pure UI labelling etc mostly still stays as a serif font.
* A few sizes of controls were tweaked (like headers in the pipeline
windows) so that they didn't just barely overflow with the larger
font.
* While looking at this, it became obvious that buffer viewers and
constant bufferviewers should always display in monospaced regardless,
so that has been changed.
* Errors like syntax and runtime errors in python are thrown as
exceptions. So for when we invoke onto the renderer thread to do some
work, we need to be able to catch those exceptions otherwise the whole
program dies. So over the execute, temporarily switch the thread into
a catching-exception mode, which then gets rethrown on the invoker's
thread.
* Note that BeginInvoke shouldn't be used by python since the callback
might happen after the execution has finished (there's no way to wait
at the moment).
* 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.
* 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.
* 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.
* Still missing several features:
- solid shading of 'secondary' data
- highlighting of vertices/faces/supporting faces
- helpers like axis markers or frustum
- post VS data and re-projection
* So RenderMesh doesn't pick up anything implicitly from the current
event, log, pipeline state etc - everything it needs is explicitly
provided by the config parameters (note this might include a buffer
generated by postvs data fetching, but the implementation now doesn't
need to care or treat it as a special case.
* This has been bugging me for ages, it's not a problem typically for users
as the config would be saved on shutdown, but if you're debugging
renderdoc and you kill the process (by stopping debugging) after loading
a log but before closing the program, the recent file wouldn't be saved!
* 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).
* 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.
* 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