What's left is *a lot* of places taking monstrous
std::vector<std::reference_wrapper> and that can't be changed to
std::vector<Containers::Reference> in a source-compatible way. Even that
would be only a temporary change, since the goal is to fully avoid
dependency on STL in those cases.
The final version of these APIs should take
Containers::ArrayView<Containers::Reference> and be implicitly
convertible froom e.g. std::vector<Containers::Reference>. That's
definitely possible, but not in time for 2019.01, so instead of forcing
users to temporary pass a `{vec.begin(), vec.size()}` everywhere instead
of just `vec`, I'm rather keeping these APIs intact.
Since Range1D is now used all over Animation, the vector made it very
annoying to use. That's fixed now. This is a backwards-incompatible
change, but I don't expect the 1D range to be used much, mainly because
it was so shitty to use. Generic code that needs a vector can always
cast to it, like this:
Math::Vector<dimensions, T>{range.min()}
Test for the constructor from pair is no longer accepting pairs of 1D
vectors. I have no idea what I meant by that test case (it's testing the
same thing twice), so I removed one of these.
It was passed by value everywhere else, but not here. Weird. This is a
breaking change, you need to update all your callbacks from e.g.
[](const Float&, const Vector2&, T&) { ... }
to
[](Float, const Vector2&, T&) { ... }
Fortunately I caught this soon enough before the release, this would be
annoying to change later.
The pause should advance at `stopPauseTime - startTime`, but the
*original* startTime. Since I changed startTime to be
`stopPauseTime - startTime`, the pause advanced to
`stopPauseTime + startTime`, which is wrong. Now the timeToUse variable
is containing the real final time to unconfuse everything.
MSVC 2015 and 2017 is clueless when it comes to trying to deduce the
template parameters (C2893: Failed to specialize function template). It
works when calling add<V, R> explicitly, but that makes the API hard to
use and inconsistent between platforms. The only possible workaround is
to make add() take *anything*, casting it to proper TrackView type and
then calling add() with explicit template parameters. This also neatly
resolves the Track/TrackView overload, as the static_cast is either a
no-op or it invokes the conversion operator on Track. The original code
also reportedly makes the Intellisense freezing like hell and adding
this overload fixes the freezes. Three birds with one stone.
The Player class definition is now full of typedefs, with the amount of
comments about why the typedefs are there much bigger than the actual
code. Oh well.
At the moment, with the major use case, which is playing back glTF
animations, one can't use atStrict() because there Extrapolation is
specified to be always Constant. The atStrict() function behaves as
Extrapolate and one would need to patch the imported tracks to add
explicit keyframes at the beginning/end of the duration that emulate the
Constant behavior.
I managed to work around that for Emscripten 1.38.5 by adding an
explicit definition of noexcept Player::Track copy
constructor/assignment, but that didn't solve anything for Emscripten,
iOS or Android. Since I can't reproduce that on *anything* I have on
this machine and it seems that the problem somehow just goes away when
using a more recent Clang, I decided to just remove the noexcept
specifier altogether.
I had a temptation to make it noexcept everywhere except Clang, but that
might add potential portability issues (code that works with GCC would
suddenly break on Clang without any clear reason).
For consistency with all other views such as Containers::ArrayView as
these are all relatively light types and so the construction should be
lightweight as well. OTOH, Track constructors are still explicit because
they're heavy and the user should experience the heaviness firsthand.
Moreover, this will prevent from passing e.g. integer-based keys to
Trade::AnimationData. And this also now allows me to add duration() to
Trade::AnimationData. I also moved all accessors that don't need a
concrete value type to this base class.
Or via an enum + func ptr. Main goal of this is to provide a hint to
users who want to supply their own interpolator (for example with a
different perf/correctness tradeoff, or a optimized/inlined/batch
version etc.).
Will be used to supply general desired interpolation method to tracks to
make it possible for the user to decide about a particular interpolator
function for given type.