In addition to 37e4f9d6f7 which did the
change for Sdl2Application (because Emscripten required it), making sure
that everything (except GLUT, which does it by default) behaves the
same.
Moreover, some applications don't expect viewport size changes at all
(e.g. the app can't change size of immutable texture used for rendering)
and thus the original way to defer the initialization until
viewportEvent() is called would be overly complicated.
Also, since framebuffer classes store viewport size in them, there is no
need to call viewportEvent() on initialization. The current ways to do
the initial call in Sdl2Application, *XApplication and NaClApplication
were nothing more than ugly workarounds for mimicking GLUT behavior,
which is bad.
Lastly, to be sure that nothing breaks in user apps, I did this change
in magnum-bootstrap long ago and all bootstrap application behave the
right way.
Consider this craziness when setting up projection or something similar:
Vector2i framebufferSize;
Float aspectRatio = Float(framebufferSize.x())/framebufferSize.y();
And now, behold, the convenience:
Float aspectRatio = Vector2(framebufferSize).aspectRatio();
The event is called only if any button is pressed, added Button::Left
which is always present. This is just for source compatibility with
other Application implementations.
Doing it the same way as in Sdl2Application, as this doesn't have any
performance impact (just alias for already present variable).
The other way around, i.e. combining mouse buttons and keyboard
modifiers in Sdl2Application, would have unnecessary performance
penalty, as keyboard modifiers must be queried with separate function,
even if they won't probably be used at all.
Qt employs similar approach.
The old way is preserved for backwards compatibility, but marked as
deprecated and will be removed in future releases.
Emscripten supports some hybrid between SDL1 and SDL2. I don't want to
add Sdl1Application just for that and create more portability issues, so
I just changed some things in Sdl2Application to be compatible with what
Emscripten wants. Full SDL2 support is awaited in Emscripten, thus this
is future-proof (rather than having SDL1 support, which would be
deprecated later).
Added documentation about Emscripten usage and template HTML markup to
Sdl2Application docs, will move it somewhere else in the future when
more than one Application will be supported (e.g. GLUT).
Aside from the fact that we shouldn't have done it at all, it caused at
least two roblems:
1. std::hash is by standard defined as struct, but GCC's libstdc++
defined it as class, causing Clang warning (probably harmless, but
annoying).
2. Clang's libcxx implements STL in inline namespace std::__1, which
causes the forward declaration to define a completely new struct,
different to std::__1::hash. The actual template specialization
std::hash<ResourceKey> would then be totally unrelated to
std::__1::hash, causing compiler error. Removing the forward
declaration solves this, as it's possible to do the specialization
without knowing about the inline namespace.
Should speed things up a bit in debug builds, as the asserts are now not
fired in functions which would not trigger them anyway, such as
normalizeRotation(), resetTransformation() etc.
Previously it was possible to access internal transformation
implementation from Transformation and thus also from Object, e.g.:
typedef SceneGraph::Object<SceneGraph::MatrixTransformation2D> Object2D;
Object2D o;
o.fromMatrix(...); // What does this here and why it returns matrix?!
Now everything is hidden in Implementation namespace and all
traces of previous code are removed from documentation. It might now be
slightly harder for users to implement their own transformation
implementations, but it wasn't easy before either. The widely used ones
are already implemented, so it shouldn't be too much of a problem.
Similarly for potential backward compatibility issues, I assume nobody
needed to implement their own transformation yet.
Caused in 6ee2745503, I accidentaly
removed code that initialized the array to proper length. Again I
experienced how useful unit tests for GL functionality would be.
Renamed AbstractTexture::maxSupportedLayerCount() to maxLayers(),
which is in fact alias to Shader::maxCombinedTextureImageUnits(). Also
renamed Samples::maxSupportedAnisotropy() to maxAnisotropy(). It now
has slightly confusing naming, will fix that later. Both
original functions are now alias to new ones to retain source
compatibility, will be removed in future releases.
Also printing the values in magnum-info.
Renamed AbstractShaderProgram::maxSupportedVertexAttributeCount() to
maxVertexAttributes(), the old function is now an alias to retain
source compatibility, will be removed in future release.
Also printing the values in magnum-info.
The geometry shader implementation somehow expects GLSL 1.50 and is not
working on GLSL 1.40 (probably inconsistent variable naming in
extension and core specification). Added checks for that. Might fix this
properly someday when there is need for geometry shader in GL 3.1.
Even if the extension specification describes the minimum required
version as GL 2.1 (or doesn't mention it at all), most compilers can't
handle `layout(...)` before input/output declaration. These drivers mark
the extensions as supported on GL < 3.1, but then can't handle them at
all: Mesa fails to compile it with GLSL 1.20, NVidia fails with GLSL
1.30.
Also updated `EXPLICIT_*` defines in Shaders/compatibility.glsl to
reflect this change.
Vladimír Vondruš