This is a replacement for the existing AbstractRenderer and Renderer2D /
Renderer3D classes, with no STL or other shittiness like excessive
allocations, and with a much better feature set. Deprecation of the old
APIs is going to happen next.
Compared to the old implementation it doesn't make use of the
complicated buffer mapping because -- unlike in 2012 -- such behavior
was since deemed questionable as the driver (or whichever translation
layer like ANGLE or Zink or Apple's GL-over-Metal) may still make a copy
anyway and doing so prevents buffer orphaning. So it's right now just
plain setData() / setSubData() calls. *If* it becomes some sort of a
bottleneck (which I doubt), I may reconsider, or add something else like
double buffering.
Builds upon RendererCore and generates index and vertex data from the
glyph positions and IDs. Documentation again coming later once
everything is in, next is a RendererGL which populates a GL::Mesh with
these.
A higher-level stateful wrapper around the low-level utilities, capable
of rendering text formed from multiple lines and multiple fonts. Will be
used as a backend for a new Renderer / RendererGL implementation.
No usage docs yet, those will come once the other two classes are made
as well.
One was a Doxygen workaround that shouldn't be needed anymore and an
API reference missing from e1c9c4d007, the
other was an inconsistency in a test that was just weird but shouldn't
affect anything.
I'm going to make a new Renderer class that's unlike the old one, and
isn't templated anymore either, so gotta make room for it first. I assume
that all existing code used the Renderer2D / Renderer3D typedefs so this
should be pretty much painless.
Ultimately this class will be gone, with only (then deprecated)
AbstractRenderer left, and Renderer2D / Renderer3D being aliases to it
-- internally it doesn't actually do anything dfferent, even the
positions are two-component in both cases.
Based on the actual text direction (either explicitly set or detected),
these resolve to either *Left or *Right. For the Text::Renderer it's
done automatically inside (and there's no way to actually set the
direction from outside due to the API being ancient and limited), for
the align*() utils the alignment has to be explicitly resolved using a
new alignmentForDirection() utility.
Which also allows the internals to be a bit simpler / potentially more
efficient, as the implementation can now access the glyph cache contents
directly, without a getter.
The awful original STL-heavy public API is kept the same for now, it's
just the internals being now implemented using brand new APIs that are
actually usable with multiple fonts, font sizes and runs with different
scripts/languages/directions. There's also preparation for configurable
vertical text layouting, although for now the functionality asserts that
horizontal text is used.
This also makes Renderer.h header available on non-GL builds, as the new
APIs don't rely on a class full of GL objects anymore. The class will
get eventually renamed and moved to a dedicated RendererGL.h header, but
for now this partial update has to suffice.
It doesn't need to access anything else than what the base API provides,
doesn't render with it, and doesn't expose the instance via any getter
either.
Even though the Renderer is scheduled for a total rework and changing
the old API may feel like throwaway work, this change alone doesn't
break anything and allows me to test certain new corner cases.
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.
Followup to previous commit -- links to opengl.org are now redirected to
khronos.org and the extension links have the same format for both GL and
GLES. That allows me to remove some of the Doxygen aliases and use just
a single set of the functions for both GL and GLES.
Why did I do this:
* It is more clean, shorter and nice looking with method chaining,
i.e. instead of:
shader.setColor(...)
.setOtherParam(5);
texture1.bind(MyShader::Texture1Layer);
texture2.bind(MyShader::Texture2Layer);
We now have this:
shader.setColor(...)
.setOtherParam(5)
.setTexture1(texture1)
.setTexture2(texture2);
* It is now also clear which texture type is expected, the layer
constant did not say anything about type.
* Also it is possible to use new features (multi bind, bindless
textures etc.) while preserving the same public API.
The only potential disadvantage is that the textures don't stay bound
like uniform values do, but this become a non-issue with bindless
textures. As usual, the old way is now deprecated and will be removed in
some future release.
Vladimír Vondruš