● P4 WebGPU wasm32

HUD

A game-style heads-up display with no game behind it: health and mana bars, an ability row that cools down, a wave banner and a damage ticker — every pixel of it built out of the draw list's rectangles, outlines and text spans, and driven by a scripted ticker on the server.

hud — crcbl
Starting…
Click the canvas first. A canvas has to hold keyboard focus to receive keys, and browsers will not start audio until you have interacted with the page. Clicking away pauses the game and lets go of whatever key was held — no platform sends the release for a key that was down when focus left.
Touch reaches the engine. A contact arrives as an ordinary pointer, and the first one is also the gesture a browser waits for before it will start audio. Whether this demo can be played with one is in its controls below — not all of them can. Switching tabs pauses the game and lets go of whatever was held: no platform sends the release for an input that was down when focus left.

controls

There are none. That is the sample.

This is the one demo here you do not play. It takes no input: key_event in apps/hud is empty on purpose, because the subject is the widget system and a player between you and it would only be showing something else. Everything on the page is the server's ticker working through a fixed script.

The three keys below are the engine loop's, not this sample's, and they are the same three every other demo answers to. Click the canvas first — a canvas has to hold focus to receive them, and letting go of it pauses the loop.

why a sample with nothing to do

Because the UI has to be dogfooded by something that is not a game.

Every other sample here proves the engine can host a game, and each one draws a HUD as a side effect of being one. This sample is the HUD, and nothing else: it is the fixture the UI system is developed against, so a widget that is awkward to build shows up as an awkward file in apps/hud rather than as a paragraph in a design document.

Press F3 for the proof. The debug panel is drawn from the same primitives, into the same draw list, and one of its two sections counts the commands the page it is sitting on top of just emitted — rectangles, outlines and text spans, per frame.

It is still a real client/server sample: the ticker is a game module the authoritative server owns, stepped on the fixed timestep, with a client on the other end of an in-memory transport. What it is not yet is styled — the stylesheets, the themes and the runtime switcher this sample exists to exercise are waiting on a layout engine that does not exist, and the page positions itself from named constants until it does.

what is actually running

The native sample, with three differences the browser forces.

Start-up is polled across several frames, because requestDevice is a promise and the main thread cannot block on it. The frame loop is driven by requestAnimationFrame out here rather than by a loop inside the engine. And the clock is the browser's, because wasm32-unknown-unknown has no Instant.

There is no fourth difference about saved data, which every other demo here has: this one keeps nothing, because there is no score to keep. It is also the smallest artifact on the site — no sprite sheet, no audio, no world.

Open the console for the engine's log. The wasm module imports nothing, not even console.log, so log lines are queued inside wasm and drained by the page each frame. crcbl.audio(), crcbl.saves() and crcbl.logLevel(4) are there too.