* Unifying these views means that constant buffers have all the same
reformatting and it avoids having multiple paths for what is now effectively
the same control (a buffer can either have fixed data, repeating data, or
both)
* GL and Vulkan allow buffers to have fixed variables before a trailing AoS
unbounded array. These fixed variables can't be easily displayed in a table
and previously we skipped them. Now we display these in a tree format.
* We also support formats which don't have an unbounded array at all and display
these just with the tree. This will allow the BufferViewer to subsume the
capabilities of the ConstantBufferPreviewer (though it needs to handle opaque
non-buffer-backed variables, and slot-following).
* These elements are consumed but not shown, so the offsets of subsequent
elements still act as if they're there. This may be more convenient than
specifying a manual offset on the next element or a struct size.
* This allows the calling code to pass a hint of what packing is known or likely
to be used, meaning less generated manual offsetting/padding when the implicit
rules cover it.
* Instead of having a global tight/non-tight we now let the format string
specify the packing rules (defaulting to scalar - i.e. tight packing as
before), and use the resulting properties to calculate packing.
* This is primarily for GL/VK where the packing rules are not pre-defined and
are also not explicitly reflected, so we instead see what rules are broken
along the way to get the most conservative ruleset we can (that way minimising
the need for manual offset decorations)
* There are several different API packing rulesets - GL has std140 and std430
(and packed/shared, which is implementation defined but is likely to be
similar to one of these or more conservative), VK effectively has rules for
those both, as well as scalar packing which is close to C packing. D3D has one
ruleset for cbuffer packing similar to std140, and effectively scalar for
structured resources.
* These rulesets are quite similar and only differ by the properties here. There
is one exception in the handling of empty structs - but in GLSL these are
illegal so we will take the HLSL interpretation and always treat them as 0
bytes.
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* Newly written shaders and any updated shaders can now use pre-defined macros
to abstract away binding differences between APIs, so custom shaders will be
more portable in particular shaders written in HLSL for D3D or GLSL on OpenGL
won't break on vulkan because they refer to incorrect binds.
* We also add the ability to toggle on/off the replacement being active without
needing to intentionally add a compile error (and this also makes it more
explicitly clear when the shader replacement is enabled or not. This could be
useful for quick A/B testing between the edited version and the original.
* We still need to handle multiple elements in the root of a struct specially by
commenting out the fixed members, but the final element needs to go through
the normal DeclareStruct() path to handle things like per-column padding in
matrices etc.
* The UI will become non-functional and the backend will be replaced with a do-
nothing one that keeps things alive without needing error bulletproofing
everywhere in the real backend.
* We split stepping for source debugging into step over/into/out depending on
how it handles function calls. Step Into is the same behaviour as before - it
steps to the next source line executed regardless of if it's inside a function
call. Step Over is similar but will not enter function calls. We define that
as the callstack growing (so staying the same or shrinking - returning from a
function - is OK), and this is as accurate as the underlying debug
information. Step Out will run until the callstack shrinks, i.e. returning
from a function.
* This is a slight behaviour change of keyboard shortcuts - F10 was effectively
doing step into and will now step over. F11 will step into which is the old
behaviour.
* All these variants have backwards versions, and to remain consistent we keep
the shift modifier as forwards/backwards. This differs from visal studio where
step out is shift-F10.
* The seems like the best balance - using any other variant would likely confuse
muscle memory of anyone used to visual studio (where these shortcuts are
intended to mimick), if only because F10 would be step into whether or not F11
is used for step over or some other key which would likely be even more
confusing either way. Trying to twist to use Shift-F10 for step out would be
inconsistent with the other backwards running operations and likely cause more
confusion than it saves in matching VS's shortcuts exactly. Also an accidental
Shift-F10 is not too destructive, the user can realise it didn't Step Out
forwards, and press Ctrl-F10 or look up the button.
* The hope is that most likely people doing source debugging and familiar with
these keys expect F10 to step over, so the previous behaviour was unexpected
but easy to work around, and that changing the meaning of the key won't
disrupt them. Or at least the disruption is less than other alternatives.
baldurk