The SDL2 variant works better than expected, however the GLFW variant
underdelivers -- no key names for modifier keys, the accent keys are not
UTF-8... I don't care ATM, will solve it once someone actually
complains.
The original implementation tried to mimic the behavior of GLUT, which
treats mouse wheel as a button. SDL2, GLFW and NaCl all treat scroll
event separately, so it was quite nastily hacked in, with horizontal
scrolling ignored and scrolling offset treated as cursor position.
Moreover, wheel up/down buttons were confused with extra mouse buttons
in SDL2.
Now there is a dedicated MouseScrollEvent, which has just the offset and
modifiers, no cursor position. The original way with WheelUp/WheelDown
buttons in mouse press event is still preserved, though it is marked as
deprecated and will be removed in future release. Sdl2Application had
WheelUp/WheelDown buttons also for mouse move event, which was
completely useless (try moving a mouse while the wheel is rotating, ha),
so it's removed.
Scroll event offset is now also consistently Vector2 across all toolkits
-- it was integer in SDL2, float in NaCl and double in GLFW.
The X1 and X2 buttons in Sdl2Application are not confused with wheel
up/down anymore and are a new Mouse*Event::Button::X1 and
Mouse*Event::Button::X2 enums -- on my mouse they are actually wheel
left and wheel right (though wheel left and wheel right is not treated
as horizontal scrolling, weird).
The docs weren't correct in 90% cases -- mainly in case of
createContext() function, docs of which were extended to clearly specify
what's done inside.
* It might change during the text editing process and thus we need to
reposition it.
* And it's also not possible to connect a parameter-less signal to it
on Clang, which is unfortunate.
As with Corrade, this is not exactly backwards compatible, but for
common use case without OBJECT libraries this should not be a problem.
In any case, recreate the build dir and update your copy of all
Find*.cmake modules to avoid weird things happening.
User-facing changes:
* Documentation of all Find*.cmake modules converted to
reStructuredText to follow official CMake guidelines.
* The newfangled way to use the libraries is to link to Magnum::Shaders
instead of adding ${MAGNUM_SHADERS_INCLUDE_DIRS} to include path and
linking to ${MAGNUM_SHADERS_LIBRARIES}.
* The old ${MAGNUM_*_LIBRARIES} are deprecated and now just expand to
Magnum::* target. Use the target directly. These are also enabled
only when building with MAGNUM_BUILD_DEPRECATED.
* The old ${MAGNUM_*_INCLUDE_DIRS} are removed as the Magnum::* targets
cover these too.
Internal changes:
* Global state such as include_directories() was replaced with
target-specific settings.
The camera now accepts generic projection matrix instead of providing
functions for setting orthographic/perspective projection. This allowed
to completely get rid of the AbstractCamera->Camera*D inheritance
hierarchy and everything is now done through one templated Camera class.
The Camera2D::setProjection(), Camera3D::setOrthographic() and
Camera3D::setPerspective() are deprecated, use
Camera*D::setProjectionMatrix() in combination with
Matrix3::projection(), Matrix4::orthographicProjection() and
Matrix4::perspectiveProjection() instead.
The Camera3D::near() and Camera3D::far() getters are removed. The user
is advised to cache the values on application side if they are really
needed. More general queries for all six clipping planes (*not*
distance) might be implemented later.
The AbstractCamera, AbstractBasicCamera2D, AbstractBaseicCamera3D,
AbstractCamera2D and AbstractCamera3D types are deprecated as there is
no such type anymore, use Camera, BasicCamera2D, BasicCamera3D, Camera2D
and Camera3D instead.
The AbstractCamera.h, AbstractCamera.hpp, Camera2D.h, Camera2D.hpp,
Camera3D.h and Camera3D.hpp headers are deprecated, use Camera.h and
Camera.hpp instead.
As always, all deprecated features will be removed in some future
release.
If implemented by the user, it is called periodically after processing
input events and before draw event and does not depend on whether there
are any input events or the application needs to redraw.
Sorry that it took ages. Oh, actually, I'm not able to test this AT ALL
because my awesomely amazing NVidia Optimus laptop CANNOT (what?!) do
VSync because of some bad design decisions from previous century that
led to the disaster that we now know as X11 and as I heard it is
impossible to work around that or something. Ugh.