We would need to duplicate all the functionality found in Vector, which
I don't think is needed at all. If anyone needs to do this, it is
possible to "linearize" the matrix into long vector and do the
operations on it.
Also updated subclass operator implementation, added tests for it, both
for proper returned value and proper result type.
Operators that are part of Vector are operating only with the same type
as Vector itself, operators for multiplying/dividing integral vectors
with floating-point numbers and vectors are now out-of-class and enabled
only for integer vectors. It allows better control (e.g. multiplying
integer and floating-point vector will _always_ result in floating-point
one). Thoroughly tested integer/FP operations and also reworked and
tested operator and funciton reimplementations in subclasses, both for
value correctness and result type correctness.
Found even more stuff broken -- copied contents of
Corrade::Utility::Directory::Flags into Magnum::Context::Flags (WTF!),
asterisks in code listings... IS IT SO HARD TO FIX ONE THING AND DON'T
BREAK THOUSAND OTHERS, DAMMIT??
It is possible to do everything with Mesh::addInterleavedVertexBuffer().
Moreover Mesh::addVertexBuffer() was dependent on vertex count, which
was counterintuitive and not always what the user wants. Also in many
times I mistakenly used Mesh::addVertexBuffer() instead of
Mesh::addInterleavedVertexBuffer() and then spent endless hours trying
to figure out what is wrong. This is now over. Thanks, brain!
On systems without VAOs and without gl_VertexID the buffer needs to be
bound before every draw call. This way the buffer reference would become
dangling one, because the buffer is moved out somewhere else. Now
creating it on heap and returning pointer instead.
This multiple code path implementation is really starting to pay out,
yay!
In 1.8.5 it is now possible to reference directly to enum member.
Hooray! Also added explicit @ref here and there, fixing some referencing
bugs along the way.
Set it to some non-trivial value to achieve these two things:
* Some "corporate identity", I find very dark gray nicer than pure
black.
* Easier "black screen" debugging. Native Client, for example, by
default clears to pure white, which caused me painful hours figuring
out what the hell is going on.
I hoped the typedef was the same everywhere, but apparently ES has
something else, which is typedef'd recursively and I don't want to
maintain the consequences when porting elsewhere.
It adds much more convenience. Only some resources can't be moved around
(i.e. those with someone pointing at them), which isn't excuse for
forbidding copy/move altogether.
Finally it is possible to do convenient things like this again:
DebugTools::ResourceManager::instance()->set("red",
DebugTools::ShapeRendererOptions().setColor({1.0f, 0.0f, 0.0f}));
Every circle should consist of 40 lines, i.e. sphere should have 40
segments and 20 rings, capsule should have 40 segments and 10 rings per
hemisphere (=20 rings total).
The code is mostly copied and simplified from Capsule renderer. However,
it is such simplification that any attempt to reduce duplicate code
would result in much less maintainable thing.
Seems like an essential part of the toolbox -- we have Point, LineSegment
and Line and now we have also all "swept sphere" alternatives to them --
Sphere (swept "along" the point), Capsule (swept along line segment) and
Cylinder (swept along infinite line).
"Implemented" collision detection with point and sphere, which is just
simplified version of collision detection implemented for Capsule (i.e.
no need to check for cap cases).