u/NicRagent

I opened four PRs (1 Open, 3 WIP) for supporting Box3D task execution across Web Workers:

[#7272]: Makes `odin.js` compatible with shared WASM memory.
[#7286]: Lets a WASM host provide Box3D with a monotonic clock.
[#7287]: Adds an atomics-enabled Box3D build and mutex.
[#7288]: Tests shared memory, multiple instances, separate stacks, atomics, and callbacks.

This is intentionally not general `core:thread` support. Applications still manage their own workers, stacks, task scheduling, shared memory, and COOP/COEP configuration.

The latter 3 PRs are WIP. Feedback is welcome. Also should I also look into a separate proposal for `core:thread` support on JS/WASM?

For ingot + Box3D Web Worker demo - https://openalloy.ai/demos/ingot-box3d-advanced/

The experiment is simple: if deterministic simulation testing shapes the engine from the beginning, how quickly can it become useful - and how much of it can be tested without a window, GPU, or live operating system? Production code runs against simulated input and failure conditions, with failures reproducible from a seed.

The API is layered: start with the managed application shell and UI facade, drop down to explicit layout and rendering when needed, or use the raylib-shaped graphics layer directly. One Odin codebase targets macOS, Windows, Linux, and browsers through WebGPU.

This is an early `0.x` source release. I’m looking for real applications especially raylib projects to discover where the approach works, where it breaks down, and how far it can go.

Ingot is heavily influenced by TigerBeetle, adapting its Tiger Style and DTS ideas to application and graphics development in Odin.

https://openalloy.ai/ingot

PR series: Box3D task workers for Odin WASM

Ingot: an experiment in using DTS to rapidly build a production-grade immediate-mode application framework for Odin