WASM build of the parser libraries #301

New issue

Closed

opened 2026-07-23 20:52:09 +02:00 by jqueuniet · 1 comment

jqueuniet commented

2026-07-23 20:52:09 +02:00

Owner

The parsers are pure-Rust and &[u8]-driven, so a WASM target should be mostly free. Exposes graphics/dungeon/saves/music decoding to the browser and underpins a future web viewer.

The parsers are pure-Rust and `&[u8]`-driven, so a WASM target should be mostly free. Exposes graphics/dungeon/saves/music decoding to the browser and underpins a future web viewer.

jqueuniet added this to the Bindings & distribution milestone

2026-07-23 20:52:09 +02:00

jqueuniet added the

area/tooling

type/feature

labels

2026-07-23 20:52:09 +02:00

jqueuniet added this to the dm2-tools project

2026-07-23 21:43:33 +02:00

jqueuniet referenced this issue

2026-07-31 22:31:12 +02:00

Web-facing serialization scheme: self-contained JSON vs filesystem + sidecars #307

jqueuniet referenced this issue

2026-07-31 22:31:54 +02:00

Lossless, round-trippable JSON for dm2-saves #308

jqueuniet referenced this issue

2026-07-31 22:32:05 +02:00

Lossless, round-trippable JSON for dm2-dungeon #309

jqueuniet commented

2026-07-31 22:32:28 +02:00

Author

Owner

Investigated feasibility and scoped the work.

WASM readiness — confirmed. All four parser crates cross-compile cleanly to
wasm32-unknown-unknown (verified — libdm2_{graphics,dungeon,saves,music}.rlib all
build). No C / FFI / -sys deps in the parser chain; getrandom / libc / tempfile
are dev-only via dm2-cli and never reach the libraries. The audio chain
(sms-audio / opl-audio / xmrs / xmrsplayer) also builds: xmrsplayer's
thread/time usage is confined to its cpal_player binary, and xmrs's std::fs loaders
are never called (mod-audio feeds &[u8]). So the dm2-wasm cdylib wrapper itself is
small.

(One unrelated aside surfaced: binrw 0.15.1 throws a future-incompat warning on every
build, host and wasm alike — worth its own tracking issue for a version bump, not a
blocker here.)

But the useful boundary is JSON, and the current JSON isn't ready. A browser
viewer/editor needs to hand structured data across the wasm boundary. dm2-dungeon's
json::skproject dump is one-way and lossy (retired-C#-tool interop; start_map
hardcoded to 0), and dm2-saves has no JSON at all. To avoid baking a lossy contract
into the web API, the plan is lossless-JSON-first, then wrap:

Lossless, byte-exact-round-trippable JSON in the parser crates — #308 (saves,
first) and #309 (dungeon). The parsers already round-trip byte-exact at the binary
level, so this is mostly a faithful serde projection guarded by a round-trip test.
A web-facing serialization-scheme decision — #307 — because the existing JSON
assumes a filesystem with sidecar binaries (PNGs / sounds), which the browser lacks.
Then this issue: the dm2-wasm cdylib exposing the settled JSON, graphics as PNG
bytes, and music as PCM (via wasm-pack --target web).

Keeping this open as the wrapper/exposure step; it is now gated on #307 / #308 / #309.

Investigated feasibility and scoped the work. **WASM readiness — confirmed.** All four parser crates cross-compile cleanly to `wasm32-unknown-unknown` (verified — `libdm2_{graphics,dungeon,saves,music}.rlib` all build). No C / FFI / `-sys` deps in the parser chain; `getrandom` / `libc` / `tempfile` are dev-only via `dm2-cli` and never reach the libraries. The audio chain (`sms-audio` / `opl-audio` / `xmrs` / `xmrsplayer`) also builds: `xmrsplayer`'s thread/time usage is confined to its `cpal_player` binary, and `xmrs`'s `std::fs` loaders are never called (`mod-audio` feeds `&[u8]`). So the `dm2-wasm` cdylib wrapper itself is small. (One unrelated aside surfaced: `binrw 0.15.1` throws a future-incompat warning on every build, host and wasm alike — worth its own tracking issue for a version bump, not a blocker here.) **But the useful boundary is JSON, and the current JSON isn't ready.** A browser viewer/editor needs to hand structured data across the wasm boundary. `dm2-dungeon`'s `json::skproject` dump is one-way and lossy (retired-C#-tool interop; `start_map` hardcoded to 0), and `dm2-saves` has no JSON at all. To avoid baking a lossy contract into the web API, the plan is **lossless-JSON-first, then wrap**: 1. Lossless, byte-exact-round-trippable JSON in the parser crates — **#308** (saves, first) and **#309** (dungeon). The parsers already round-trip byte-exact at the binary level, so this is mostly a faithful serde projection guarded by a round-trip test. 2. A web-facing serialization-scheme decision — **#307** — because the existing JSON assumes a filesystem with sidecar binaries (PNGs / sounds), which the browser lacks. 3. Then this issue: the `dm2-wasm` cdylib exposing the settled JSON, graphics as PNG bytes, and music as PCM (via `wasm-pack --target web`). Keeping this open as the wrapper/exposure step; it is now gated on #307 / #308 / #309.

jqueuniet referenced this issue

2026-07-31 22:37:37 +02:00

Bump binrw to clear future-incompatibilities warning #310

jqueuniet referenced this issue

2026-08-06 06:32:22 +02:00

feat(saves): lossless self-contained save JSON + dm2 dump path #311

jqueuniet referenced this issue

2026-09-02 16:40:45 +02:00

feat(dungeon): lossless round-trippable JSON for dungeon.dat (#309) #313

jqueuniet referenced this issue from a commit

2026-09-03 12:37:30 +02:00

feat(wasm): dm2-wasm browser bindings for the parser crates