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

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

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

@@ -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.