The editor divides its work between components and their child scenes. In the three analysed V2 builds, Create opens scenes for drawing, frames, sound and saving. The application keeps shared controls such as Back and the video console. When those controls are created or removed affects input handling and changes between scenes. [1]
Document state
The working image stores two packed pixel layers. Separate buffers hold neighbouring frames for navigation and expanded pixels for display. The sizes recorded in the research apply to the routines that were checked; other allocations may exist. The editor's working pixel-format byte and the version field in a saved PPM are separate values. [1][2]
Following an action
To trace a drawing action, follow the sampled buttons and stylus position through the active callback, tool settings, pixel operation, frame cache and display update. A menu can request a scene change before the current frame has finished processing. Check callback order when reproducing what happens while a button is held or released. [1][3]
Document state and display state
The editor stores the animation separately from the image currently on screen. Drawing changes the active frame, while onion-skin and playback can read neighbouring or cached frames. Keep each frame's data available independently of the visible canvas so edits, undo, duplication and saving can use it. [1][2]
Scene transitions
Drawing, frame navigation, sound recording and saving are handled by different parts of the application. Releasing the stylus can open a menu, with the actual change taking place only after an option is chosen. To trace an action, follow the input event, the chosen operation and the changes it makes to the document. [1][3]
What a replacement editor needs
- Two independent ink layers with frame-local colour choices and visibility.
- Paper colour, frame order, timing and optional sound-effect triggers.
- A deterministic pixel representation before compression into PPM rows.
- An explicit export/validation step; rendering a frame is not evidence that the resulting PPM is accepted by original Studio. [1][2]
V2 scene map
| Scene | Mode | Registered component | What it controls |
|---|---|---|---|
| Create | 6 | Main-menu transition | Enter a new document |
| DrawMenu | 7 | Editor menu | Drawing tool and layer controls |
| SoundEditor | 9 | Factory 8, primary slot 8 | Music and three effects |
| FrameEditor | 11 | Factory 10, primary slot 11 | Frame order and clipboard |
| MenuSave | 14 | Factory 11, primary slot 12 | Destination choice and save wait |
This scene mapping is established for Japanese, American and European V2. Frame, rendering and storage routines have been mapped separately in Japanese V1, but an equivalent complete V2 scene graph has not been established there. Resource names such as DrawTool, PageCounter, BackButton and VideoConsole are strings in the original ROM; a screenshot alone cannot identify which object handles the corresponding action. [1]
Working image and shared controls
A frame's two packed image planes total 0x3000 bytes. Navigation uses A, B and C image buffers plus a separate decode workspace. The shared B and decode buffers load at 01FF83C0 and 01FFB3C0 in every studied Studio build. The US V2 application constructs a 64-byte BackButton, 68-byte ScrollBar and 116-byte VideoConsole once, stores them in application slots, then scenes borrow those objects. A menu-local re-creation would alter object lifetime and callback behaviour. [1][2]
Checkpoint and dirty state
NewDocument invokes the serialiser in mode 8 before registering a callback, but does not immediately write a PPM file. Mode 7 packages current document state without replacing that checkpoint; a dirty predicate compares the resulting 144-byte operation output. In V2 an invalid live frame cache first counts as changed; JP V1 packages every nonempty document in this path. The compared 144 bytes are package output, not the author metadata at file offset 0x10. See the serialiser guide for mode and field effects. [1]