DEV Community: Denshin Team

Building a Neon City Map in PixiJS: Layers, Fog and Traffic

Denshin Team — Wed, 04 Nov 2026 05:55:21 +0000

Originally published on the DENSHIN blog.

A street name belongs on the asphalt. Cars should drive over it. A quest marker needs to stay readable while the street underneath it is sealed. Those are small visual decisions, but they determine whether a player can understand a city at a glance.

Our map runs in PixiJS in the browser. It combines illustrated quarter art, road geometry, moving traffic, atmosphere and clickable markers. Each piece has its own job, and the order in which we draw those pieces is part of the game design. This is a tour of that order, from the street surface to the camera looking down on it.

Start with a world that moves together

The map's layers sit inside one world container. Panning changes the world's position; zooming changes its scale. Roads, blocks and cars therefore stay in the same coordinate system while the view moves around them.

That sounds ordinary until a visual element ends up outside the arrangement. A label that moves differently from the road looks attached to the screen. A glow that loses its relationship to a building looks like a floating effect. Keeping the city together gives us a stable place to decide what each object should cover.

The interface has a different job. A button needs to remain usable as the player drags the map underneath it. We keep that distinction clear: the world is the place being explored, and the interface is how the player chooses what to do there.

Draw the street before its movement

We begin with the ground and the road markings. Quarter surfaces and their artwork establish the blocks. Street labels sit above the surfaces, followed by road effects and traffic. Neon light, building elements and the elevated expressways complete the visible city below the lock treatment.

The street labels are a useful example. We place them below traffic so a car passes over a painted name. Moving those names higher would make them easier to read in isolation, but it would also make them float above every car. Their position in the stack gives the viewer a clue about what they are.

The same reasoning applies to light. A road marking needs to feel like paint under the city's night lighting. Its colour belongs to the scene around it. When every bright surface competes equally for attention, it becomes harder to distinguish a street detail from something the player can click.

A sealed quarter needs a coherent silhouette

Our lock treatment sits above the quarter art, traffic, neon and buildings. That placement lets the whole area read as sealed. Bright windows or an expressway shining over the treatment would weaken that signal.

Quest banners sit above it. They are the route into the task, so the player needs to see where a quest is and inspect its status. Each banner carries its own visual lock state. A sealed region can therefore remain readable without exposing the city underneath as though it were open.

This also keeps the renderers' responsibilities manageable. The layer order decides which scenery the treatment covers. A road renderer can concentrate on roads, while the quest marker handles the status the player needs to understand. Changing the meaning of the lock is a deliberate change to the composition.

Distance changes the atmosphere

There are two kinds of fog in the scene. Local road atmosphere belongs with the road effects. A separate city-wide overlay sits above the world and responds to camera zoom.

At a wider view, the overlay contributes more haze. As the player moves closer, it becomes transparent and the quarter details come forward. The camera distance therefore changes the amount of atmosphere between the player and the city.

The update follows the camera scale. When the calculated opacity is unchanged, we leave it alone. That small rule reflects a broader habit in a scene with many moving parts: an effect should update the state it actually needs, at the moment it needs it.

Traffic has a street system underneath it

The cars follow lanes, approach intersections, wait at lights and turn. Those behaviours give the movement a relationship to the road layout. The traffic system also checks the viewport so vehicles outside the visible area do not all need to be drawn.

Rendering and movement have separate concerns here. A car can leave the picture while its simulation continues. When the camera reaches that road again, the traffic still belongs to the same street system. Nearby off-screen space gives the renderer room to prepare for what will enter the view.

Animated systems also have a lifecycle. They register updates with the ticker and remove those updates when the system is destroyed. A map that opens, changes and closes needs that cleanup just as much as it needs the animation itself.

Let the artwork arrive around the camera

Illustrated block art does not all have to arrive before the first useful frame. Our streamer prioritises the visible area, orders pending blocks by distance and limits concurrent loads. The rest of the city fills in behind that first view.

We covered the loading work and its measurements in our earlier PixiJS performance article. Here the visual consequence matters: the player should be able to read the street layout while the richer artwork arrives. Loading order is another form of visual priority.

Read the city as one composition

When we review the map, we look for relationships: labels under cars, markers above sealed areas, atmosphere that follows distance, and lights that sit inside the scene. A screenshot can reveal a misplaced layer. Dragging and zooming reveal whether the same arrangement holds together in motion.

The image above is a fresh capture from the running city, with the interface outside the frame. Open the live map and move between the streets and the quarter view. The artwork gives each block its character; the layers, movement and camera make those blocks work as a place to explore.

How We Took a PixiJS Map From 33.9 s to 3.0 s on a Slow Phone

Denshin Team — Thu, 24 Sep 2026 16:20:04 +0000

Originally published on blog.denshin.io.

Our team builds DENSHIN, a game whose main screen is a live city map drawn with PixiJS v8: a 10 × 10 grid of city blocks, road markings, traffic, planes and other players moving in real time. Players complete on-chain quests to open parts of the city, and none of that matters for what follows.

On 29 July we loaded a production build with the network throttled to 1.6 Mbps and the CPU slowed 6x. The loading overlay said RENDERING MAP for 33.9 seconds. By the evening it said so for 3.0 seconds, with the same city behind it. This post covers what we moved, in what order, and the phone crashes from earlier in the summer that shaped the loader.

Production build, 1.6 Mbps, CPU 6x	Before	After
"RENDERING MAP" on screen	33.9 s	3.0 s
Total time until the map is up	38.7 s	7.8 s
Bytes before the first frame	6.9 MB	1.0 MB

The first frame waited for 196 MB of pictures

Earlier that day, against production, the map took 35.7 s to appear and pulled 203.7 MB in 309 requests. 196.1 MB of it was 62 PNGs: the art painted into each block. All 62 sat inside the Assets.load() that GameApp.init() awaits before the overlay lifts. On home Wi-Fi that was about a minute.

Two fixes:

Encode for the size you draw. A block is 18 grid cells of 64 px, so 1152 world pixels, and the camera never zooms past 1:1. The masters were PNGs of up to 1254 px, and not one pixel in any of them was transparent. Re-encoded as WebP, capped at 1152 px and with no alpha channel, the set is 16.6 MB, 11.8x smaller. Phones get a 512 px set of 4.6 MB.
Take them out of the awaited list. The category is registered with Assets but not enrolled in the bulk load:

// null: registered, but not in the list loadAll() awaits
this.registerGlob(
  lowPower ? buildingMobileUrlMap : buildingUrlMap,
  ASSET_CATEGORY.BUILDING,
  null,
  lowPower ? undefined : { autoGenerateMipmaps: true },
)

Every block is now drawn at once from one shared 494-byte blurred placeholder, and the real images stream in over it. The first frame dropped to 7.4 MB and 223 requests, with no block art at all.

The rest of the awaited list was decoration too

On a 1.6 Mbps link, the 6.9 MB still behind the overlay is about 34 seconds of pure transfer. The render pipeline took 410 ms of the total, even at 6x CPU. We were bandwidth-bound, so the fix was to ask for fewer bytes, not to render faster.

Here is what the first frame was waiting for:

What	Size	Needed at first paint?
Road markings and overlays	324 KB	Yes
A rectangular block set	984 KB	No. Its only renderer was switched off
Cracks, stains, litter	2.7 MB	No. Phones never draw them
Cars, planes, manhole covers	2.4 MB	Can arrive a second later

Two rows need a note. Phones downloaded 2.7 MB of debris for renderers that are disabled on phones. And the rectangular set was pulled in by a glob for a code path behind a disabled flag. That one is a Vite trap: an eager import.meta.glob is rewritten into real imports before dead-code elimination runs, so its files ship whether or not anything can reach them. The same pattern had put 337 files, 70 MB, of another unused block set into dist. A build flag can't fix that. The glob has to go.

The manhole covers were a smaller case of the same thing: 1.32 MB of roughly 1000 px art for sprites drawn at 6–9 px. We deleted them.

The awaited list is now two placeholders plus the markings and road overlays, 324 KB in total. That's what took RENDERING MAP from 33.9 s to 3.0 s.

Four waves that never overlap

Moving everything to "later" created a new problem: everything arrived later at the same time. The block art (about 17 MB on desktop, 4.6 MB on a phone) started downloading together with 1.1 MB of cars and planes and took their bandwidth. At 1.6 Mbps, traffic finished at 21.8 s. Until then players looked at empty streets and blurred blocks, and they read the blur as locked content.

Now the boot runs in four waves, and each one starts only after the previous one has landed:

1. loadAll()         324 KB  -> the city is drawn
2. loadDeferred()    1.1 MB  -> cars, planes, players
3. startStreaming()  block art, nearest first
4. loadTrim()        2.7 MB  -> asphalt debris (desktop)

With the same throttling, traffic now finishes at 11.7 s instead of 21.8 s, and the first wave is untouched. The chain lives in one method, and init() does not await it:

private populate(pipeline: RenderPipeline): void {
  this.populated = new Promise<void>((resolve) => {
    requestAnimationFrame(() => requestAnimationFrame(() => {
      AssetLoader.loadDeferred()
        .then(() => {
          if (!this.alive()) return
          const late = pipeline.renderDeferredLayers()
          this.trafficSystem = late.trafficSystem
          // ...quests, other players, planes
        })
        .catch(() => undefined)
        .then(() => this.streamArt())
        .then(() => this.trim(pipeline))
        .catch(() => undefined)
        .finally(resolve)
    }))
  })
}

Three details in there each came from a bug:

Two animation frames, not one. One frame only queues the paint. The second makes sure the city was actually presented before the main thread gets busy again.
alive() checks. A wave can land after the player has left the page.
A 45-second deadline on the art wave. A block that never arrives must not hold back the wave behind it. Failures are swallowed, because every wave only adds to the city. A city without planes still works.

Nearest the player first

The streamer used to walk blocks in city order. The top-left corner sharpened first while the block under the player stayed a blur. Now every scan (one per 140 ms) sorts pending blocks by distance to the centre of the screen, which is where the opening camera puts the player:

const candidates = this.pending
  .filter((item) => item.state === 'idle')
  .filter((item) => !viewportOnly
    || isInViewport(bounds, item.target.cx, item.target.cy))
  .sort((a, b) => distanceSq(a, centre) - distanceSq(b, centre))

Sorting about a hundred items that often costs nothing next to one texture upload, and after a pan it follows the camera without any extra bookkeeping. At most 4 loads run at once on desktop and 2 on phones, because more than that makes decode and upload stutter the frame. After 2.5 s the viewport filter drops and the rest of the city fills in, outward from the centre.

Crash: `Assets.unload` and the null `alphaMode`

That streamer only loads. It never unloads, and that's a deliberate rule.

In June an earlier block streamer freed GPU memory by calling Assets.unload() on blocks that left the screen. unload destroys the texture's GPU source. When the player panned back, Assets.load() for the same alias handed back the same cached texture object, which now had no source. A live sprite still held it, and the batcher crashed with Cannot read properties of null (reading 'alphaMode'). It never reproduced on localhost, because it needed real latency and memory pressure. Running load and unload one at a time didn't help: the cache reuse itself was the trap.

We removed eviction entirely. Memory is now bounded by texture size and count: one district, a fixed set of images, and smaller files on phones. The loader also refuses to hand out a dead texture:

const source = texture?.source
if (!source || source.destroyed) return undefined

Crash: a world-sized RenderTexture is 0.8 GB

That same June day, phones killed the tab right after RENDERING MAP. There was no JavaScript error, just iOS WebKit running out of memory. Three decorative renderers (neon reflections, road debris, neon glow) each baked into a RenderTexture the size of the whole world, about 14848 × 14848 px. At 4 bytes a pixel that's roughly 0.8 GB of GPU memory each, and about 2.5 GB for all three. A desktop GPU absorbs that. A phone can't.

// Each bakes a world-sized (~14848²) RenderTexture, ~0.8 GB apiece.
const heavyEffects = !isLowPowerDevice()
if (heavyEffects) {
  this.renderNeonReflections()
  this.renderNeonGlow()
}

On phones the block surface that desktop bakes is drawn as live masked sprites instead. Our rule now: before any render target ships, multiply width × height × 4.

The device tier answers a memory question, nothing else

The tier check itself is small:

export function isLowPowerDevice(): boolean {
  const nav: Navigator & { deviceMemory?: number } = navigator
  const mem = typeof nav.deviceMemory === 'number'
    ? nav.deviceMemory : undefined
  const coarse = matchMedia('(pointer: coarse)').matches
  const minSide = Math.min(screen.width, screen.height)
  return (mem !== undefined && mem <= 4) || (coarse && minSide < 820)
}

Every phone trips it, fast ones included. That's fine for what it decides: 512 px block art instead of 1152 px, no mipmaps, a lower zoom cap to match, and no world-sized bakes.

Twice we used it for more than that. First we turned headlight beams off on phones, and later the whole locked-block treatment (haze and blur). Both times the phone quietly lost something the desktop had, and both times it was reported as a bug. Now the tier can make the pictures lighter, but it can't change what the map shows.

Frame time is a separate budget and gets its own answer. We measured the beams under mobile emulation, interleaving the runs because the test rig drifted by up to 2x between batches. At 4x CPU the p95 frame went from 18.5 ms to about 32 ms with beams on. At 1x there was no cost at all. We kept the beams.

The locked-block effects step down only when the median frame stays above 24 ms for 3 seconds. The first version triggered on p95 above 14 ms. A healthy session runs at p50 16.7 ms and p95 17.6 ms, so that ladder fired in every session: by second 26, only a flat fill was left. The median tells you a device can't keep up. The tail only tells you that frames sometimes spike.

Eight canvases on one landing page

Our landing page showed eight live fragments of the map, which meant eight WebGL contexts. On an emulated iPhone 13, one scroll down and back up created 51 contexts and took the JS heap to 254 MB, which is where iOS starts killing tabs. Now only the hero is live. The other seven are stills baked in a headless browser by the same renderer from the same seed. The only visible difference is that the cars have stopped. The same scroll now creates 3 contexts.

Bugs that looked like slow loading

A late mipmap flag. We set autoGenerateMipmaps on a texture after Assets.load resolved, which forced a full re-upload of a live 1152² texture. That upload didn't fit in one frame, so blocks grew in from the top-left corner. Upload options now go in with the source, in Assets.add({ alias, src, data }).
A clipped blur. While panning, locked blocks drew half-empty and healed after about 10 seconds, which looked exactly like slow streaming. The real cause was a blur filter at 0.5 resolution with no filterArea: PixiJS took the region from the object's bounds and cut off the bottom fifth. An explicit filterArea fixed it. We found it by comparing sprite bounds in a live dev session and switching mask, overlay and blur off one at a time.

What we check now

The awaited load holds only what the first frame can't be drawn without. Every byte added there is paid by every player on every visit.
We measure on a production build with network and CPU throttled. Localhost hides both the bandwidth math and the GPU memory race.
Waves are ordered by what the player notices, and they never overlap.
Textures stay resident. Memory is bounded by size and count, not by eviction.
Every render target gets its width × height × 4 before it ships.
The device tier picks asset sizes. Measured frame time decides which effects run.

The map is live at app.denshin.io and opens for guests with no sign-in. It's a good test case for DevTools throttling.

We built a Web3 quest game where the progress bar is a city

Denshin Team — Mon, 21 Sep 2026 19:49:48 +0000

Most Web3 quest platforms look the same: a list of tasks, a checkbox per task, a points counter. You swap, you tick, you forget. We wanted progress you can actually see, so in Denshin the progress bar is a city.

Denshin went live on September 10 with its first season, Genesis, and launches on Product Hunt on September 22. Here is how it's built, and a few decisions that turned out to matter.

The idea in one paragraph

The map is one district of 100 quarters, and four of them are open at the start. Each quest belongs to a quarter: complete it and the quarter opens. The Genesis season has 33 quests across Base, Soneium and Sonic, and 23 of them are verified straight from the chain: holding gas, holding a stablecoin, swapping on a named DEX, supplying to a lending market, providing liquidity. There is no token and there are no NFTs. The prize pool is $100 USDT for the top 50 of the season, small on purpose: the game has to be worth playing on its own.

Drawing the city with PixiJS

The UI is Vue 3 and the map is PixiJS. The map is a stack of containers, bottom to top:

baseFill → roadWear → grid → roadMarkings → roadEffects (traffic)
→ neonGlow → buildings → players → aircraft → clouds → fog

Two kinds of renderers draw into it:

Stateless renderers (road markings, wear, neon glow, buildings) create their display objects once and are done.
Animated systems (traffic, pedestrians, aircraft, clouds, fog) register a ticker callback and hold state. Every one of them has an init(layer, ticker) / destroy(ticker) pair, and forgetting the second half is the fastest way to leak.

Every procedural detail, from the stains on the asphalt to which cars drive which lanes, comes from a seeded PRNG (mulberry32) with one seed per renderer. The city looks the same for every player and on every reload, which also makes visual bugs reproducible.

Two performance lessons:

Bake on desktop, not on phones. On desktop the quarter art is baked into one world-sized RenderTexture, which makes panning cheap. On phones that one texture runs the GPU out of memory, so mobile keeps live sprites and a lighter 512px WebP set.
Atlas the small stuff. Road markings and vehicles ship as committed spritesheets instead of hundreds of separate PNGs.

Verifying quests from the chain

No screenshots, no "paste your tx hash". Every on-chain quest check asks the chain one of three questions:

Check	Question
Native balance	Do you hold at least X of the gas token on chain N?
Token balance	Do you hold at least X of a specific ERC-20?
Swap	Did you swap at least X on an approved venue since you started the quest?

Three rules make this hard to game:

Accepted-at block. Action checks only look at blocks after the moment you pressed Start mission. Otherwise "did you swap on Base" would pay for any swap in the wallet's history.
One transaction, one reward, ever. An accepted tx hash is consumed: stored once, behind a uniqueness constraint on the hash itself. It can't close two tasks, the same task twice, or a task on another account.
The server picks the hash. The hash comes from the verifier's own read of the chain, never from the browser, so a client can't nominate one it likes.

Swaps are matched against a registry of known pools and routers per network, so "a swap on Kyo" means Kyo, not any contract that happens to emit a Swap event.

Putting the daily check-in on-chain

Until this week the Daily Check was an off-chain button. Now it is a transaction: sync() on a tiny contract called DenshinSync, deployed at the same address on Soneium, Base and Sonic.

function sync() external returns (uint32 streak) {
    uint32 day = today(); // block.timestamp / 1 days
    Record memory record = _records[msg.sender];
    if (record.lastDay >= day) revert AlreadySynced(msg.sender, day);

    streak = record.lastDay + 1 == day ? record.streak + 1 : 1;
    // ...store lastDay, streak, longest, total
    emit Synced(msg.sender, day, streak, total);
}

It holds no funds, has no owner and no admin functions, and cannot be upgraded. The day is the block's UTC day, not the player's clock. The streak that pays points is computed off-chain from Synced events, so a player can sync on Base one day and on Sonic the next without breaking it.

The identical address on three chains comes from a deterministic CREATE2 deployment. A side effect we didn't expect to care about: changing even a comment in the source changes the bytecode metadata, and with it the address.

For the player it costs gas only, a fraction of a cent. The contract is 0xCCFFb22048d9E1fDd04F5F3B9681cC0C95a0f654, source verified on each chain's explorer.

Stack

Client: Vue 3, PixiJS, viem/wagmi, Reown AppKit
Server: NestJS, PostgreSQL, Redis, BullMQ
Contract: Solidity, Hardhat

Try it

The map and the quests are visible without a wallet: https://app.denshin.io. Docs: https://docs.denshin.io.

We launch on Product Hunt on September 22. If you have thoughts on the map, the verification rules or the on-chain check-in, that is the best place to leave them: https://www.producthunt.com/products/denshin

We're a small team, so honest feedback is the most useful thing you can give us.