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>
ReadCharGlyph read glyph metadata at an attacker-controlled bit offset
with no validation, and ReadShadowGlyph only checked after delegating to
it. Validate charPtr (with margin for the header reads) at the top of
ReadCharGlyph so it is safe regardless of caller, and drop the now
redundant checks at the ReadPtr call sites.
PGF::ReadPtr walked four length-prefixed tables and computed table sizes
before any bounds check, and used signed 32-bit size math that could
overflow, allowing a crafted font to read past the input buffer.
- Validate the total size of all tables up front using 64-bit math.
- Check the rev3 extra header fits before reading it.
- Cap charPointerLength/charMapLength/shadowMapLength to avoid absurd
allocations.
- Bounds-check glyph data offsets before reading each glyph.
Also throw in a warning fix
Some games render HLE sceFont glyphs into small VRAM-backed framebuffers and immediately sample them as textures. This needs both the source glyph buffer and the temporary render target to be preserved before later commands overwrite or rebind them.
Save first-frame data from the previous render target before creating a new framebuffer, since ResizeFramebufFBO() makes the new framebuffer current. Also flush pending draws before PGF writes over a glyph buffer that may still be referenced by queued texture draws.
Backend software transform normally reports safe framebuffer size during draw flush, but first-frame readback can happen before queued draws reach that path. Estimate through-mode rectangle/triangle bounds before SubmitPrim() and feed those bounds to SetSafeSize(), using actual vertices clamped to scissor instead of a tiny-target heuristic.
Fixes missing text in Evangelion JO.
Turns out these were needed after all. For some reason, on Windows and
Mac, <algorithm> gets auto-included by something else so I don't notice
when it's missing, and MSVC's include dependency tracker doesn't see it
either.
* Rename LogType to Log
* Explicitly use the Log:: enum when logging. Allows for autocomplete when editing.
* Mac/ARM64 buildfix
* Do the same with the hle result log macros
* Rename the log names to mixed case while at it.
* iOS buildfix
* Qt buildfix attempt, ARM32 buildfix
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...)
Henrik Rydgård