3D + 2D: Testing out my cross-platform WASM graphics engine

Hacker News Discussion ↗

A new cross-platform WebAssembly-based graphics engine aims to turn GPU rendering into portable “renderlets”: sandboxed WASM modules that generate graphics data and can be embedded into any host app or browser. Commenters probe how this compares to tools like Unity, Godot, wgpu, sokol, and SDL, focusing on its role as a low-level, runtime-agnostic graphics plugin layer rather than a full game engine, and on future integration with standards like WASI-WebGPU. The thread also raises practical concerns and opportunities around shaders, text and font rendering, audio/input APIs, performance, and whether such a model could underpin broader cross-platform UI or even Electron-style app replacements.

Overview of the Project

  • A cross‑platform graphics engine where “renderlets” are WebAssembly modules that generate graphics data; “wander” is the C++ host/runtime that embeds and runs these modules.
  • Goal: high‑level, data‑driven graphics description compiled to portable Wasm, then mapped to platform GPU APIs. Positioned more as “graphics middleware / plugin system” than full game engine.

Relation to Existing Tech

  • Compared to sokol: sokol is seen as a minimal “STB-like” app/graphics layer; renderlet aims at higher‑level descriptions that generate runtime code.
  • Plans to build on WebGPU via wgpu and wasi-webgpu/wasi-gfx rather than re‑implementing low‑level backends.
  • Some see parallels to Flash/SWF, Rive, Godot, Flutter, Kha, and .NET/COM/CLS‑style intermediate layers.

Shaders, Languages, and Runtime

  • Current version requires host‑provided shaders; long‑term plan is automatic shader handling via higher‑level shader APIs (e.g., WGSL, possible Slang).
  • Today it’s a C++ library; intent is to ship a C ABI as .so/.dll so bindings for Go, Python, etc. can be generated easily.
  • Host application owns the event loop and window; renderlets are embedded modules with defined inputs/outputs.

Use Cases vs Game Engines

  • Supporters argue we need a lightweight, SDL‑like cross‑platform rendering/multimedia layer, not another Unity/Unreal.
  • Skeptics note Unity/Unreal already provide cross‑platform, full‑stack solutions and question whether a small team can match their practical value.
  • Some suggest collaborating with or building atop Godot or other existing engines.

Web, WASM, and Performance

  • Threading via SharedArrayBuffer is reported to work well now in modern browsers, though Safari has limitations.
  • Wasm graphics code currently runs at roughly ~80% of native in informal tests, considered acceptable for most non‑AAA 3D workloads.
  • Several comments highlight WebGPU’s limitations for AAA games (feature gaps, memory issues, overhead), but see strong potential for visualization and rich web apps.

Plugin/Renderlet Model & Skepticism

  • Proponents frame renderlets as sandboxed, reusable graphics plugins (e.g., TAA module) that can be dropped into pipelines across platforms.
  • Critics question why introduce an extra Wasm layer when C++ and WebGPU already exist, and see the main value only if there is a real ecosystem/marketplace of third‑party renderlets.

Future Features & Wishes

  • Strong interest in robust text and font support (likely via HarfBuzz), low‑level audio APIs, and broad input handling.
  • Some see this tech as a possible foundation for cross‑platform GUI frameworks or even Electron‑style app stacks, though that’s not its current focus.