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.
Originally enabled just on OSX, apparently something similar is needed
also in Mesa. If the version is not user-specified, core GL 3.2 is
created on OSX, core 3.0 elsewhere. If that fails, the application falls
back to creating compatibility 2.1 context.
Hopefully I didn't break anything. The only difference on OSX is that
the application doesn't fall back anymore if the version is
user-specified.
Each class should now have *everything* needed in its documentation,
nothing is left out. Most of the text was taken from README in
magnum-bootstrap repository.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Currently XEglApplication and GlxApplication were requesting only ES2
context and SDL2 was not requesting anything in particular (but in
theory should work on ES-only systems flawlessly). Now explicitly
requesting ES3 if MAGNUM_TARGET_GLES3 is enabled and also explicitly
requesting ES in SDL2, so it is usable also with
MAGNUM_TARGET_DESKTOP_GLES.
Don't do anything to respond to viewport size by default, as the window
has fixed size in most cases anyway (always fullscreen, canvas of fixed
size in browser etc.). Makes the initial implementation requirements
much simpler and shorter.
* The default (empty) implementation of virtuals shouldn't be called,
thus this effectively protects the user from doing it.
* Only the application itself knows best when and how to call
rendering-related functions such as swapBuffers() and redraw(), thus
they are protected.
* Functions for setting up fullscreen or hiding the mouse may be called
from user code outside the application, thus they are kept public.
We need to create one instance, send it to subclasses and then check its
state, thus we expect that the user always operatres with the original
instance.
They are something like singletons (or they expect that behavior
internally), moreover some code might hold pointer to them, thus
movement is not desired.
Vladimír Vondruš