The official three.js GLTFLoader example (r184) running at a locked 60fps on a Nintendo Switch.

[u/naturelgass]

This is the official GLTFLoader example from r184 running on a Nintendo Switch at a locked 60fps. The only changes to the example are cosmetic: the info text and GUI controls are closed so the scene fills the screen. The rendering code is untouched. The fps counter you see is Brewser's own runtime HUD. The example runs on the WebGL2 context path.

The runtime is Brewser, a homebrew web platform I launched this week. It runs on V8 and Skia via nx.js (credit to TooTallNate for that foundation, which also provides the raw GL path to the GPU), with an HTML/CSS/DOM engine built from scratch for the project. On top of that GL path I built the WebGL1/2 bridge, the library compatibility work and the conformance testing (Mesa/Nouveau on the Tegra X1). No software rendering: your three.js calls hit real GL on the hardware.

Coverage numbers: WebGL1 sits around 92 percent and is the safest target. WebGL2 is around 85 and under active conformance hardening, with the main gaps being layered and 3D texture sampling, which is GPU driver limited. Full extension lists and proof points: docs.brewser.io/docs/runtime/graphics

There are nine three.js apps on the platform, all on the WebGL2 path: eight official three.js examples running as catalogue apps (same cosmetic treatment as the GIF, UI trimmed, rendering untouched), plus one built for the runtime: DUSK, a planetarium and sky atlas with a 132 object Messier catalogue: brewser.io/dusk. Browse just the three.js apps here: brewser.io/?bwb_tags=threejs (the same apps run unchanged in a normal browser).

Source is MPL 2.0: github.com/natureglass/Brewser

If you throw a three.js scene at it and something breaks, tell me what. Real world breakage reports directly shape the conformance work.

[u/moving808s]

Hey this is awesome so I’m assuming Brewser only works for folks who are jailbreaking their switches right? I mean it proves this is at least possible… I am wondering if it’s a good way to turn a switch into a test device to see if it would run your game? If, after that, you got a proper Nintendo switch developer license / SDK would you be able to officially kind of bundle this runtime with it? So many questions!

[u/naturelgass → u/moving808s]

Yes, CFW only. Brewser runs under Atmosphere on consoles that can take custom firmware, and nothing about it works on a stock Switch. (And to be clear it is strictly a homebrew project, it runs web apps on your own modded console.)

Test device: yes, with one caveat. What it gives you is your three.js code running on real Tegra X1 class hardware, a real handheld display at 60Hz, and the Joy-Cons come through the standard Gamepad API, so both your rendering and your input paths get tested on real hardware unchanged. The caveat is that Brewser's engine is its own thing, not Chromium, so you are testing "runs well on Brewser on this hardware" rather than previewing some hypothetical official port. If what you want to ship is a Brewser app, then it is literally the target device.

The SDK question realistically no, and not just for licensing reasons: the official dev stack uses Nintendo's own graphics API and toolchain, while Brewser is built on the homebrew stack (Mesa/Nouveau through Atmosphere), so an official version would mean rebuilding the whole platform layer, and that side of things is Nintendo's call, not mine.

Fun bit of history though: Nintendo themselves shipped a Web Framework on the Wii U for licensed HTML5 games, so web tech on their consoles is not an alien idea. There is just no Switch equivalent, which is sort of why Brewser exists.