* This is a bit less ambiguous and less confusing in the case where
someone is expecting a "compile" type button instead of "save changes"
type button.
* We can't reliably know when we can safely remove the layer property
at capture time because it's impossible to know if an android app will
use vulkan or not. So instead we fall back to unsetting it whenever we
need to - before opening a capture or when shutting down the remote
server (in case after capturing, no frame capture was actually opened)
* This means that if the UI crashes without unsetting it, we will poison
the state, but this seems unavoidable.
* As explained in the code, if we repoint an input variable to refer to
a previously declared private type, it might start referencing forward
in the SPIR-V which is invalid. So to fix this and be safe, we just
move the variable to the end.
* We want to make sure every section always has at least one word in it
so we can unambiguously tell which section we're appending to. If the
debug section is empty, it's hard to tell the difference between
appending to the entry point section and inserting into the debug
section, so we add a nop that will get stripped out later.
* The reason is if comparing directly against the end of a section, we
could skip over it if the section ends in a nop and the next section
starts in a nop. Instead < will always work as expected.
* If you have any questions about the analytics please contact me
directly at baldurk@baldurk.org
* Enabling this now to give realistic usage for anyone testing over the
next month, and also to pre-populate stats for the time 1.0 comes out.
* If we don't track their lifetimes specifically, then we can end up
with the situation where an application makes more state objects over
the course of its rendering than is legal (there can only be a max
4096 unique state objects of each time). This could happen if an
application creates state objects each frame with slight variances,
but then releases them again.
* ID3D11Device::CreateInputLayout will fail if we pass a NULL descriptor
array pointer, even though 0xdeadbeef will work so it doesn't actually
use the pointer at all.
* On windows it's strongly desired to be able to compile straight out of
a clean checkout or source download. This means anyone can download
the source and investigate something quickly, without having to worry
about the hassle of figuring out how the project downloads 3rd party
dependencies, fetching them, getting them registered in the right
place.
* This can't be put in a submodule as git submodules don't get
downloaded by default so people new to git will get confusing
compilation messages, and someone downloading the source from github
directly without cloning via git won't get submodules included.
* It does add some extra size to a fresh download/checkout which is
unfortunate, but absolutely worth the cost. Shallow checkouts still
aren't unfeasibly large, and it's only a one-off cost at clone time.
* It's already optional on linux due to distributions not necessarily
carrying packages for it yet. We also make it optional on windows
since by the same measure it's not a huge problem if it's missing, and
official builds will include it. This means we don't have to ship the
binary dependencies
* This helps on android where we might fail to create the preview window
if our app isn't in the front, but we still want to let the base loop
know that we're done previewing and let it go back to the generic
splash screen.
baldurk