This removes dependencies on deprecated tools "ant" and "android project"
The new method relies on JAVA_HOME and ANDROID_SDK being set.
It also requires specific versions of the Android build-tools (26.0.1) and
platforms (android-23). See updates to CONTRIBUTING.md and our Travis-CI
config for details.
Travis-CI and documentation also roll forward to latest public NDK r14b.
* In some cases it seems that no sRGB fbconfigs are available, so we
fall back and create a non-SRGB one. This may render incorrectly but
at least it should run without crashing.
* In particular for e.g. elements that don't require a sampler, the
VkSampler may point to a random address if it's uninitialised, and we
shouldn't try to access it at all.
* Most functions we hook and then jump to the real driver we can fetch
just with dlsym to the library, but the ARB context creation function
is an extension and may not be directly exported.
* It's safe to call glXGetProcAddress(ARB) without a context current
though and it's guaranteed to be directly exported, so we can use this
to fetch the function if we don't find it with dlsym.
* This includes ISG1 and OSG1 chunk types which have an extra enum on
the end for the minimum precision type.
* Also add extra casing for min precision types (although anywhere they
are on an externally-facing interface, they're not actually min
precision).
* It's seemingly possible to bind a structured SRV with no format
given, to a Buffer<float4> declaration in the shader. In this case
we can't get the buffer stride/format type from the SRV itself so we
have to go to what's declared in the reflection data itself.
* The change to make the disassembly view not directly a child of a
DockContent but instead a table layout (to add the disassembly type
drop-down) were causing some casts of 'thing.Parent' to fail.
* The +1 for internal NULL terminator must be done internally, otherwise
we end up with "foobar" being a 7-character string of "foobar\0". If
this is then re-serialised we add more and more null terminators.
* In future we could handle async exceptions by storing the exception
information in a std::function derived object (instead of the separate
ExceptionHandling that lives on the stack) and query it out in a new
WaitForInvoke function maybe. Right now we just print the exception
to the output log and abort the callback.
Cody Northrop