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 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.
What's new:
* The style is consistent with the dark m.css theme that's used on the
website and so provides a bit better "brand identity".
* The canvas is responsive, looking properly on mobile and scaling down
with aspect ratio preservation if the screen is too narrow.
* It's now possible to override canvas size and aspect ratio or make it
"fullscreen", i.e. occupying the whole browser window.
* If the app crashes, a helpful message is printed instead of
everything just being stuck.
With HiDPI support it's no longer just about window size changing -- if
the framebuffer size is different than window size, on resize both are
changed to new (different) values. Other than that, for example, when
moving a window from one display to another with a different DPI,
all three of window size, framebuffer size and DPI scaling can change as
well. This should be all reflected in the event.
This change is done in all Application classes, but the full
implementation is only in the SDL2 implementation at the moment, as the
others don't have full HiDPI support implemented yet. The old
viewportEvent(const Vector2i&) is deprecated and for backwards
compatibility called with either framebufferSize() or windowSize()
(depending on level of HiDPI support) from the new event. Overriding the
old one will still work as expected (in case you build with
MAGNUM_BUILD_DEPRECATED enabled and use the `override` keyword -- which
you should); overriding the new one will cause the compat implementation
to not be called anymore.
In order to make it possible to preserve backwards compatibility, the
viewportEvent() is no longer pure virtual in Screen. That's also
consistent with all Application implementations.
Vladimír Vondruš