sceFontGetCharGlyphImage_Clip stored the glyph over the destination buffer.
Hardware adds it with saturation instead, so on hardware a glyph never erases
what was already in the buffer - the transparent parts contribute zero - while
we cleared them to 0. Text drawn as overlapping glyphs lost the earlier ones.
Measured on a PSP-1000 against a dumped ltn0.pgf, sweeping the pen position's
fractional part, both 4bpp and 8bpp, and several destination pre-fill values so
that "wrote a 0 here" could be told apart from "did not write here":
- The result is min(dst + blend, max), not blend.
- The two horizontal weights are rounded in opposite directions, down for the
left neighbour and up for the pixel itself. That is not a free choice: it is
what makes the pair sum to exactly the format's full scale whenever both
samples are full ink, for every fraction. Rounding the combined sum once, as
before, disagrees with hardware on about a fifth of the blended pixels.
- 4bpp blends the raw nibble and 8bpp the value swizzled to 8 bit. Blending at
8 bit and narrowing afterwards is not the same thing and misses ~0.6%.
- The fractional part of yPos64 is discarded entirely. There is no vertical
blending and the rectangle never grows downwards, so renderY2 loses its +1
and the two render loops collapse into one - xFrac == 0 needs no special
case, the first term vanishes and the second collapses to exactly b.
Only PSP_FONT_PIXELFORMAT_4 and _8 render at all. _4_REV, _24 and _32 return 0
and leave the buffer completely untouched, which is also the answer to the
"not sure how to make these produce an image" note in pspautotests'
charglyphimageclip.cpp. They are skipped now, with a report so that a game
relying on them can be found - only one buffer configuration was measured.
Verified with pspautotests: the new charglyphimagexfrac goes from 388 of 601
differing lines to passing, and charglyphimage and charglyphimageclip improve
from 57 differing lines to 3. No other font test changes. The remaining 3 are
a separate, pre-existing issue with bytesPerLine of 0 and 1.
Not covered: clip rectangles that actually clip, negative pen positions, and
the shadow glyph entry points.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It was not clipping completely, and didn't handle negative clip w/h.
Also, reduce to debug log (seems to work fine now and has been working
fine in most games.)
This makes it match the value from the PSP, and seems logical (the charmap
value is hardly useful, and might lead me to overallocate space for the
glyph bitmaps...)
