It's now possible to call *Texture::setStorage() even if
OpenGL 4.2, ARB_texture_storage, OpenGL ES 3.0 or EXT_texture_storage in
ES 2.0 is not available, the function will internally use sequence of
setImage() calls as fallback.
It seems to me that this behavior is better than forcing the user to
always check for extension presence and then implementing this
functionality again and again. The huge switches for setting proper
image format and type are ugly though, but according to specs they must
be set even if we are sending no data (which is weird).
Special RGB values together, RGBA values together, Depth values
together, DepthStencil values together. Left sized internal formats in
the same order, though.
It is deprecated, but many ES2 implementations don't support
EXT_texture_rg, thus this is the only way to have single- and
two-component textures without wasting precious memory. The enum value
isn't exposed on desktop OpenGL and ES3. GL_ALPHA is not supported, as
it doesn't bring any new functionality (it is also single-component
and thus can be interchanged with GL_LUMINANCE).
It seems that with Clang you cannot split declaration and definition of
`constexpr` function. These should be as short as possible anyway, thus
it is non-issue.
Calling functions directly on Object will result in non-virtual calls,
calling functions on AbstractObject will result in virtual calls. Also
removed now unneeded "hacks" like `sceneObject()` and properly hiding
unsafe functions taking `AbstractObject*` with safe functions taking
`Object*`. Also hide `isScene()` from public documentation, as it is
sort-of hack too.
Until now, all calls to e.g. `Object::translate()` were virtual, which
is _very_ bad for performance. The virtual call is only needed when
setting the transformation via some interface, e.g.
`AbstractTranslationRotation3D`, as the caller doesn't know which
transformation implementation is used.
Now all public-facing transformation methods are inline non-virtual
functions, which are in most cases calling directly the transformation
implementation. In `Abstract*` transformation interfaces these functions
call private virtual `do*()` implementations, which are (re)implemented
in subclasses, but aren't used anywhere except when transforming
directly through the `Abstract*` interfaces. This should have good
impact on performance when doing many transformations in every frame
(although I can't verify it anywhere, as I don't have any significantly
large animated demo). Except of course when doing it through the virtual
interfaces.
As the public-facing transformation methods are now non-virtual, there
are now no "covariant return" issues and they can now return proper
`Object<*Transformation*>` type instead of just `*Transformation*`,
which makes full non-WTF method chaining possible:
Object2D* obj2;
obj2->translate({0.5f, -1.0f}) // Transformation method
->setParentKeepTransformation(obj1); // Object method
Or even this:
Object2D* obj = (new Object2D)->rotate(-15.0_degf);