mirror of
https://github.com/openfrontio/OpenFrontIO.git
synced 2026-06-26 09:22:44 +00:00
dcdfd7bad7923af46a1a89d406ecadb892ed2848
34 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Vivacious Box
|
dcdfd7bad7 |
If player is localplayer, set structure border to territory color (#4366)
Resolves #4365 ## Description: Currently the border of icons are using borderColor which is grey for local player <img width="227" height="281" alt="image" src="https://github.com/user-attachments/assets/9e334e19-c5b2-49ca-a85d-4576a5bbc1a9" /> This set it to territory color <img width="187" height="102" alt="image" src="https://github.com/user-attachments/assets/9b9f27f9-69e2-4ae7-9f35-a789b56b45de" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [ ] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: Mr. Box |
||
|
Evan
|
6159f1f186 |
Fix anonymous-names setting not hiding names on the map (#4345)
## Problem Enabling the **hidden names** (anonymous names) setting hid names in the leaderboard/HUD but **not on the map**. The GL name renderer (`NamePass`) drew `slot.static.displayName` — always the real name — and never consulted `userSettings.anonymousNames()`. The HUD works because it calls `PlayerView.displayName()` (which honors the setting) on each render, but the names baked into the GPU texture bypassed that path entirely. ## Fix Push the *resolved* name into the renderer instead of the raw static name: - **`WebGLFrameBuilder.syncPlayers`** registers each player with `displayName: p.displayName()` (honors the setting) instead of `static.displayName`. Covers enabling the setting before a game and players who join after a toggle. - **`WebGLFrameBuilder.refreshNames` → `MapRenderer` → `Renderer` → `NamePass.refreshNames`** is a new path that re-resolves cached names and forces a re-upload (resets `slot.nameLen = 0`, which also recomputes the name half-width so it stays centered). - **`ClientGameRunner`** listens for the `settings.anonymousNames` change event and calls `refreshNames`, mirroring the existing territory-patterns live toggle. ## Behavior - Enabled before a game → players register with anonymous names. - Toggled mid-game → map names flip to/from anonymous on the next sim tick (~100ms), matching the leaderboard. - Your own name is unaffected (unchanged — `PlayerView` maps the local player's anonymous name to their real name). ## Testing `tsc --noEmit` passes for all edited files. This is a WebGL rendering change with no straightforward unit test; verified by tracing the data flow (resolved name → cached `slot.static.displayName` → re-upload on dirty). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Evan
|
c7fdc4ec2d |
Cap renderer device-pixel-ratio at 2 (#4339)
## What
Routes every renderer call site that read `window.devicePixelRatio`
through a single `renderDpr()` helper that caps the value at **2**.
```ts
export function renderDpr(): number {
return Math.min(window.devicePixelRatio || 2, 2);
}
```
## Why
On very high-DPI displays (DPR 3, common on phones) the WebGL backing
store was sized at 3× CSS pixels — ~9× the fragment work of 1× — for a
marginal visual gain over 2×. Capping at 2 keeps retina (DPR 2)
pixel-perfect while clamping the 3× case.
## How it stays correct
DPR isn't just the canvas size — it's one coordinate system shared by:
- the canvas backing-store size (`Renderer.resize`)
- the camera's screen↔world math (`Camera.resize` / `screenToWorld` /
`worldToScreen`)
- the camera zoom scale (`ClientGameRunner.syncCamera`)
- the constant-CSS-pixel-size world text (`WorldTextPass`)
These must all use the same DPR value or pointer hit-testing and text
sizing drift. Routing them through one helper guarantees that. The
diagnostics reporter (`Diagnostic.ts`) is intentionally left reading the
real hardware DPR, since its job is to report the actual device.
## Test
- `tsc --noEmit` clean for all touched files (one pre-existing unrelated
`marked` types error remains on `main`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Evan
|
305534cc65 |
Dispose WebGL renderer when a game stops 🧹 (#4295)
## Problem `ClientGameRunner.stop()` tore down the worker, network, and sound, but left the `MapRenderer` (and its WebGL context), the WebGL canvas, the input overlay, and the self-driving RAF loop in place. When you exit a game via the **Exit button** or browser **back**, the page navigates to `/`, so the browser reclaims everything — that path is fine. But you can start a new game **without** a reload: matchmaking and joining another lobby go through `handleJoinLobby`, which calls `lobbyHandle.stop(true)` then `joinLobby()` on the same document. The old WebGL context stayed alive (the never-cancelled RAF kept it referenced, so it wasn't even GC'd), and each new game stacked another context. After a few games, mobile browsers hit their WebGL context limit — matching the repro in #4267. ## Fix `stop()` now disposes the renderer: - cancels the self-driving RAF loop and disconnects the frame-loop resize observer - disposes the `MapRenderer` (frees all GPU resources) - removes the WebGL canvas and the input overlay from the DOM `GPURenderer.dispose()` additionally calls `WEBGL_lose_context.loseContext()` so the context is released promptly instead of waiting on unreliable GC. The territory-patterns settings listener is wired to the existing graphics `AbortController` so it no longer outlives the disposed view. The cleanup runs unconditionally in `stop()` (a superseded join can stop before the game becomes active) and is idempotent against repeated `stop()` calls. Fixes #4267 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
6c84919801 |
Smooth nuke point-light position per frame in ambient mode (#4311)
## Summary Follow-up to #4255. That PR made nuke **sprites** glide per render frame — `UnitPass.drawMissiles` lerps each nuke's `lastPos→pos` by wall-clock progress through the current tick. But in ambient/night mode the glow *behind* a nuke comes from a separate pass, `PointLightPass`, whose instance buffer is packed once per tick in `updateLights()` from the raw `unit.pos`. Its per-frame `draw()` (run every frame via `LightmapPass`) only set uniforms and issued the instanced draw — it never repositioned the lights. So the sprite moved at 60fps while its light jumped once per 100ms tick. ## Fix Mirror `UnitPass`'s smoothing in `PointLightPass`: - `updateLights()` records a `smoothSegs` tuple `(lightIdx, lastX, lastY, x, y)` for each `SMOOTHED_NUKE_TYPES` unit whose `lastPos !== pos`, and stamps `lastUnitsUpdateMs`. - A new `applySmoothing()`, called at the top of `draw()`, lerps those lights by wall-clock tick progress (`(now - lastUnitsUpdateMs) / tickIntervalMs`, clamped to 1) and re-uploads **only** the affected instances. Unlike `UnitPass` (which re-uploads its tiny missile buffer wholesale), the light buffer can hold thousands of static structure lights, so a full per-frame re-upload would be wasteful. - `tickIntervalMs` comes from a new `config` constructor param, wired through in `Renderer.ts` (the same `config` already passed to `UnitPass`). The light now uses the exact same `lastPos→pos` endpoints and alpha as the sprite, so the two track together. ## Test plan - `npx tsc --noEmit`, eslint, and prettier all clean. - `npx vitest tests/client/render --run` — 40 passed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
1ad71b9cfa |
Fix hover-highlight inner border lagging during tile changes (#4303)
## Problem
When you hover over a territory, it highlights with a band that is
`highlightThicken` (default **2**) tiles deep — the edge plus 2 interior
rings, computed via a Chebyshev expansion in `border-compute.frag.glsl`.
Starting a hover triggers a full border recompute, which paints the band
correctly. But while you keep hovering and tiles change owner (territory
growing/shrinking, combat at the front), only the cheap **incremental**
scatter path runs. `BorderScatterPass.pushWithNeighbors` repainted only
the changed tile **+ its 4 cardinal neighbors** (radius 1) — fine for
normal borders, but not for the highlight band. A changed tile affects
the thickening of *every* highlight-owner tile within `highlightThicken`
of it, and those interior tiles were never repainted, so the **inner
edge of the highlight band stayed stale** ("the inside border is not
getting updated"). This was a documented trade-off in the class comment.
## Fix
When a highlight is active, `pushWithNeighbors` now repaints a Chebyshev
**box of radius `highlightThicken`** around each changed tile (the box
subsumes the cardinal cross, so normal borders still update). With no
highlight active it stays on the cheap 5-point cross, preserving the
pass's O(dirty-tiles) scaling. The extra cost (~25 vs 5 points/tile at
default) only applies while actually hovering.
## Testing
Hover over a territory while it grows/shrinks (early-game expansion or a
war front) and confirm the inner edge of the highlight band now tracks
the moving border instead of lagging.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Evan
|
0639cdb29b |
Fix nuclear fallout covering UI overlays (#4302)
## Problem Nuclear fallout was rendering on top of UI overlays (most visibly the SAM launcher range circles), hiding them. ## Cause In `renderOverlays()` (`src/client/render/gl/Renderer.ts`), the fallout bloom pass was drawn near the end of the overlay sequence — after the SAM radius, range circles, structures, bars, etc. — so it painted over all of them. ## Fix Moved `bloomPass.draw(...)` (fallout bloom) to draw right after the ground units and before all UI overlays. Fallout is a ground-contamination effect, so it now sits above the terrain/units but below every UI overlay, which all render on top. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
10ca2d1230 |
Restore gray in-game background to match v31 (#4301)
## Summary The in-game map background changed from gray (v31) to near-black after the WebGL renderer rewrite. This restores the gray. The renderer rewrite hardcoded the base-layer clear color to `(0.04, 0.04, 0.06)` in `drawBaseLayer` (`src/client/render/gl/Renderer.ts`). v31 set the background via `PastelTheme.backgroundColor()`, which returned `rgb(60,60,60)`. This change sets the clear color back to that gray. ## Notes - The old theme-based `backgroundColor()` system was removed in the rewrite, so this hardcoded clear color is now the single source for the map background. 🤖 Generated with [Claude Code](https://claude.com/claude-code) |
||
|
Evan
|
8b9bda1c8b |
Add ocean color override to graphics settings (#4269)
## What Adds a **Terrain** section to the graphics settings modal with a color picker and a hex-code text field (paste a `#rrggbb` code) for the **ocean** (deep water) color. ## Details - The picked color sets the *shallow-water base*; the existing per-depth brightness gradient is preserved (deeper water still darkens). - Only deep water is affected — shoreline water and land are untouched. - Follows the same override pattern as every other graphics setting: the default lives in `render-settings.json` (`terrain.oceanColor`), the override is a field in `GraphicsOverrides`, and `applyGraphicsOverrides` copies it into the live `RenderSettings`. - Rebased on #4271 (settings resolved before renderer construction): the terrain texture **bakes the resolved ocean color at construction**, so a saved override shows on load with no special-casing. Terrain is baked into a GPU texture rather than read per-frame, so a *live* change still triggers an explicit `view.rebuildTerrain()`. - Resetting graphics overrides clears it back to the default ocean color. ## Testing Verified live in a headless singleplayer game: - A **saved** ocean override renders green deep-water on load, baked at construction with no settings-change event fired. - A mid-game color change recolors the deep ocean instantly, gradient preserved, shoreline/land untouched. `tsc` and ESLint clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
54a7042303 |
Resolve render settings before renderer construction (#4271)
## What
The client now resolves render settings (defaults + user overrides) **up
front** and passes the result into the renderer, instead of the renderer
constructing defaults itself and the client re-applying overrides
afterward.
```
before: new GPURenderer(...) // this.settings = createRenderSettings() (defaults)
view.getSettings() → deepAssign(defaults) → applyGraphicsOverrides(...) // patch after the fact
after: const settings = createRenderSettings(); applyGraphicsOverrides(settings, ...); applyDarkModeOverride(settings, ...)
new GPURenderer(..., settings) // built with the final values
```
## Why
- **Removes the construct-with-defaults / re-apply-overrides dance.**
Every pass — including texture-baking ones like terrain that read their
settings *once* at build time rather than every frame — is now built
with the final values on the first try. (This is the cleanup that
motivated the change, surfaced while adding a terrain color override in
a separate PR.)
- **Fixes a latent context-restore bug.** On WebGL context loss/restore
the renderer was rebuilt via `createRenderSettings()` → fresh
**defaults**, silently dropping any user overrides until the next
settings change. `MapRenderer` now holds the resolved settings object
and hands the same one to the recreated `GPURenderer`, so overrides
survive a restore.
Live setting changes still work exactly as before:
`regenerateRenderSettings()` re-resolves and `deepAssign`s onto the
renderer's live settings object in place (passes hold a reference, so
they pick it up next frame).
## Changes
- `Renderer.ts` (`GPURenderer`) — constructor takes a `settings:
RenderSettings`; drops the internal `createRenderSettings()` call.
- `MapRenderer.ts` — holds the resolved settings and passes it through
on construction and on context-restore re-init.
- `ClientGameRunner.ts` — new `resolveRenderSettings()` helper used both
at construction and by `regenerateRenderSettings()`; `createWebGLView`
takes the resolved settings; the now-redundant initial
`regenerateRenderSettings()` call is removed.
## Testing
Verified live in a headless singleplayer game:
- A saved `nameScaleFactor` override is present in `getSettings()`
immediately after game start, with no settings-change event fired
(construction path).
- A mid-game override change is reflected in the live settings
(regenerate/in-place path).
- The map renders correctly through spawn phase.
`tsc` and ESLint clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Evan
|
f4db4a33c8 |
Send nukes as motion plans and render them smoothly per frame (#4255)
## Summary Follow-up to #4244's payload work: nukes were the last per-tick movers flooding the worker → main update stream. - **Core**: nuke trajectories are fully determined at launch (precomputed parabola), so `NukeExecution` now records a `GridPathPlan` when the nuke is built — same mechanism trade ships use — and the client derives the position each tick. Per-tick `UnitUpdate`s for nukes in flight are suppressed; only targetable flips and deletion (interception/detonation) still emit. This covers atom bombs, hydrogen bombs, and MIRV warheads (dozens of per-tick movers per MIRV separation). - The plan path replays a separate pathfinder rather than reusing the stored trajectory array: the curve's cached points don't advance exactly one index per tick, and the plan must match the movement pathfinder's exact per-tick tile sequence. - `startTick` accounts for MIRV warheads' staggered `waitTicks`. - **Render**: `UnitPass.drawMissiles` now lerps each nuke's instance position `lastPos→pos` by wall-clock progress through the current tick, so nukes glide along their arc at render framerate instead of jumping once per 100ms tick. Both endpoints are real simulated positions — the rendered nuke trails the sim by at most one tick and settles exactly on it when ticks stop. Plan-driven units sync `lastPos` on path-stall ticks so the lerp never replays a segment. Shells keep their existing two-instance trail; SAM missiles are unchanged. ## Test plan - New `tests/nukes/NukeMotionPlan.test.ts`: tick-exact alignment between the recorded plan and core nuke position over the whole flight (mirroring `GameView.advanceMotionPlannedUnits` math), `waitTicks` offset, and that no per-tick unit updates are emitted in flight except targetable flips and deletion. - Full suite passes (1452 + 65), tsc/eslint/prettier clean. - Verified in-game (headless Chromium, real WebGL): atom bomb arcs from silo to target with the client position driven by the plan, missile sprite renders intact while the smoothing rewrites the instance buffer every frame, detonation FX land at the target. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Evan
|
7ec26df4b4 |
Fix three high-impact renderer performance issues (#4251)
## Summary A performance review of `src/client/render/` found three issues where per-tick work silently defeated existing optimizations. All three are surgical fixes with no behavior change. ### 1. Relation matrix forced a full-map border recompute every tick `buildRelationMatrix` ran unconditionally every tick and `updateRelations` was pushed unconditionally, so every tick paid: - a 1 MB `fill(0)` + rebuild on the CPU, - a 1 MB `texSubImage2D` upload (~10 MB/s steady-state), - a **full map-resolution border fragment pass** via `globalDirty` — which also called `scatter.clear()`, making the incremental `BorderScatterPass`/`patchTile` path dead code during live play. Now the matrix is rebuilt and uploaded only when alliances/embargoes actually change. `PlayerUpdate`s are delta-encoded (`diffPlayerUpdate` content-compares `allies`/`embargoes`), so field presence is a reliable change signal. The WebGL context-restore path force-pushes relations, matching the existing structures/railroads pattern. ### 2. Heat decay pass + full-map blit ran every frame, forever `HeatManager.decayHeat()` set `heatActive = true` on every tick regardless of whether any fallout existed. With `heatDecayPerTick: 1` the drain window (255 ticks) was always re-armed before expiring, so the map-sized decay/transition fragment pass **plus a full-map R16UI `blitFramebuffer`** ran at 60 Hz for the entire game — even if no nuke was ever fired. On large maps this was likely the biggest fixed GPU cost in the renderer. Now `TerritoryPass` flags FALLOUT-bit flips at GPU-write time (delta, drip-drain, and conservatively on full uploads), and the renderer activates the heat pipeline only then. While inactive, `updateHeat()` does no GL work at all. Skipping the prev-tile blit while inactive is safe because the transition shader only reads the fallout bit, and every fallout flip activates the pipeline before its tile flush reaches the GPU. ### 3. `computePlayerStatus` was O(players × units) per tick The per-player loop scanned **all units** looking for that player's nukes (~1M+ iterations/tick at scale). Inverted to a single pass over units building per-owner `nukeActive`/`nukeTargetsMe` sets, then O(1) lookups in the player loop. ## Testing - Full suite passes (1386 + 65 tests), including the 19 existing `computePlayerStatus` behavior tests; `tsc --noEmit` and ESLint clean. - Verified in a live singleplayer game (headless Chromium): territory fill, borders, names/troop counts, and leaderboard all render correctly. - Fallout path verified end-to-end: built a missile silo, launched an atom bomb (1235 fallout tiles in tile state), and the fallout glow rendered at the impact site — under the new gating that glow can only appear if the `falloutTouched → activate()` chain works. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Evan
|
aa4b490e68 |
Simplify WebGL renderer integration: remove dead extension code, untangle GameView naming (#4240)
## Summary The WebGL renderer was adapted from an external extension and carried a lot of machinery this integration never uses (replay playback, its own input/event system, a GL radial menu). This PR is two mechanical cleanup passes with **no behavior change**: delete the dead code, then untangle the `GameView` naming collision. **78 files, +142 / −2,197.** ### Pass 1 — remove dead extension baggage - **Replay/copy mode**: `FrameData.tileMode` was hard-coded `"live"`; the copy branches in `frame/Upload.ts`, `UploadOptions` (never passed), `applyFullFrame`/`applyFullTiles`/`applyDelta` on the facade and `GPURenderer`, `HeatManager.resetForSeek`, and the seek-upload methods on `TerritoryPass`/`TrailPass` were all unreachable. Also deletes `types/Replay.ts`, `types/FrameSource.ts`, `types/GameUpdates.ts`, `types/Game.ts` (imported only by the types barrel). - **FrameEvents**: trimmed from 14 fields to the 3 actually populated and read (`deadUnits`, `conquestEvents`, `bonusEvents`). The other 11 fed the extension's stats system and were never written or read here. - **GL radial menu**: `RadialMenuPass`, its 4 shaders, and ~10 API methods on facade + renderer had zero callers — the game uses the DOM/d3 radial menu in `hud/layers/RadialMenu.ts`. The pass was constructed and drawn every frame for nothing. - **Facade event system**: `GameViewEventMap` defined 10 event types (`click`, `hover`, `scroll`, …) but only `contextrestored` was ever emitted — input actually flows through `InputHandler` → EventBus → controllers. Replaced the listener map with a single `onContextRestored` callback and deleted `Events.ts`. Also fixed the stale header comment claiming the facade handles user interaction. - **Unused API surface**: removed ~20 facade/renderer methods with zero callers (camera passthroughs like `panTo`/`zoomTo`/`fitMap`/`screenToWorld`, hit-testing queries, SAM replay setters, `setSelectedUnit`, `clearFx`/`setFxTimeFn`, `onFrame`/`afterRender`/fps tracking). Deliberately left alone: `Camera`'s pan/zoom primitives (building blocks for a possible future camera unification) and the `timeFn` plumbing inside the FX passes (deeply embedded as defaults; only the dead renderer-level wrappers were removed). ### Pass 2 — untangle the three GameViews - `render/gl/GameView.ts` → **`MapRenderer.ts`** (class `MapRenderer`). Every importer was already aliasing it as `WebGLGameView` to dodge the collision with the simulation-mirror `GameView` in `client/view/`, so this removes aliasing rather than adding churn. `render/CLAUDE.md` updated. - Deleted the `src/core/game/GameView.ts` back-compat shim (its own TODO asked for this). All 51 importers now import from `src/client/view/` directly via a new 3-line barrel `view/index.ts`. ## Test plan - `tsc --noEmit` clean, `eslint` clean - Full test suite passes (1,385 + 65 server tests) - Manual verification via headless Chromium: started a singleplayer game and confirmed the renderer works end-to-end — terrain draws, spawn-phase overlay shows, territories fill with borders after spawning, player names/flags render, no renderer console errors 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
FrederikJA
|
b1e9955af3 |
Coordinate grid (#4224)
**Add approved & assigned issue number here:** Resolves #3839 ## Description: A bunch of small updates to make the coordinate grid a lot nicer. - Removes black backgrounds on text. - Allows user to modify the opacity of the coordinate grid - Persist the enable state of the coordinate grid ### Before <img width="2344" height="1168" alt="image" src="https://github.com/user-attachments/assets/22c2fb77-9db6-41bf-a50a-987f651cc19a" /> ### After <img width="2331" height="1174" alt="image" src="https://github.com/user-attachments/assets/0e5a9575-8a79-407b-8d78-8564df02b259" /> <img width="407" height="947" alt="image" src="https://github.com/user-attachments/assets/b9e5f9f1-3cc1-4832-b7d4-38e1f5e93d57" /> ## Please complete the following: - [X] I have added screenshots for all UI updates - [X] I process any text displayed to the user through translateText() and I've added it to the en.json file ## Please put your Discord username so you can be contacted if a bug or regression is found: FrederikJA |
||
|
evanpelle
|
2d747d0f8b |
Flash alliance icon when renewal prompt is active
When an alliance is within the renewal-prompt window, the alliance icon above the player's name now pulses, ramping from 2 Hz to 5 Hz as expiry approaches (same effect as the traitor flash). The flash window is driven by allianceExtensionPromptOffset() — the same Config value that triggers the "renew alliance" prompt in the actionable events display — so the two always stay in sync. The shader only knew the alliance fraction, not absolute time, so computePlayerStatus now also emits allianceRemainingTicks, packed into the free pd7.w slot of the player-data texture. |
||
|
Evan
|
1db02acdc2 |
Move theme data into the render-settings JSON pipeline (#4223)
**Add approved & assigned issue number here:** N/A — maintainer refactor. ## Description: Replaces the theme class hierarchy (`BaseTheme`/`PastelTheme`/`ColorblindTheme`) with theme JSON files — `default-theme.json` and `colorblind-theme.json` — combined with `render-settings.json` at runtime into a single graphics-configuration pipeline (`settings.theme`). One `SettingsTheme` class keeps the algorithms (color allocation, team-variation generation, LAB-contrast structure colors) and reads all data from `ThemeSettings`; adding a theme is now just adding a JSON file. Colorblind mode (#4150) is fully preserved: - Same palettes — the 32-color CVD-safe pool and Okabe-Ito team colors are baked into `colorblind-theme.json` - The relative border rule (`l × 0.6`) is expressed as a `borderLightnessScale` knob alongside the default theme's absolute `borderDarken` - The mid-game re-theme wiring (`refreshPlayerColors`/`refreshPalette`) and the affiliation/friend-foe tint overrides are unchanged; `applyGraphicsOverrides` now also swaps the `settings.theme` slice - `deepAssign` replaces arrays wholesale so differing palette lengths survive theme switches Verified against the previous implementation with an equivalence test (since removed): default-theme colors are byte-identical including allocation order; colorblind team/derived colors are byte-identical, and FFA assignment may permute within the same palette (hex baking rounds upstream's fractional-RGB colord objects, which can flip the allocator's greedy delta-E ordering — rendered colors round identically either way). Also removes dead theme surface (`terrainColor`, `backgroundColor`, `falloutColor`, `font`, `textColor`, spawn-highlight variants, `PastelThemeDark`) — GL terrain colors and dark mode were already handled in the renderer. Note this means the colorblind terrain bands from #4150 were dead code (nothing calls `terrainColor`; GL terrain comes from `ColorUtils.encodeTerrainTile`); wiring CVD-safe terrain into the terrain texture would be a follow-up. ## Please complete the following: - [x] I have added screenshots for all UI updates — N/A, no UI changes (verified color-identical) - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file — N/A, no user-visible text - [x] I have added relevant tests to the test directory — `tests/Colors.test.ts` updated for the new pipeline (team colors from theme JSON, colorblind palette/border tests) ## Please put your Discord username so you can be contacted if a bug or regression is found: evanpelle 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Evan
|
7137347b7d |
Fade player names under the cursor, with a graphics setting to tune it (#4221)
## Description: Player name plates can block the view of what's underneath them (structures, units, terrain). This PR fades the entire name plate — name, troop count, flag, and emoji/status row — to 25% opacity while the cursor is over it, so you can see and click what's behind it. **How it works:** - `HoverHighlightController` pushes the cursor's world position into the renderer on mouse move. - `NamePass` hit-tests the cursor against each player's name plate bounds on the CPU (mirroring the lerp/sizing math in `name.vert.glsl`) and passes the matched player's ID to the text, icon, and status-icon programs, which apply the alpha multiplier in their shaders. **Graphics setting:** - New "Name opacity under cursor" slider in the Graphics Settings modal (Name Labels section), range 0–1, default 0.25. Setting it to 1 disables the fade entirely. - Wired through the existing `GraphicsOverrides` pipeline: changes apply live and are cleared by "Reset to defaults". - Tuning knob exposed as `name.hoverFadeAlpha` in `render-settings.json` and the debug GUI. ## Please complete the following: - [ ] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [ ] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
evanpelle
|
9189aac687 |
Improve railroad visibility: own-rail contrast color and thickness setting
Local-player rails previously rendered in the white focused-border color from the palette, making them hard to see on light territory. Rails now use a dedicated local rail color: white normally, flipped to black when the territory backdrop is too light for white to read against (patterns average their primary/secondary brightness). Also add a railThickness render setting (0.5-3, default 1), exposed in the Graphics Settings modal and the debug GUI, and persisted via GraphicsOverrides. In the medium-zoom LOD, rails are now drawn as screen-space anti-aliased lines around each tile's rail centerline, accumulated from the 3x3 neighborhood so thick lines spill cleanly into neighboring tiles; detailed mode scales its sub-grid band widths. - PlayerView: compute railColor() (white/black by backdrop brightness) - RailroadPass/shader: uLocalPlayerID, uLocalRailColor, uRailThickness - render-settings.json, RenderSettings, GraphicsOverrides, RenderOverrides: new railroad.railThickness knob - GraphicsSettingsModal: "Train track thickness" slider (+ en.json keys) - tests: schema + apply coverage for railroad overrides |
||
|
Evan
|
26d8a314ae |
Scale defense-post border + fill rendering to thousands of posts (#4181)
## Description
Scales the defense-post border effect so it works with **thousands** of
Defense Posts instead of silently capping at 64.
### Problem
The border "checkerboard" (drawn on a player's border tiles when a
same-owner Defense Post is within range) was computed per-pixel: for
every border fragment, the shader looped over a `uniform vec4
uDefensePosts[64]` array doing a distance test. Two issues:
- **Hard cap of 64** — posts beyond the first 64 were dropped, so their
checkerboard never appeared.
- **Wrong cost shape** — work was `border_tiles × posts`; every added
post made every border pixel slower.
### Solution: invert the loop into a coverage texture
New `DefenseCoveragePass` stamps one instanced circle per post into a
map-resolution `R8` coverage texture (`1.0` = tile is within range of a
**same-owner** post; the owner check samples `tileTex` at stamp time, so
enemy posts never light up your border). It's a single
`drawArraysInstanced` regardless of post count — the same instancing
pattern `UnitPass`/`StructurePass` already use. The border-stamp shader
now reads one texel of that texture instead of looping; the old uniform
array, the 64-cap, and the per-fragment scan are removed from
`border-compute`/`BorderStampPass`/`BorderScatterPass`.
### Incremental re-stamping (dirty-block grid)
Coverage depends on tile ownership, which drips every frame during
combat, so a full re-stamp every frame would be wasteful at high post
counts. Because a tile changing owner only changes *its own* coverage,
the pass tracks a grid of dirty **blocks** and re-stamps only the blocks
containing changed tiles, scissored to each block (`gl.scissor` confines
the clear + draw to the changed region). Post add/remove and full tile
uploads fall back to a whole-map stamp; so does a frame where most
blocks are dirty. Per-frame cost tracks *how much changed*, not *how
many posts exist*, and scattered fronts (e.g. opposite corners) become
independent small block draws.
### Territory-fill darkening
The coverage texture marks every same-owner in-range tile (interior
included, not just borders), so `TerritoryPass` now also samples it to
darken the territory **fill** around posts. New tunable
`mapOverlay.territoryDefenseDarken` (live-editable in the graphics debug
GUI alongside `defenseCheckerDarken`).
### Performance
Tested with ~1,000 posts blanketing a map — smooth, including on a
low-end (~10-year-old) Chromebook.
## Files
- **New:** `passes/DefenseCoveragePass.ts`,
`shaders/defense-coverage/defense-coverage.{vert,frag}.glsl`
- **Edited:** `Renderer.ts`, `BorderStampPass.ts`,
`BorderComputePass.ts`, `BorderScatterPass.ts`, `TerritoryPass.ts`,
`border-stamp.frag.glsl`, `border-compute.frag.glsl`,
`territory.frag.glsl`, `RenderSettings.ts`, `render-settings.json`,
`debug/Layout.ts`
## Notes
- No user-facing text (no `translateText`/`en.json` changes needed).
- No `src/core` changes — purely client rendering, so no simulation
tests; verified via `tsc`, ESLint, `build-prod`, and in-game.
|
||
|
Evan
|
075547b7b6 |
Incremental GPU scatter recompute for tile borders (#4166)
## Description: Incremental GPU border recompute — sequel to #4159. On 10 yo low-end chrome book this increased performance by ~5fps. I'm now able to get 40fps on GWM. `BorderComputePass` previously re-ran its fragment shader over every tile on the map every time any input changed (tile flip, highlight, relation, defense post). Cost was O(mapW × mapH) per invalidation, and tile flips invalidate it ~every render frame in live play. This PR adds `BorderScatterPass`, which runs the same fragment shader but rasterizes only one POINT per dirty tile (plus its 4 cardinal neighbors, to cover the cardinal-neighbor read in the border shader). Cost is O(dirty tiles) regardless of map size or spatial distribution. ### What changed - New `BorderScatterPass` — owns its own FBO, VAO, and instance buffer; shares the border fragment shader with `BorderComputePass` so the two paths can't diverge in output. - `BorderComputePass.draw()` now picks per frame: - **Full recompute** — when `globalDirty` is set by highlight / relation / defense-post changes (those affect tiles across the whole map). - **Scatter** — when only per-tile patches have been queued via `patchTile()`. - `TerritoryPass.flushTileTexture()` now returns `"none" | "full" | "scatter"` instead of `boolean`, so the renderer can pick the right downstream invalidation: - `"full"` → `borderPass.markGlobalDirty()` (full tile upload supersedes per-tile patches). - `"scatter"` → no-op; per-tile patches were already pushed via the wired `borderPatchConsumer` callback during drip drain. - Renderer wires `territoryPass.setBorderPatchConsumer((x, y) => borderPass.patchTile(x, y))` so every per-tile scatter write to `tileTex` also schedules an incremental border recompute for that tile + its neighbors. ### Known limitation Highlight-thicken rings (within `uHighlightThicken` of a changed tile) are NOT incrementally repainted — they'll lag visually until the next full recompute. In practice this is short-lived (the next highlight change or seek triggers a full recompute) and not visible during normal play; the trade is documented in the `BorderScatterPass` header. ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
Evan
|
d1ce199a52 |
Upload tile delta to GPU (#4159)
## Description Reduces the amount of tile data sent to the gpu each tick, roughly ~10fps rate increase on 10 year old chromebook. Two changes to the territory rendering path: ### 1. Split `passEnabled.mapOverlay` into four flags The single `mapOverlay` toggle controlled four unrelated passes (territory fill, border compute, border stamp, trail). Splits it into `territory`, `borderCompute`, `borderStamp`, `trail` so each can be toggled independently in the debug GUI. Pure rename — default behavior is unchanged (all four default to `true`). ### 2. GPU scatter for per-frame tile texture updates Replaces the dirty-row bbox `texSubImage2D` upload in `TerritoryPass` with a new `TileScatterPass` that uploads a small attribute buffer of `(x, y, state)` patches and runs a single `POINTS` draw into an FBO bound to `tileTex`. Each patch rasterizes as a 1×1 point into exactly its target texel. **Why:** the old path's cost scaled with the bounding box of the dirty rows, not the number of changed tiles. In typical play, tile changes are spread across the whole map (multiple players fighting in different regions, scattered trails/fallout), so the bbox covered most of the map's rows and we re-uploaded mostly-unchanged data every frame. The new path is constant cost in patch count regardless of spatial distribution, and no longer scales with map size. The full-upload path (initial load / seek / spawn-phase flush) is unchanged. `fullUploadPending` correctly supersedes any queued scatter patches. ## Please complete the following: - [x] I have added screenshots for all UI updates *(N/A — no UI changes)* - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file *(N/A — no user-facing text)* - [x] I have added relevant tests to the test directory *(renderer code, not covered by unit tests; verified visually)* ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
evanpelle
|
431f22ac94 | Always render player name when under the cursor | ||
|
Evan
|
f1045a2022 |
Update & refactor dark mode (#4114)
## Description: - The renderer no longer knows what "dark mode" is. `RenderSettings.dayNight.mode` (`"light" | "dark"`) is gone — passes read neutral values (`lighting.ambient: number`, `lighting.enabled: boolean`). - `render-settings.json` holds the light-mode baseline. Dark mode is just another override layer, applied the same way as graphics settings (`darkNames`, `classicIcons`, etc.). - New `src/client/render/gl/RenderOverrides.ts` exposes two in-place mutators with matching shapes: - `applyGraphicsOverrides(settings, overrides)` — replaces the old `generateRenderSettings` - `applyDarkModeOverride(settings, isDark)` - `ClientGameRunner` regenerates the live settings each time the user setting changes via `deepAssign(live, createRenderSettings())` + the override chain. No per-slice copy list, no intermediate object — adding a new override that touches a new section just works. - Renamed `dayNight` → `lighting`; collapsed `nightAmbient`/`dayAmbient` into single `ambient`; renamed `enableLightCompositing` → `enabled`. - Bumped dark-mode ambient from 0.15 → 0.35 so terrain stays readable. <img width="1250" height="846" alt="Screenshot 2026-06-02 at 11 47 28 AM" src="https://github.com/user-attachments/assets/b41e8ffb-6011-4ba0-9e1f-c2a21ff90794" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
noahschmal
|
2c8a66625c |
Feature/Move theme system from core to client-side ThemeProvider (#4108)
**Add approved & assigned issue number here:** Resolves #2549 ## Description: Themes are purely for the client's rendering, and the server doesn't need context on them. This PR moves `Theme.ts` from `src/core/configuration` to `src/client/theme` and moves affiliation colors to `render-settings.json`. This is to support the ability to add additional themes more quickly, such as colorblind-friendly themes. No visible changes occur from this refactor. ## Please complete the following: - [X] I have added screenshots for all UI updates - [X] I process any text displayed to the user through translateText() and I've added it to the en.json file - [X] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: jetaviz --------- Co-authored-by: Josh Harris <josh@wickedsick.com> |
||
|
evanpelle
|
475a7ab8af |
bugfix: port construction bar completes early; renderer now reads durations from Config
The renderer kept a parallel CONSTRUCTION_DURATIONS table in src/client/render/GameConstants.ts that had drifted from Config: port showed as 20 ticks but the simulation builds it in 50, so the bar hit 100% and idled for 30 ticks. SAM/silo cooldown constants were also stale (120/75 vs Config's 90/90), making the missile-readiness bar slightly wrong too. Delete GameConstants.ts entirely. Thread the Config instance through WebGLGameView → GPURenderer → BarPass / FxPass / FxSpritePass / WorldTextPass; passes call config.unitInfo(...).constructionDuration, config.SAMCooldown(), config.deletionMarkDuration(), config.msPerTick() directly. Add Config.msPerTick() since no method existed for it. Move the visual-only NUKE_EXPLOSION_RADII (not a game-logic value) into FxSpritePass where it's used. |
||
|
Evan
|
aa3959bffe |
feat: territory png based skins (#4006)
## Description: Add image-based territory skins as a new cosmetic type, rendered alongside the existing 1-bit patterns. Skins render a single PNG centered on each player's spawn tile — opaque pixels show the skin (multiplied by team color in team games, raw colors in FFA), transparent pixels and tiles outside the image bounds fall through to the regular player palette color. **Cosmetic plumbing** - `SkinSchema` in `CosmeticSchemas.ts`, optional `skins` map on `CosmeticsSchema` - `PlayerSkin`, `PlayerCosmetics.skin`, `PlayerCosmeticRefs.skinName` in `Schemas.ts` - Server-side resolution: `PrivilegeCheckerImpl.isSkinAllowed` (gated by `skin:*` / `skin:<name>` flares) - Client persistence: stored under `PATTERN_KEY` (`pattern:` and `skin:` share one slot — they're mutually exclusive) - `getPlayerCosmeticsRefs` only emits a `skinName` when cosmetics are loaded, the skin exists in the catalog, and the user has the right flare — otherwise drops the ref and clears storage **Renderer** - `SkinAtlasArray` — fixed `TEXTURE_2D_ARRAY`, 1024×1024 per layer, exact layer count allocated once at game start from the locked-in player set. No resize, no callbacks, no retained `HTMLImageElement`. Zero GPU cost when no players have skins (1×1 placeholder). - `skinLayerTex` (R8UI 4096×1) — per-player `layer + 1` (`0` = no skin) - `skinAnchorTex` (RG16UI 4096×1) — per-player spawn tile, so the PNG center anchors at each player's spawn (re-uploads when the player re-picks during spawn phase) - `WebGLFrameBuilder.syncPlayers` collects unique skin URLs on first sync and calls `view.initSkinAtlas(urls)` once; `clearCaches()` resets so seek/replay re-initializes - `territory.frag.glsl`: skin branch is mutually exclusive with patterns; bounds-checks UVs against `[0, 1]` so the image is a single stamp, not tiled; alpha-blends against the player palette color so transparent pixels and out-of-bounds tiles render as the regular player color **Hover highlight (global UX change, not skin-scoped)** - Existing hover highlight changed from "brighten toward white" to "saturation boost." Applies to all players regardless of skin/pattern/flat-color — looks better across the board. **UI** - `CosmeticButton` renders skins as a single `<img>` (object-contain) - `TerritoryPatternsModal` merges patterns + skins into one grid; single "default" tile clears both - Selecting a pattern clears the skin and vice versa (mutually exclusive) - `Store` pattern tab includes skin entries (purchasable, not-yet-owned) - `PatternInput` lobby button previews the active skin when one is set **Memory** - 0 skin players → ~4 bytes (placeholder) + ~40 KB fixed per-player tables - 1 skin player → ~5.6 MB GPU - 5 skin players → ~28 MB GPU - 10 skin players → ~56 MB GPU **Tests** - `tests/Privilege.test.ts`: 13 new cases covering `isSkinAllowed` (wildcard, exact-match, missing flare, missing skin, forged refs) and `isAllowed` integration (allowed/forbidden paths, short-circuit when invalid skin is paired with valid other cosmetics) ## Please complete the following: - [ ] I have added screenshots for all UI updates - [ ] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory - [ ] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
Evan
|
b4a14f9b9d |
Move attack troop overlay to WebGL (#3996)
## Description: Replaces the DOM-based `AttackingTroopsOverlay` with `AttackingTroopsController`, rendering attack troop counts through `WorldTextPass` instead of a separate fixed-position DOM container. ## Summary - New `AttackingTroopsController` polls `attackClusteredPositions()` every 200ms and pushes labels to the WebGL view each frame, lerping cluster positions over 250ms for smooth front-line movement (replaces the old CSS `transform 0.25s` transition). - `WorldTextPass` gains `setAttackTroopLabels()` and renders them at a fixed on-screen size (zoom-independent) using `screenScale / zoom`. - World text now draws on top of `NamePass` so attack callouts aren't hidden behind centered player names. - Fragment shader adds a soft quadratic dark halo around every world-text label; extent uses the remaining SDF range after the hard outline so it fades smoothly to zero (no rectangular clipping). - Deletes `AttackingTroopsOverlay.ts`; existing unit tests repointed to the controller's exported `alignClusterOrder`. <img width="369" height="395" alt="Screenshot 2026-05-24 at 4 43 51 PM" src="https://github.com/user-attachments/assets/4dbffe20-77f9-4c0f-b956-ecf543538f8d" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory - [x] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
evanpelle
|
b486caa6f4 |
Wire view-mode toggles (alt-view + coordinate grid) via new ViewModeController
Moves the AlternateViewEvent / ToggleCoordinateGridEvent subscriptions out of ClientGameRunner into a dedicated controller in src/client/controllers/. Also wires ToggleCoordinateGridEvent (M keybind) — previously emitted with no listener — so the persistent coordinate-grid toggle works. Grid + alt-view hide names only under alt-view; M keeps names visible. |
||
|
Evan
|
ee04a19d3c |
unit price (#3989)
## Description: # Ghost structure cost label Renders the gold cost of the currently-selected build under the ghost structure cursor, with color-coded affordability/placement state. Honors the existing `cursorCostLabel` user setting (legacy name `ghostPricePill`, already shipping ON by default). ## Behavior | State | Color | |---|---| | Can afford + valid placement | white | | Can afford + can't place here (port on land, overlap, …) | gray | | Can't afford | red | The number is formatted via `renderNumber` (project-wide convention — `1.5K`, `1.23M`, etc.) and rendered as MSDF text at a fixed world-space scale, centered under the ghost icon. ## Implementation The cost was already plumbed end-to-end on [`GhostPreviewData.cost`](src/client/render/types/Renderer.ts) but never visualized. This PR: - Extends [`GhostPreviewData`](src/client/render/types/Renderer.ts) with `showCost` (from setting) and `canAfford` (gold vs. cost check, computed in [BuildPreviewController](src/client/controllers/BuildPreviewController.ts)). - Adds a `setGhostCostLabel(...)` channel to the MSDF text pass — one persistent, non-animated text instance alongside the existing ephemeral popups. No new pass, no new shader. - Wires [`Renderer.updateGhostPreview`](src/client/render/gl/Renderer.ts) to push the label whenever a ghost is active. - Renames `ConquestPopupPass` → [`WorldTextPass`](src/client/render/gl/passes/WorldTextPass.ts) (and its shader dir `conquest-popup/` → `world-text/`) since it now handles conquest popups, bonus popups, and the ghost cost label. Done with `git mv` so history is preserved. https://github.com/user-attachments/assets/c5b21bf3-f440-4c28-9b94-843df9bf6a37 ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory - [x] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
Evan
|
fe6581e3fe |
update webgl nuke effects (#3984)
## Description: Reworks the visual look of nuked tiles to read uniformly green (no more brown/black bleed-through), and moves the ember "particle" effect out of the border passes — where it lived as a storage-sharing hack — into the fallout system where it belongs. ## What changed visually - **Fresh fallout**: bright uniform bloom with a hint of flickering green particles dampened on fresh tiles, ramping up as heat decays (`particleFreshScale` controls the fresh-tile dampening). - **Stale fallout**: dark-green ground (was near-black charcoal), with full-strength flickering particles in dark-green ↔ light-green. - **Particles**: per-tile flicker is now de-synced (each tile pulses at its own rate, 0.4×–1.6× base speed) so the eye can't lock onto a global rhythm. - **No more brown/black pixels** in fallout zones. Two root causes were fixed: - The territory pass now renders stale-nuke ground for **all** fallout tiles, not just unowned ones — so an owned player's color can't show through where the bloom is dim/transparent. - The ember stamp (which fully replaced tile color with orange) is gone; particle render is now additive and color-tuned green. ## Architecture cleanup The ember effect was conceptually fallout-domain, but lived in `BorderComputePass` (writing intensity into `borderTex.g`) and `BorderStampPass` (stamping orange dots), just because the border pass already had an RGBA8 texture with a free G channel. Two consumers read from it (`BorderStampPass`, `FalloutLightPass`), and the per-tile flicker math used no border data at all. This PR relocates the math inline into the two passes that actually need it (`FalloutBloomPass.extract.frag.glsl` and `FalloutLightPass.fallout-light.frag.glsl`), drops the ember code from both border passes, and renames `mapOverlay.ember*` → `falloutBloom.particle*` so the settings live with their pass. Side benefits: - **Animation correctness**: the old setup only updated ember intensity when `BorderComputePass`'s dirty flag flipped (highlight change, relations update, etc.), so the supposed flicker was actually a frozen snapshot between border events. The new inline path runs every frame as intended. - **Slightly cheaper per-frame compute**: removed a per-dirty-event full-map writeback to `borderTex.g`; added a few cheap ALU ops (1 sin + 2 hashes) per fallout tile in shaders that were already running. Same texture memory. ## Other small changes - Renamed `mapOverlay.charcoal*` → `mapOverlay.staleNuke*` (charcoal was a misnomer now that the ground is green). - Added `staleNukeR/G/B` for the ground color (was hardcoded grey). - `intensityHot` bumped 0.6 → 1.8 for a brighter fresh-nuke glow. - Raised `railroad.railMinZoom` 2 → 4 and `railDetailZoom` 4 → 6 so rails pop in later (separate small commit). <img width="354" height="371" alt="Screenshot 2026-05-22 at 10 37 34 AM" src="https://github.com/user-attachments/assets/03b46c45-c617-41b3-b3e4-9934f064bfe1" /> <img width="335" height="358" alt="Screenshot 2026-05-22 at 10 37 43 AM" src="https://github.com/user-attachments/assets/af370b19-8f22-4694-9859-1ad52aa755a7" /> <img width="651" height="613" alt="Screenshot 2026-05-22 at 10 38 09 AM" src="https://github.com/user-attachments/assets/e06e5101-8529-49f6-b29a-ce0563eb52d6" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory - [x] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
Evan
|
c82b078dab |
Stagger territory tile rendering across frames (#3973)
relates to #893 ## Description: Territory updates were uploaded in one shot per game tick, producing a 10 Hz tile update which looked choppy. This change drips each tick's tile changes across the ~6 render frames between ticks so the fill flows continuously instead of stepping. Inside TerritoryPass, each changed tile is hashed by ref into one of N buckets (configurable via tileDrip.bucketCount, set to 9 — gives ~50 ms of jitter headroom over the tick period without making attacks feel laggy). One bucket drains per render frame. The stable per-ref hash keeps repeated updates to the same tile in arrival order, so the latest owner always wins. While in there, moved trail state ownership out of TerritoryPass and into TrailPass where it belongs — the territory shader doesn't sample trailTex, so the colocation was just code-reuse drift. ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory - [x] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: evan |
||
|
VariableVince
|
ed928db081 |
Display territory skins again (#3966)
## Description: Display territory skins (patterns) again. ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory - [x] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: tryout33 |
||
|
evanpelle
|
1dd00f6264 |
push terrain deltas to the WebGL view so water nukes show
Terrain was uploaded once at game start and treated as static — water nukes (land → water conversion) mutated the sim's terrain bytes but the rendered terrain stayed dry. Plumbed a delta path: TerrainPass and RailroadPass each get applyTerrainDelta(refs, bytes), Renderer + GameView forward, and WebGLFrameBuilder pushes each tick from gameView.recentlyUpdatedTerrainTiles(). Per-tile encoding is shared via the new encodeTerrainTile helper in ColorUtils so the startup full-map build and the per-tile delta updates can't drift. |
||
|
evanpelle
|
4cd22a9b5c |
rename render/ files to UpperCamelCase to match client convention
The render/ tree was the only place in the client still using kebab-case filenames. Brings ~80 files in line with the rest of src/client/ (BuildPreviewController, TransformHandler, etc.). Directories kept as they were (name-pass/, fx-pass/, passes/, utils/, debug/) since the codebase already mixes those. Two collisions surfaced and got resolved: render/types/ is a directory, not a file, so its imports kept the lowercase form; and the sed pass incidentally normalized core/pathfinding imports, which had to be reverted since that file is actually lowercase on disk despite some imports having referenced it as ./Types under macOS case-insensitive resolution. |