← Catalog·Game·2026

Pokemon Ultra Moon

A web-based 3DS emulator targeting Pokemon Ultra Moon (and other retail 3DS ROMs the user supplies themself). The emulator runs entirely in the browser — the ROM never leaves the device. The project lives on its own subdomain (`pokemon.bridgeworks.dev`) as a separate Cloudflare Worker. The catalog card on this site embeds the subdomain via iframe. The subdomain owns the emulator canvas, the input layer (keyboard + mouse + gamepad), the WebAudio sink, and the save-slot persistence layer (Cloudflare D1). **Why not bundled into this catalogue?** 3DS emulation is heavy: the Wasm core plus the JS shim is the largest single dependency we ship. Keeping it on a separate worker gives the catalog site a clean fast cold start, isolates the worker bundle budget, and lets this project's deploy cadence drift from the rest of the catalogue. **Important**: This site does not distribute ROMs. The user is expected to supply a `.3ds` file from their own copy of the game. Save-state bytes (~32KB per slot) are stored in D1 keyed by an opaque visitor cookie so progress survives reloads. ROM bytes are never accepted by any API route, never cached at edge, and never written to disk.

Framework

Next.js 16 (App Router) + React 19 — own Worker (`pokemon-bridgeworks`)

Emulator core

Wasm 3DS core (chosen post-evaluation; see AGENTS.md notes)

Rendering

Composed 3DS framebuffer (400×240 + 320×240) to a single canvas; pixel-perfect CSS scaling

Audio

WebAudio AudioContext; 32kHz stereo int16 PCM rate-converted at the sink; sample-block queue with overflow backpressure

Input

Keyboard mapping (15-button 3DS), mouse touchscreen layer (lower 320×240 frame), gamepad polling rAF-driven

Persistence

Cloudflare D1: `pkmn_users` + `pkmn_save_slots` + `pkmn_save_blobs`. ~5MB blob cap, 16 slots per user, HttpOnly cookie user_id.

Deploy target

Cloudflare Worker via OpenNext (nodejs_compat)

Subdomain wiring

DNS CNAME on `pokemon.bridgeworks.dev` → Worker Route on the zone → script `pokemon-bridgeworks`