Replaces the previous, grossly inefficient AbstractLayouter which was
performing one virtual call per glyph (!). It's now also reusable,
meaning it doesn't need to be allocated anew for every new shaped text,
and it no longer requires each and every font plugin to implement the
same redundant glyph data fetching from the glyph cache, scaling etc. --
all that is meant to be done by the users of AbstractShaper, i.e.
Renderer. The independency on a glyph cache theorerically also means it
can be used for a completely different, non-texture-based way to render
text (such as direct path drawing directly on the GPU), although I won't
be exploring that path now.
It also exposes an interface for specifying script, language,
direction and typographic features. Such interface will be currently
only implemented in HarfBuzz, but that's the intent -- to provide a
flexible enough interface to support all possible use cases that a font
or a font plugin may support, instead of exposing a least common
denominator and then having no easy way to shape a text in a non-Latin
script or use a fancy OpenType feature the chosen font has.
The old public interface is preserved for backwards compatibility,
marked as deprecated, however the virtual APIs are not, as supporting
that would be too nasty. I don't think any user code ever implemented a
font plugin so this should be okay.
To ensure smooth transition with no regressions, the Renderer class and
MagnumFont tests still use the old API in this commit, and their test
pass the same way as they did before (except for two removed MagnumFont
test cases which tested errors that are now an assertion in the
deprecated layout() API and thus cannot be tested from the plugin
anymore). Porting them away from the deprecated API will be done in
separate commits.
Will be used for the upcoming new AbstractShaper API. It's based on the
ISO script codes, matching the HarfBuzz script enum, with the intention
of being passed to it as-is.
Allows the Font and FontConverter plugins be built without TARGET_GL
enabled. That was the last piece missing for making the magnum-plugins
repo completely GL-free.
Forward declarations of templated types don't have named template
parameters and thus Doxygen (sometimes) used these for documentation. It
then looked like this:
Magnum::Math::RectangularMatrix<std::size_t, std::size_t, class>
which isn't helpful at all. After the change it looks like this (much
better):
Magnum::Math::RectangularMatrix<cols, rows, T>
As we are now using absolute includes, there is no need to prefix
everything with "magnum<Namespace>" etc. All generated configuration
files are renamed to configure.h and their path is included _before_
everything else to avoid accidental collisions.
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.
No redundant naming. Text::Renderer2D and Text::Renderer3D is typedef'd
to old name, the typedefs are deprecated and will be removed in some
future release.
Provides a way to convert font into different format (either with or
without contents of associated glyph cache) or import/export glyph cache
(i.e. to avoid recreating it from scratch every time).
In next few commits AbstractFont will become plugin interface. Font
implementations are now in magnum-plugins repository. Removed all traces
of FreeType and HarfBuzz dependencies.
Font and text layouting is now abstracted out from its implementation.
Font class is renamed to FreeTypeFont and all the work can be done
through AbstractFont and AbstractLayouter interface.
The library uses FreeType for glyph pre-rendering and basic glyph
geometry and HarfBuzz for text layouting (i.e. ligatures, kerning, ...).
Currently all used glyphs must be prerendered into texture atlas, other
glyphs are simply not rendered (although the layouting code handles them
like if they are there).
Text rendering supports UTF-8, although glyph pre-rendering is currently
ASCII only, as I couldn't find any working implementation of Unicode
STL function in recent GCC versions. Will be fixed later.
* The light didn't catch camera transformation changes, so it was
returning wrong position for most of the time.
* The multiplication was in wrong order, it should be multiplied with
camera matrix from the left.
I need to find an solution for this, because now it is one redundant
matrix*vector multiplication per object per frame again.
This reverts commit 0443bbe286.
Conflicts:
src/Light.cpp
src/Test/LightTest.cpp
Object::setClean() now computes absolute transformation while traversing
through object parents and passes it as parameter to clean(), which is
now virtual a meant to be reimplemented instead of setClean().
Updated and greatly improved unit test.
Saves one matrix*vector multiplication per object per frame. The
position can be now Vector3 like before, because it won't be multiplied
with anything on draw call. Added unit test.
Removed functions at(), set() and add(), everything (and more) can be
now done using operator[]. Accessing matrix elements is now done through
column vectors, e.g.:
Matrix4 a;
a.at(row, col); // before
a[col][row]; // now
Note that because operator[] on Matrix returns column vector (there is
nothing like row vector), the parameter "order" is now swapped.
It was overengineered and unnecessarily complicated. Now the camera is
specified only in Scene::draw(), which eliminates all the needs for
recalculating absolute object transformations on each camera
transformation change. Absolute object transformation is now computed
relative to root object or relative to camera object passed as
parameter. Because of that it is now also possible to draw the scene
using multiple cameras at once.
Vladimír Vondruš