html-in-canvas + emulation
A modern HTML form rendered inside an in-browser C64 emulator.
Viciious-core, a full Commodore 64 emulator written in JavaScript, running in a canvas, with a real HTML contact form rendered into the C64's video output. Submit the form and it behaves like any other form on the web. Looks like 1985 though.
After DOOM and the cloth experiment, the next axis to test was host: what if the rendering surface is not a Three.js scene but an emulated 8-bit machine? Can you still route HTML input through to a modern form, with the same pipeline, if the canvas is being driven by an emulated VIC-II chip?
Viciious-core handles the C64 emulation; the form is rendered to a texture overlaid on the emulator's video output. Pointer events get routed back through the inverse transform as usual. The form's CSS uses C64 colours and a chunky pixel font so it sits inside the host visually as well as technically.
Same html-in-canvas core, but the host is an emulated 8-bit machine. Speaks to the flexibility of the pattern: if your renderer can produce pixels, an HTML UI can live inside it. Game engines, emulators, GIS clients, scientific visualisers, retail kiosk shells. All fair game.
If your product needs UI inside an unusual renderer, the same pipeline applies.
All experimentsIf your product needs UI inside an unusual renderer, the same pipeline applies.
Misbehaving stack? Codebase that won't play fair?