sceFontGraphicsAppendGradientSegment decodes from the 4.03 libSceFont
body at 0x20500: sorted-inserts a 0x18-byte color-stop node into the +8
chain of linear (0x20) and radial (0x30) gradient records while
node->+4 == record->+4 and position >= node->+0x10. Stop records live in
a unit byte stream built from the per-object segment arena at
object->+0x10 (+0xc0 descriptor, mutex at +0x40, stats +0x48/+0x4c),
allocated by the span allocator at 0x1b5e0 (12-byte nodes: count(22b),
chain index(21b), span end(21b); index 0 is the sentinel). Units chain
through frame->+0x18/+0x20 with byte position in frame->+0x10/+0x14;
sub-0x18 tails get a 0xff pad record plus a zeroed tail. Validation
order, error codes (0x80460020/0x80460086/0x80460002/0x804600a0), NaN
acceptance, stats updates skipped on alloc failure, and the pad loop's
abandon-on-failure all follow the disassembly; guest_font_graphics
covers insert order, epoch stop, pads, unit boundaries and exhaustion.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
The 13.42 runs report error paths storing at frame +4 without the
registered callback on the image/pattern bodies, while the fills'
sealed paths still invoke it. Scope the recorded difference
accordingly.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Firmware 4.03 re-disassembly of the drawup bodies fixes three
transliteration errors:
- Option1Flags[1] is 0x3000, not 0x2000: the option1 jump table at
0x37fcc routes index 1 to case code that ors 0x2000 then falls into
or 0x1000.
- Sealed paths run the shared error epilogue (store at frame+4 and
invoke the registered callback), like every other error path; use
DrawupRecordError instead of a bare return.
- DrawupPoolAllocate returns memory + completingNodeIndex*slotSize
(0x1bcc0 marks slots start..start+count but returns the node whose
span finished the run), not the run's first slot.
The 13.42 emulator report matches on all three; its callback
suppression and +0x20 pool entries are firmware differences, not
deviations here.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Firmware 4.03 re-disassembly of the drawup bodies fixes three
transliteration errors:
- Option1Flags[1] is 0x3000, not 0x2000: the option1 jump table at
0x37fcc routes index 1 to case code that ors 0x2000 then falls into
or 0x1000.
- Sealed paths run the shared error epilogue (store at frame+4 and
invoke the registered callback), like every other error path; use
DrawupRecordError instead of a bare return.
- DrawupPoolAllocate returns memory + completingNodeIndex*slotSize
(0x1bcc0 marks slots start..start+count but returns the node whose
span finished the run), not the run's first slot.
The 13.42 emulator report matches on all three; its callback
suppression and +0x20 pool entries are firmware differences, not
deviations here.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Firmware 4.03 bodies at 0x20cb0 (image) and 0x20f50 (pattern) recovered:
frame magic/sticky/parameter checks with error store at +4 and hook,
record-pool u16 free-run allocation under the pool mutex, 0x80 record
header (type 0x40/0x50, sequence, payload at +0x80), descriptor memcpy
of mode bytes, and same-sequence queue append bumping frame+0x28.
libSceFont links libkernel for scePthreadMutexLock/Unlock; guest test
covers validation, record bytes, queue order and the allocator.
Firmware 4.03 body at 0x20f50 takes ten integer arguments with the\noutput pointer last - the PPSA20397 libSceFontGsm.prx caller rotates\nsix registers and pushes four stack arguments, no float registers.\nUpdate the declaration, stub and signature assertion, and record the\nverified offsets and record/queue semantics in the debt file.
The return codes of sceFontRebindRenderer come from our shadPS4-based port and
are unmeasured; the new test pins them, so the debt file now says so.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Horizontal writing steps advanced the pen by the glyph's vertical advance on
every character, so text drifted down diagonally (steepest for CJK fonts,
whose vertical advance is roughly the em size). The step's GlyphMetrics
width/height were also overwritten with the pen position, leaving the first
glyph of each run invisible at pen (0, 0).
Every supported writing form (0x10/0x11/0x12) is horizontal, so the pen must
advance only along X and the step reports the real glyph width/height.
sceFontWritingInit took a reference on the string's host character
storage and kept it in the caller's SceFontWriting bytes. Only a later
sceFontWritingInit on the same, unchanged bytes dropped it, so every
string drawn with a fresh, zeroed or overwritten writing leaked its
characters, and re-initialising both copies of a copied writing dropped
its one reference twice. A SceFontWriting has no teardown export, so it
is plain caller memory and cannot own anything.
sceFontCreateString now allocates the characters through the string's
FontMemory, as it already did the string, so no character pointer the
guest receives points into host memory. sceFontDestroyString clears
the string's magic and frees both, and a failed create clears it before
freeing the string. A writing keeps only a pointer to its string and
checks the magic on every step, so after the destroy its steps return
null unless that memory holds the magic again, as when a new string is
allocated there. An init that fails after resetting the writing still
leaves it stepping nothing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
BunnyFl ran firmware 13.42's libSceFont natively against this PR's
checks. With both set, the surface's style frame wins over the argument,
so it is now taken first. A frame that sets no scale, zeroed or only
initialised, is accepted and keeps the glyph's generation scale instead
of returning SCE_FONT_ERROR_INVALID_PARAMETER. A valid
sceFontGlyphRenderImageVertical call, and sceFontGlyphRenderImage on a
vertical font, throw again: the module draws the char call's pixels
there but reports a different advance and stride (40/40 against 90/90
at 40 px), and one case doesn't name the rule.
The test drops the vertical comparison and the non-renderer pointer
check, whose result in the module depends on memory past the pointer,
and checks the frame order and the unscaled frames.
Draw a glyph from sceFontGenerateCharGlyph through the sceFontRenderCharGlyphImage rasterizer at the glyph's own scale, with the renderer argument checked as sceFontBindRenderer checks it and the style frame argument, else the surface's frame, applied as surface frames are. The horizontal and vertical forms place the image like their character forms. The three functions build on RenderCodeWithStyle and ApplyStyleFrame from the previous commit and move out of Unimplemented.cpp.
The font-set record path still throws in production, but the test no
longer asserts it: tests cover implemented behaviour only. The null-output
check on a font-set handle stays. The outline profile debt entry states
the gap without naming a source.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A string created from a text source in the default horizontal form (0x10)
reported 0x10. TEKKEN: DARK RESURRECTION (PPSA31371) passes the reported form
to sceFontCreateWritingLine, which only accepts 0x11 and 0x12, so the call
failed and the layout width was 0.
On firmware 13.42 sceFontCreateString decides the direction for a default-form
source and sceFontStringGetWritingForm returns the stored form. The string
gets 0x12 when its first strong character is left to right, 0x11 when it is
right to left, and 0x12 when it has none. Left-to-right and right-to-left marks
count as strong, embeddings and overrides do not, and text between an isolate
initiator and its PDI is skipped. Explicit 0x11 and 0x12 sources keep their
form.
The test follows the table reported on the pull request. Which characters are
strong is decided by Unicode block ranges here, not by the full bidi class
tables.
sceFontGetFontGlyphsOutlineProfile reports the maxp maximum contours,
points, composite contours and composite points through the driver slot
at SysDriver+0x70, as libSceFont and libSceFontFt do in firmware 13.60.
A maxp older than 1.0 returns SCE_FONT_ERROR_NO_SUPPORT_FUNCTION, and a
failed call clears the output. Font-set records, which the console
merges over system font entries, still throw.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
sceFontGetFontStyleInformation fills the 24-byte style block through the
driver slot at SysDriver+0x48, as libSceFont and libSceFontFt do in
firmware 13.60: the FreeType family and style names, the italic and bold
flags, the OS/2 weight class when it is a multiple of 100 from 100 to 900,
the width class below 10, and 1 plus a right-to-left head direction plus
0x80 for vertical metrics. A font-set record supplies the same fields
directly. A failed call points both names at an empty string and clears
the rest.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Dean