* 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.
* This is a deliberate break of compatibility since the field is now often
empty, for non-markers. This means code will get a more explicit error when
the name is being referenced, so it can be updated to fetch the name it needs
as needed.
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
* These map more naturally to python tuples and are easier to wrap in and out.
* We also tidy up the FloatVecVal etc and standardise the members of
ShaderValue.
* One automodule in a file for our modules is way too much, so we split it into
files. Unfortunately this means that only one file can have those classes and
functions be linkable from elsewhere.
* Instead we bite the bullet and manually curate the items into pages, and at
the same time subdivide the 'enums and data' page more which is a general
readability and usability win as well.
* We also add some previously not-included functions, and add a doc-build time
check to ensure that functions and classes aren't omitted from the
documentation in future
* It may work since the python scripting is generally not Android specific, but
Android itself is quite likely going to cause problems that are out of scope.
* Others using automodule:: must have :noindex:.
* I'm unclear when this is required - travis hit an error on this but I couldn't
reproduce it locally, but it seems harmless.
Fixed "IndexError: tuple index out of range"
`value = tuple(float(value[i]) / divisor for i in value)`
Was effectively attempting to access the value tuple using an element as an index.
`value = tuple(float(i) / divisor for i in value)`
Uses the elements from the tuple and modifies them.
Ex: (0,0,0,255) becomes: (0.0, 0.0, 0.0, 255.0)
Instead of throwing an error.
baldurk