This apparently already stores precalculated maximal glyphs extents.
Testing this side-by-side with the previous solution shows that these bbox values are mostly matching the
results of loading and measuring each glyph.
They are 100% matching in the "bad" fonts which I've been adding this calculation for. For some "good"
fonts they sometimes have 1 pixel less offset, but are not less than the extent given by (0, height).
And obviously this is faster than loading and calculating glyphs.
From upstream d96da7e7a7cbdf1d5b101921c5fb83fe0040169d
This fixes loading very big fonts, which may take literally seconds to calculate if we process each glyph.
This load mode is primarily purposed for backwards compatibility, as with new games authors may
fix / replace the font if they have issues.
Because of that, it's not a good thing to pessimize loading times for games that don't require this autofix.
From upstream b058b35ec82f19a4f2b70d952eede9589e626083
This is an attempt to fix certain fonts getting "cut off" from the top when
being drawn on a limited size texture or bitmap.
The reason for such behavior is that fonts may include glyphs which
topmost extent is higher than the reported "ascender".
In this case the engine simply does not know that glyphs may be drawn
higher, and the prepared texture is not accommodated for that.
How we fix this:
1. Following a caller's instruction (a new flag ALFONT_FLG_PRECALC_MAX_CBOX),
alfont preloads all glyphs one by one and records the maximal extents of their "control boxes".
These values are saved and returned on demand.
2. Our FontMetrics struct has a new VExtent field, that keeps these values (converted to top-down
Y axis) for the reference.
3. get_font_surface_height() now returns a surface height calculated from these extent values.
4. CalcFontGraphicalVExtent() now uses the extent values when telling how the text will be
graphically positioned, relative to the requested "text position".
From upstream ec362d744f7e7c0630d68a92219f2129fec7ab3d
FreeType 2.13.3 changed a few types of the struct members for FT_Outline struct to unsigned
This is the relevant commit from the FreeType source (github):
2a7bb4596f
Tinted blitting was completely broken on the 2bpp AVX2
path, due to the code ignoring the boundary in the
middle of the wide registers. This change fixes the vertical
striping produced by the original code, and removes some
unnecessary operations that were being performed for
every group of pixels.
All optimized blitting paths exhibit similar overreading
behavior, due to the flawed design of (almost) always
loading a full 128/256-bit line, and discarding overread
pixels afterwards. This commit patches up the code so the
overreads never happen, albeit at the cost of a few
memcpys at the end of every line of pixels.
The CPU extension optimized paths do not work properly
when scaling or flipping the image. Fixing this needs a lot
of work, so for now we pre-stretch and pre-flip as a
workaround.
The issue that produced crashes when blitting beyond the
bottom-right edge of the screen was previously fixed,
but only for cases involving a 4bpp surface. The fix has
now been extended to the 2bpp functions as well.
The previous design of the optimized paths used the same
name for the dummy class used to access BITMAP's private
members. On machines that support AVX2 this meant that
the SSE2 path would shadow the AVX2 one, and make it
inaccessible unless the configure script specifically
disabled SSE2 extensions.
The dummy class has now been split into three, one
for each of the optimization paths; those dummy classes
now contain all of the internal functions to avoid potential
name clashes; and finally, all the internal functions have
been marked as static.
This fixes a (literal) edge case that was introduced in the last
attempt at fixing the clipping issues that would crash
ScummVM when a sprite is drawn at the bottom right of
the screen. In particular, the specific Y value that would
result in only one row of the sprite being off screen no
longer produces a crash.
The AVX2 path was previously completely broken, as all
blitting produced an alternating pattern of 4 correctly
blitted colors, followed by 4 black pixels. The intrinsics used
in the pixel drawing code have been changed so this is no
longer the case.
This is a second attempt at fixing the crashes that pop up
when attempting to blit past the bottom-right corner of a
surface. The previous commit caused a bunch of surfaces
to not blit their last row, and introduced more drawing
errors in scrolling scenes. Also, made sure the size check in
AVX2 code is 8 bytes everywhere, as this was also likely to
cause issues.
This reverts commit e2720d39f3.
The changes were based on a wrong assumption on where
the issue actually lies, and introduced a new problem:
some surfaces' bottom rows were getting entirely skipped.
This reverts commit 90beb8887e.
The changes were based on a wrong assumption on
where the issue lies, and also introduced even buggier
behavior in scrolling scenes.
Fixed an off-by-one error in the non-scaling blit code, which
would result in an attempt to draw to one row beyond the
bounds of the dest surface (affects only the optimized paths).
Fixed a clipping issue that would crash ScummVM when
attempting to blit to a surface with a negative dest x
(affecting both the optimized and non-optimized paths).
