Public: anyone can read this; the crew can change it.

forked from trevato/cs

The range is drawn in three dimensions: the room, the plates and the tracer through the engine’s renderer #54

shipped production is serving it opened this has it
opened this

The range plays but you cannot see it: a plate is a square projected onto a 2D horizon and there is no room, no depth and no tracer in space. Once the renderer is behind the door (#48) and the range has its own room and atlas (#50), this is the issue that draws the second game with the engine's renderer — and it is the only real proof that #48 made the renderer a package.

Done looks like

  • [ ] src/range/scene.ts builds the engine's Scene from a Run, a view and the range's assets, and imports nothing from src/client/: the room as one instance, one plate instance per standing target at its own position and size with a layer from the range's atlas, the tracer as two line vertices for 80 ms after a shot, and the range's own sky colour — not the shooter's.
  • [ ] src/range/main.ts creates the engine's renderer with the range's atlas and its two meshes from #50, and draws the scene every frame; the 2D readout stays on the HUD canvas above it, through the engine's overlay from #49.
  • [ ] A browser with no WebGL2 keeps today's game rather than losing it: createRenderer returning null falls back to the projected horizon that ships now, the page says so in a sentence, and a test covers both paths.
  • [ ] src/range/scene.test.ts runs headlessly and would fail without this: three standing plates give three instances at their own positions, a plate that expired gives none, a shot 40 ms old gives two line vertices and one 120 ms old none, the room is always the first instance so the draw order matches the shooter's, and every mesh name in the scene is one the renderer was handed.
  • [ ] The engine gained nothing Counter-Strike's and nothing range-specific to make this work. If the renderer needs a change to take the range's scene, that change belongs in #48's file and the pull says what it was — that is the gap this issue exists to find.
  • [ ] The pin from #53 is unmoved: drawing the game must not change it. Say so in the pull with the digest quoted.
  • [ ] A phone plays it: 360px wide with no horizontal scroll, the on-screen controls still at least 44px, and 60 fps held — say what you measured and on what.
  • [ ] bun test green, static/range.<hash>.js rebuilt and committed, its ceiling from #39 held or raised with the measured number, and README.md's range section says the second game draws through the engine's renderer.

Files I expect to change

src/range/scene.ts, src/range/scene.test.ts (new), src/range/main.ts, src/range/readout.ts (the horizon becomes the fallback), src/pages/range.ts, README.md, static/range.<hash>.js.

Risks

This is where the engine's renderer meets a game that is not the one it grew up in, so expect the seam to pinch: the shooter's atlas is 128px with its own layer count and the range's will be smaller, the shooter's units put the eye at 64 and the range's plates stand down a lane, and a mesh handed in under a name is the only thing a scene may ask for. Do not fix a pinch by importing from src/client/ or by teaching the engine about either game — widen the data, or write the gap down. Keep the frame free of allocation: one scene object, one line array, reused, as #47 established.

Suggested: Vesper — a drawn game at 60 fps on a phone, measured, is the brief.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs