Similar change to the windowed apps, also resetting it when core context
creation fails or when the workaround is applied. This change is not
done for CGL, iOS and Windows EGL apps, as these are either GLES-only
or, in case of macOS, such flag is not available.
It's enabled by default, but it's possible to explicitly remove the flag
to allow for using features that are not enabled otherwise (such as wide
lines). To make the flag handling easier, there's now also new
addFlags() and clearFlags() methods.
There's much more to work around / fix, but this is a start. First we
need to create the context with a pbuffer, otherwise eglMakeCurrent()
crashes deep inside. Second, it doesn't treat EGL_CONTEXT_FLAGS_KHR as a
bitfield, so it blows up when encountering a combination of zero flags.
In that case we're simply not sending the flags there. This would also
blow up when there's more than one flag passed, but there's just one
flag for debug context at the moment, so shouldn't be a problem.
The nested for loop is a big problem. Worked around this by putting a
fixed upper bound and some `break`s. This might result in the code
being slower on desktop drivers, needs to be redone from scratch later
by generating the code directly.
Even this minor change caused Mesa drivers to output a slightly
different file. Test output is verbatim below:
============================================================================
FAIL [1] test() at
../src/Magnum/TextureTools/Test/DistanceFieldGLTest.cpp on line 107
Images actualOutputImage and
Utility::Directory::join(DISTANCEFIELDGLTEST_FILES_DIR, "output.tga")
have both max and mean delta above threshold, actual 1/0.000488281 but
at most 0/0 expected. Delta image:
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| M |
| |
| |
| M |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
Pixels above max/mean threshold:
[16,41] Vector(175), expected Vector(174) (Δ = 1)
[46,35] Vector(175), expected Vector(174) (Δ = 1)
This is in line with how the other APIs are named (for example
ObjectDataXD have instance type and instance). This would be very hard
to change later without breaking backwards compatibility, so I'm doing
it now, until the animation APIs get widely used.
This reverts commit f6ba4111e1, which in
turn reverts commit 4ce2875262 from 2015.
Turns out glDrawRangeElements() *is* fixed now in Firefox, but is broken
in Emscripten because their function dependency handling doesn't work
correctly. Related PR: https://github.com/kripken/emscripten/pull/7112
Reverting this until the Emscripten PR is integrated and a version
released with this patch is widespread enough (assuming a year-long
delay could do).
Before neither of the lerp(), slerp() had the shortest path check, while
sclerp() had it. Now, to be consistent, none of them has it and there
are lerpShortestPath(), slerpShortestPath() and sclerpShortestPath()
functions that have the shortest path check.
This is different from other engines, where there's usually only the
shortest path interpolation by default and either an optional
"non-shortest-path" interpolation or no alternative at all. I like to
give the users a choice, so there's both versions and the
non-shortest-path version is the default, because -- at least in case of
lerp() -- this results in a quite significant perf difference (15%
faster), so why not have it. Preprocess your data instead ;)
The fix done with https://github.com/mosra/magnum/pull/122
(0e05c7289e) was not tested properly (see
previous commit) and thus this code path never worked. This properly
lerps the translation part and recombines it with the rotation instead
of interpolating just a part of it.
Also I'm no longer having any "dotResult" that's done only on the
vector part of the rotation, but instead using the full
rotation quaternion dot product. I have no idea why it was done this
way. This branch was also never properly tested -- it'll be with the
introduction of "shortest path" variants in the next commit.
It's a straight copy of the code for quaternions -- it could probably be
simplified a bit, but I don't have the necessary brain cells at the
moment. I tried the following but failed:
retun Complex::rotation(acos(cosAngle)*t)*normalizedA;
Calling map<void>() was trying to instantiate ArrayView<void> through
arrayCast<void>(), which is not possible (void has no size etc etc.).
Casting the returned pointer directly instead. Thanks to @AndySomogyi
for pointing this out.
Vladimír Vondruš