Dreamcast emulation in your browser: Flycast WASM hits 60 FPS

Running a Dreamcast game in a browser used to sound better than it worked. You could get something on screen, sure, but performance often dropped to a few frames per second. That’s not really playable. Flycast WASM changes that. The project brings the established Flycast Dreamcast emulator to the web and adds a custom SH4-to-WebAssembly just-in-time compiler. The result is far more convincing than the usual browser demo. Demanding Dreamcast software can now hit 60 frames per second at the console’s native 640 x 480 resolution, with WebGL2 graphics and stable audio. That’s a big jump.

The original browser build was simply too slow

The first Flycast WebAssembly build arrived in February 2026. It could boot games and run through an EmulatorJS-style front end, which proved the core idea worked. There was one major problem: speed.

The Dreamcast’s Hitachi SH4 processor had to be interpreted one instruction at a time. That approach is useful for compatibility testing, but it’s far too slow for complex 3D games. Some titles only managed a handful of frames per second.

The new version takes a different route. Instead of interpreting every SH4 instruction as it appears, it translates blocks of Dreamcast code into WebAssembly while the game is running. The browser then compiles those blocks into native machine code. Once a block is ready, Flycast can reuse it. That removes a huge amount of repeated work.

The browser does the final compilation

WebAssembly has strict security limits. It can’t rewrite executable code in memory like a traditional desktop emulator can. That makes standard dynamic recompilation difficult. Flycast WASM works around the restriction by creating fresh WebAssembly modules at runtime. The browser compiles them, then stores the resulting functions in a shared table. The emulator can call those functions directly from its main C loop without bouncing through JavaScript every time.

That detail matters. Crossing between WebAssembly and JavaScript too often can destroy performance. Flycast WASM keeps the main execution path inside compiled code as much as possible. This isn’t just the desktop version of Flycast dropped into a browser. The developers built a new backend around the way modern browser engines actually work.

The JIT compiler isn’t doing all the work

The custom compiler handles 62 of Flycast’s 70 intermediate SH4 operations directly in WebAssembly. Frequently used processor registers stay in local WebAssembly variables, which browser engines can often map to real CPU registers. Less common operations still use existing Flycast routines. That keeps the new system close to code that has already been tested.

Memory access also needed serious attention. Early versions crossed imported function boundaries hundreds of thousands of times per frame. That overhead added up fast. The newer build uses inline fast paths for common memory operations. It also tracks changes to pages in Dreamcast RAM, so the emulator can detect modified code without constantly calculating hashes.

Compilation happens in the background, too. Instead of stopping the game to compile every small block, Flycast groups hot code into larger WebAssembly modules and processes them asynchronously.

Audio gets its own treatment. An AudioWorklet uses a ring buffer to smooth out timing changes, while rate control helps prevent pitch shifts, crackling and repeated underruns. None of these changes sounds dramatic on its own. Together, they make the emulator feel much closer to a native application.

Setup still takes some work

Flycast WASM runs as a libretro core through an EmulatorJS-compatible front end. You’ll need the JavaScript loader, the WebAssembly binary and the correct configuration files. The web server must also provide cross-origin isolation headers. Without them, some browser features the emulator depends on won’t work properly.

You’ll still need your own Dreamcast BIOS files and game images. Supported formats include CHD, CDI, GDI and CUE. Once everything is configured, there’s no desktop installation. You open the page, load the game and play through the browser. It’s convenient, but it isn’t a public one-click gaming service. Right now, it makes the most sense for users and developers who are comfortable setting up their own web front end.

Compatibility isn’t complete yet

The performance gains are real, but not every game works. Windows CE-based Dreamcast titles remain a major gap. Those games depend on SH4 memory-management features that the new JIT compiler doesn’t support yet.

Some other titles boot with blank screens, visual glitches or rendering problems. The latest documented test set showed 22 out of 29 games producing graphics. That’s a solid result, though it leaves room for improvement. Planned upgrades include Windows CE support, cached bytecode through IndexedDB, wider compilation regions, better floating-point register handling and a possible WebGPU renderer.

A serious step forward for browser emulation

Flycast WASM shows that the browser can handle far more than lightweight retro emulation. Dreamcast code moves through Flycast’s existing decoder, gets translated into an intermediate format, turns into WebAssembly and ends up as native code compiled by the browser. It’s a complicated chain, but the user doesn’t need to think about any of it.

The game just runs. There are still compatibility limits, and the setup won’t suit everyone. Even so, Flycast WASM has moved Dreamcast emulation in the browser from a slow experiment to something genuinely practical.

Spread the love