Studio arranges its UI objects in a hierarchy. It samples buttons and stylus input, detects presses and releases, then calls the active scene's handlers. To reproduce an on-screen button, check its resource data, selection state, callbacks and when it is created or removed. [1]
Resource-backed screens
The local research identifies embedded UI archives, sprite resources, layout records, fonts, messages and sound data. Its Calendar case study traces construction, month placement and date activation through the same framework. Resource names can identify a lookup, but must be paired with code and live effects to establish behaviour. [1][2]
Language and regional differences affect the resource set. A renderer or emulator should keep text encoding and geometry explicit rather than assuming English strings or one build's offsets apply everywhere. [2][3]
Press, hold and release
The UI distinguishes a held key or pen from a new press or release. A button may react on release, while drawing samples a held stylus path. Replaying only touch coordinates without the edge sequence can activate a control at the wrong time or draw through it. [1]
UI tree and resources
Original objects hold child relationships, drawing state, lifetime and callbacks. Resource-backed sprites draw from embedded archives, while layout records provide geometry and hitboxes. A visible rectangle does not necessarily correspond one-to-one with a hitbox; trace the resource index and the object that runs the callback to understand a particular interaction. [1][2]
Calendar case study
The research follows Calendar construction, month population and date activation. It shows why a screen needs both hierarchy and state: reused date cells are positioned and labelled for the chosen month, then actions depend on the selected date. A static screenshot cannot establish the month transition or input target. [1]
Localisation path
Text can come from message tables while glyphs come from a separate font resource. Japanese V1's message files sit in NitroFS; later releases place message pairs within the embedded UI archive. The V2 regions also carry different font counts. A parser that decodes text but substitutes an arbitrary font can change width and button layout. [2][3]
Viewer is a separate program
The Japanese Viewer has its own setup and Wi-Fi UI. It can help identify shared graphics conventions, but its input geometry and service flow must not be projected onto every Studio build. [1][3]
How a visible node is traversed
The observed layout renderer skips a node whose enable byte at +21 is zero. Otherwise it visits a child array from word +8 using the signed count at +16, then calls the node's draw slot. Because it reloads the array and count around child calls, a callback may change the tree while the traversal is in progress. A child draw path also checks byte +48 and a resource word at +36. The UI is therefore a live object graph, not merely static coordinates from a graphic archive. [1]
Edge state inside one input object
The mapped input slice has an enable byte at +21, gate polarity at +22, arming at +28, captured and forced element pointers at +32/+36, prior/current input bytes at +40/+41, containment at +42 and four event outputs at +43..+46. Press, release, enter and leave are interpretations supported by transitions and notifications; they are not recovered original enum names. US V2 Reset, Update, Poll, Dispatch and Step entries are 020359BC, 020359F0, 02035A2C, 02035A78 and 02035AC0. [1]
Poll checks a gate and register 04000304 bit 15. Step tests the full 32-bit containment result before storing its low byte. Thus a provider returning 256 takes a nonzero branch but leaves a zero byte in state. Notifications can replace the captured widget, so the original code reloads it after calls. JP V1 Step is 624 instruction bytes; each V2 body is 628 because it passes a fourth argument to Find. This is a concrete historical difference in an otherwise similar interaction. [1]
One verified control path
In V2, releasing over Button21Box chooses selector zero and releasing over Button22Box chooses one. The later export stub adds three to that selector, selecting two batch modes. This connects a named resource, an input edge, a setter and a downstream operation, but it does not establish every hitbox or export workflow. [1]