The selected tool and its settings determine how stylus input changes pixels. The research follows individual pixels and strokes, fills, patterns, selections, cursor updates and palette changes in the studied builds. To identify a tool's behaviour, follow its menu callback to the function that handles it. An icon or resource name alone is not enough. [1]
Two layers and a paper colour
PPM frames carry two one-bit image layers over a paper colour. The frame header selects the visible colour of each layer. Drawing changes layer bits; display composition applies the current palette and visibility. A hidden layer can still exist in the file even though it should not appear in the rendered image. [2][3]
For an implementation, keep the editable pixel planes separate from the composited preview. Test fills and selections at image boundaries, and verify saved frames with a parser as well as a screenshot. The local research records which paths have been checked against original instructions and which remain incomplete. [1]
Tool input is stateful
A stroke depends on the sampled positions, selected layer, brush or eraser mode, ink colour and frame data. One touch event cannot describe the whole stroke. Studio checks which control received a press or release before drawing into the bitmap, so control hitboxes and canvas coordinates need separate handling. [1][2]
Fill and selection
Flood fill operates on connected pixels of the selected bitmap layer. A selection carries geometry as well as pixel data, and moving it requires deciding how the source area is cleared and how the destination is clipped. Handle these operations separately from brush strokes to preserve undo and layer visibility. The original functions explain some of the input handling and pixel changes, but the complete behaviour of every tool is still being researched. [1]
Pixel conventions
The canvas is 256 × 192 pixels, but UI coordinates include screen origin, buttons and touch sampling. An image decoder's row order is not automatically a stylus coordinate order. Test a corner pixel, a tile boundary, an overlapping stroke and a frame with both ink layers before declaring a tool compatible. [1][2][3]
Menu state is regional data
The V2 DrawMenu configuration functions are JP 02063C28, US 020643F4 and EU 02064820. Each refreshes eighteen input groups and reads a live Settings object. The same logical fields sit at different offsets; for example Active layer is +0x18 in JP/EU but +0x04 in US, while layer 1 colour is +0x10 in JP/EU and +0x24 in US. A port that relocates only the base address will select the wrong mode or colour. [1]
JP and EU V2 also ask whether a Page32 special-tool selection is empty, scanning the whole 192-row by 256-column space; US does not make that extra call. All three original resource sets retain photo controls even when a later adaptation might hide them. [1]
Stroke and pixel functions
US V2 line initialisation is at 0200A078, line step at 0200A0E4, set pixel at 0200C090, clear pixel at 0200C12C, thin stroke at 0200C200 and thick stroke at 0200C298. These are original ARM9 entries, not an assertion that every toolbar icon routes to them in every state. The halfword bit setter writes its requested bit before considering a paired-bit gate. Its later equality checks use the full index while the shift uses only the low eight bits, so an out-of-range value can select a bit without taking the expected paired clear branch. [1][2]
Fill and selection are not one operation
The V2 fill family uses a span work stack and a separate eligibility map. US V2 fill starts at 02028A30; its span worker is 0202876C and push/pop are 02028894/020288EC. Selection reset, save and restore have separate entries at 02010828, 02010880 and 020108F4. The examined selection fill excludes its rightmost row bound, and that routine does not accept one-pixel row or column bounds as valid selections. These are traceable quirks, so a clean-room implementation should either reproduce them intentionally or clearly document a behavioural difference. [1]
Where comparisons stop
The research compares rewritten stroke and V2 raster routines with the original code on a specified set of inputs. It does not claim every advanced transform, touch-timing edge or user-visible tool sequence has been mapped. Test tool selection, pixel operations and saved output separately; a correct low-level fill routine can still be called with the wrong layer or bounds by a new UI. [1]