Megadev gameplay

Start with the game's intended movement and rules, its existing clock/input/renderer owners, and the actual toolchain headers. Megadev has no SGDK sprite engine or general physics API. The Lab's gp_* calls are application code, not SDK functions.

Choose the clock before tuning movement

Use timing and input for fixed-step accumulation, PAL/NTSC, edge consumption, pause and overload policies. Tune speeds in units per second; do not make one display frame equal one gameplay tick on both video standards. Reuse an existing simulation clock instead of adding another.

Keep a bounded amount of work per foreground iteration. Decide explicitly what happens after a long stall. Service deadlines and loading/audio handshakes must continue while gameplay is paused. A fixed-step model does not prove the full game meets its frame budget.

Separate simulation from its picture

Use movement and lifetimes for coordinate ranges, collision boxes, axis sliding, camera bounds, pools and area state. Let collision and pickups depend on world state, not sprite visibility or successful rendering. Keep collision bounds independent of artwork dimensions.

Choose collision techniques for the actual maximum movement: small bounded substeps work for slow actors, while fast shots need swept tests. Avoid presenting the Lab's simple tile test as a general collision engine. Use megadev-collision for exact swept boxes, finite rays and bounded static-wall sliding.

Keep background work optional to each step

Use Megadev integration for verified BIOS fields, frame publication, Main/Sub ownership and memory budgets. Authoritative movement stays on Main in the Lab; its optional Sub job exercises a separate service lifetime. Never read live Word RAM from the renderer while Sub owns it, or block each movement tick on a job reply.