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.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
The original implementation had a few problems:
- If a file callback was set, openFile() was unconditionally calling
right into doOpenData(), making it impossible for the importer to
know the original path for correctly supplying paths to additional
files. Now, if the importer supports Feature::FileCallback,
doOpenFile() is always called. It's also possible for the importer to
save the path and then just delegate to the base doOpenFile()
implementation -- it will handle the file callbacks correctly too.
- If the importer supported neither FileCallback nor OpenData and
callbacks were set, the original doOpenFile() implementation was
called without any warning or anything, doing silently a bad thing.
Now in this case setFileCallbacks() asserts -- programmer has to
check for feature support first.
- It was not possible for the file callback to indicate file opening
failure -- in general, empty files are valid, so a nullptr ArrayView
is also a valid file. Now the callback return an Optional instead.
Vladimír Vondruš