fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: sub_822380B0 is a type-tagged draw-queue walker, not the interpolator

Browse Source 
Walked the route the bounded-negative page named -- trace down from the
quad emitter -- and got one step.

sub_822380B0 is not a geometry emitter. It fetches a vertex pointer from
sub_823C2AC0, stashes it at this+0x20, then loops over an array of item
POINTERS at this+4 bounded by this+0x0C and this+0x10, loading a type tag
from item+8 and dispatching on it. So the object is a draw QUEUE and this
function consumes it.

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

Still not the interpolator: alpha is already decided by the time an item
reaches the queue. 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, not a finding: one function identified by
disassembly, no behaviour measured, identification resting on code shape
alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-02 16:17:12 +00:00
parent 8859189938
commit cac31deccd
1 changed files with 41 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
docs/re/interpolator-hunt-bounded-negative.md
View File

@@ -64,3 +64,44 @@ those negatives are complete rather than sampled — the instruction forms searc
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`](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.