- ShaderDebugState now carries a 'flags' that can be updated when the interpreter is run. Currently supported flags are 'sample/load/gather insn' or 'insn generated nan/inf'.
- DXBC interpreter now pushes operation type into results for simple intrinsics. This avoids the situation where temp decls are by default uint-typed, and any arithmetic operation on float or double operands would result in a uint shader variable. Other intrinsics are largely correct because they create temporaries with appropriate typed constructors.
- Provide icons for user interface elements, based on the existing 'run to' icons with modifications by myself.
* In a couple of places I had to resort to if(IsHighContrast) but mostly
this is just using system brushes consistently or not assuming black
text.
* The default DockPanel theme doesn't work well, so make a minimal high-
contrast theme for it and assign it everywhere.
* The pipeline flow was using fixed colours, use system brushes for the
different elements and switch based on high-contrast to ensure active
and inactive stages are visible (using ActiveCaption looks bad on
normal themes because it's a big block of colour).
* For some reason the flat toolstrip renderer doesn't handle white-on-
black themes, but the system one does. It's a little clunkier but it
shows up correctly without writing tons of custom painting code.
* Range histogram uses a properly contrasting colour for the border.
* Treelist views use a better system colour for selected rows when
inactive and hovered rows (when high contrast).
* Mesh view grids have a system background instead of white
* Various things (pipeline state, mesh viewe) set text colour when
colourising backgrounds of things instead of assuming black.
* I think eyes are just more use to parsing legal identifier characters
(like _s) rather than {}s syntax. It feels like it's probably more
readable overall, although there's more of a risk of it blending into
the names in the original code
* There were two bug reports of NullReferenceException on line:
hoverWin = m_HoverNode.OwnerView;
* Which doesn't make sense since m_HoverNode must be non-null to go by
the lines above, and all the callbacks should run on the UI thread so
it can't be a race.
* Caching locally and checking for OwnerView/ListView being valid might
fix the crash. Hopefully!
* 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?
baldurk