Sylpheed/docs/re/interpolator-hunt-bounded-negative.md

❔ The keyframe interpolator is not found — but four routes are now excluded

Status: ❔ undecodable so far, with reach. 2026-09-02. Instrument: ⟨image⟩ — mechanical scans of /image/sylpheed.pe, no database rows.

Question 1 of ../agents/PLAYTEST-2026-09-02.md has two halves. The behavioural half is answered — the game interpolates piecewise-linearly, every frame, and the declared keyframes predict the measured per-frame steps (splash-interpolates-every-frame.md). This page is the other half: which function, and it is not found.

Recorded because a bounded negative stops the next attempt repeating four searches that cost nothing to state and an hour to redo.

---

What was excluded, and how

The UI region throughout is 0x82200000 … 0x823FFFFF, which is where the corpus places the screen/bundle subsystem and the quad-emitter chain (ui-quad-class-foothold.md).

route	search	result
integer lerp	a divw/divwu with both a mullw and a subf in the preceding 10 instructions — the shape of v0 + (v1−v0)·(t−t0)/(t1−t0)	28 sites image-wide, NONE in the UI region. The evaluator is not integer multiply-divide there
indexed record access	mulli rD,rA,40 — the keyframe record stride is 40 bytes ⟨disc⟩	31 sites, NONE in the UI region. Records are not addressed by multiply
pointer walk by stride	addi rX,rX,40 inside the UI region	43 sites. The ones in the screen/bundle subsystem — 0x823CCA6C, 0x823CCA94 — disassemble to a 40-byte container copy loop (mtspr CTR,10 then a 10-word copy), i.e. a vector<40-byte> reallocation. Not an evaluator
float lerp	fmadd-family ops in the UI region	811 sites over 142 pages — far too diffuse to select on. Not excluded; not narrowed either

📌 The useful part is the first two. Together they say the evaluator does not compute a fraction with integer multiply-and-divide, and does not index its records by multiplication. Combined with the measured behaviour — steps that land on exact integers like −3 and −14 — the likeliest remaining shape is a float lerp with a reciprocal computed once per segment, then converted to a byte. That is a hypothesis, and the fmadd scan shows it cannot be found by opcode shape alone.

What would find it, in cost order

1. Trace down from the quad emitter. sub_823C2AC0 — the accessor that hands out the vertex pointer — has exactly 6 callers, four of them sibling quad emitters (sub_821D6A40, sub_822380B0, sub_82234610, sub_821BC718). sub_822380B0 calls it and then reads its colour from fields of this (+0x04, +0x08, +0x0C, +0x10). Whoever writes those fields is one step from the interpolator, and the caller set is small enough to enumerate. This is the route I would take next and did not have budget for.
2. Watch it from the guest instead of reading for it. The alpha is in a vertex buffer at a known address each frame; a watchpoint on the byte that becomes k_8_8_8_8 alpha would name the writer directly. /canary is read-write and already carries four RE logger patches.

Why this is not blocking the port

It is not. The port needs to know whether to lerp and how, and that is answered and measured. Naming the function would let the answer generalise from the splashes to every screen without further captures — worth having, not worth holding the port for.

Reach

⟨image⟩, exhaustive over the whole 9.2 MB for the two excluded opcode shapes, so those negatives are complete rather than sampled — the instruction forms searched genuinely do not occur in that address range. They do not exclude the interpolator living outside 0x82200000…0x823FFFFF, which is an assumption inherited from ui-quad-class-foothold.md and not independently checked here.

Increment 2026-09-02 — route 1 walked one step, and sub_822380B0 is identified

I took the route this page named — trace down from the quad emitter — and got one step, not to the interpolator.

sub_822380B0 disassembles as a type-tagged draw-queue walker, not a geometry emitter:

822380CC  bl 0x823C2AC0          ; get the vertex pointer
822380D0  lwz r11,12(r26)        ; head
822380D4  lwz r10,16(r26)        ; count  -> r17 = head + count
822380E0  stw r3,32(r26)         ; stash the vertex pointer in the object
82238104  subf r11,r25,r17       ; loop bound
82238134  lwz r10,4(r26)         ; the ITEM ARRAY base
82238138  rlwinm r9,r11,2,0,29   ; index * 4  -> an array of POINTERS
82238140  lwzx r29,r9,r10        ; item = array[i]
82238148  lwz r11,8(r29)         ; item TYPE TAG
8223814C  cmpi cr6,r11,2         ; dispatch on it

So the object at r26 is a queue — +4 item-pointer array, +8/+0x0C/+0x10 bounds and indices, +0x20 the vertex write pointer — and the function consumes it, switching on a per-item tag at item+8.

📌 That is a partial answer to a different open question. ui-quad-class-foothold.md records "no function that iterates screen elements has been found". This iterates a list of UI items and dispatches per item. It is a draw queue, not a screen's declared element list, so it is not that walk — but it is the consumer immediately downstream of it, and the type tag at item+8 is a concrete field to chase.

🔴 It is still not the interpolator. Alpha is already decided by the time an item reaches this queue: the emitter reads what it needs from the item and writes vertices. The evaluator runs before the enqueue, so the next step is whoever pushes items — the writer of +0x0C/+0x10 on this object.

⚠️ Recorded as an increment rather than a finding: one function identified by disassembly, no behaviour measured, and the identification rests on the shape of the code alone.