mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-08-31 09:45:24 +02:00
James0124andClaude Opus 5
8afa18c21c
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>