They are something like singletons (or they expect that behavior
internally), moreover some code might hold pointer to them, thus
movement is not desired.
Somebody would just want to defer context creation after parsing
arguments or doing some validations without any particular setup, thus
having to write even the {} is annoying.
Added missing tryCreateContext() implementations. Error messages are
printed only by tryCreateContext(), createContext() is only a thin
wrapper which exits the application if tryCreateContext() fails and
doesn't print any additional information on the output.
Hopefully I didn't break anything :-)
Sdl2Application is now taken as base implementation (it was GLUT
previously) and all others are copying/referencing the documentation
from it. When SDL2 is included in all major distributions (Ubuntu, I'm
looking at you), it will replace GLUT as the default application.
The conversion is done implicitly, thus this seemingly innocent code
would be allowed:
ImageReference2D reference = Image2D(...);
foo(reference.data()); // crash on access, data already deleted
ImageReference is supposed to be wrapper around existing data array of
some type which is passed to Magnum functions. Thus modifying the
original data array (which must be kept somewhere for proper deletion)
is much better option than casting the pointer returned by data() to
some proper type and then operating on that. Hopefully this won't break
any existing code.
The pointer conversion can be done only explicitly, thus the users will
always know what they are doing. With that change, perfectly valid
things like this couldn't be done (the result of a + b is kept until the
semicolon):
Vector3 a, b;
void foo(float* data);
foo((a + b).data());
Moreover this conversion wasn't even properly tested, leading to issues
as in mosra/corrade@781f5df38a7b1b366f3de477dd5fe641eca6ed20.
This reverts commit add989703e.
We should have used == instead of =, the counter is set to that value
later anyway, so this didn't break anything... but the assert was
useless. Hopefully it won't fire each time now :-)
The original purpose was to allow modifying of drawing order, but this
doesn't affect that at all (the order is preserved in DrawableGroup),
thus the functions are useless.
Related to issue #27 -- layout() qualifier causes compiler errors on
GLSL 1.40 (GL 3.1) on Mac OS X even that the extensions are marked as
supported. Bumping the minimal required version disables the extensions
on this versions, which should avoid the issue.
It is not proper fix at all, but most of the GL3 implementations are
now at least GL 3.2, so it shouldn't be too much of an issue. The only
exception is Mesa (GL 2.1/3.1 on most of the machines), but we need
to maintain GL 2.1 compatibility for it anyway.