DEV Community: Crane Zhou

A site that has to change at midnight: daily data with GitHub Actions and static hosting

Crane Zhou — Sat, 14 Nov 2026 08:02:00 +0000

I built a small fan site, Krillion Answer Key, that lists the day's answers to a daily trivia game. The game publishes one answer sheet a day and only keeps the current day public. So the site has one job with a deadline: shortly after midnight US Eastern, fetch the new sheet, keep it, and republish. A day that is missed cannot be fetched later.

The site is a static export (Next.js) on Cloudflare Workers static assets. There is no server and no database. Here is what the daily job looks like and what I learned.

1. The data lives in the repo. A script fetches the sheet and appends the day to one JSON file. Every page is generated from that file at build time: the home page is the newest day, each day and each prompt gets its own page, and a "yesterday" page appears once there are two days. Git history is the backup.

2. Trim before you store. The raw sheet is about 7.5 MB: more than 100,000 accepted answers across seven prompts, most of them in one tier. I keep the top answer, the small tiers in full, and an evenly spread sample of the large ones. A day ends up around 24 KB.

3. Scheduled workflows start late, so schedule several. GitHub's cron can start minutes late under load. The workflow runs a few times in the hour after the reset, and again later as a safety net. The script is idempotent: if today is already saved it exits without doing anything, and the build step is skipped.

4. Daylight saving moves the deadline. Midnight Eastern is 05:00 UTC in winter and 04:00 UTC in summer, and cron is in UTC. Rather than changing the schedule twice a year, the workflow runs after both hours and the script works out the date itself with Intl.DateTimeFormat and the America/New_York zone.

5. Commit first, deploy second. The job commits the new JSON, then builds and deploys. If the deploy fails, the data is already safe and the next run can redeploy.

6. Give CI the smallest key that works. The deploy token can edit Workers scripts and the routes of one zone, and nothing else.

7. Have a way to test the fetch without saving. A --probe flag fetches and reports the size of the sheet. I run it on manual dispatch, which is how I checked that GitHub's runners could reach the source at all.

The fetch script and workflow are on GitHub: fancydirty/krillion-answer-key.

Disclosure: I run the site, which is an independent fan site and not affiliated with the game. This post was drafted with AI assistance from my own code and notes.

Why "Optimized" GIFs Turn Into Haunted Sprite Sheets (And 4 Tiny Canvas Fixes for 2D Game Devs)

Crane Zhou — Sat, 14 Nov 2026 02:43:16 +0000

If you have ever built a sprite tool or dropped an "optimized" GIF into a custom game importer, you have met The Haunted Sprite Sheet:

Frame 1 looks great.
Frame 2 is just a floating pair of eyeballs and a sword tip.
Frame 3 has three left legs stacked on top of each other like a Futurist painting.

Then, right after you fix the GIF decoder, someone drops in an AI-generated character sheet with a solid lime-green background, uneven gutters, and a sword detached 4 pixels from the character's hand. Or they scale up a 32×32 pixel slime and accidentally introduce 900 muddy anti-aliased gray pixels.

When I built GIF to Sprite Sheet — a zero-upload browser toolkit for converting, cutting, packing, and upscaling sprite sheets — almost all the real work came down to four surprisingly small algorithms on raw ImageData arrays.

Here is every trap we hit, and the exact TypeScript that fixed it.

1. Reconstructing "Optimized" GIFs Without Ghost Limbs

A lot of naive GIF-to-sheet scripts parse the binary stream with gifuct-js and draw each frame's patch straight onto its own cell.

That breaks immediately on real-world GIFs, because encoders save bytes in two sneaky ways:

Sub-frame patches: Frame i might only be a 14×9 rectangle at (x: 22, y: 8) where the character blinked.
Disposal methods (disposalType): Each frame tells the player what to do with the canvas after showing it:
- 0 / 1 (Keep): Leave these pixels on screen; frame i + 1 paints right over them.
- 2 (Restore to background): Clear only this frame's dims rectangle back to transparent before frame i + 1.
- 3 (Restore to previous): Snapshot the canvas before painting frame i, display frame i, then roll back to that snapshot!

Ignore disposalType, and 1 gives you floating eyeballs while 2 gives you stacked legs. To output clean game-engine cells like this 96×96 sheet:

…you maintain a running virtual screen buffer and snapshot out of it on every tick:

const full = createCanvas(gifWidth, gifHeight);
const fctx = full.getContext("2d", { willReadFrequently: true })!;
const patch = createCanvas(1, 1);
const pctx = patch.getContext("2d")!;

let restoreSnapshot: ImageData | null = null;
const frames: HTMLCanvasElement[] = [];

for (const f of rawFrames) {
  // Disposal 3: snapshot the screen BEFORE this frame touches it
  if (f.disposalType === 3) {
    restoreSnapshot = fctx.getImageData(0, 0, gifWidth, gifHeight);
  }

  // Paint this frame's dirty rectangle onto the running screen
  patch.width = f.dims.width;
  patch.height = f.dims.height;
  pctx.putImageData(
    new ImageData(new Uint8ClampedArray(f.patch), f.dims.width, f.dims.height),
    0,
    0
  );
  fctx.drawImage(patch, f.dims.left, f.dims.top);

  // Copy the composited full frame into our output list
  const out = createCanvas(gifWidth, gifHeight);
  out.getContext("2d")!.drawImage(full, 0, 0);
  frames.push(out);

  // Honour the frame's cleanup rule before the next tick
  if (f.disposalType === 2) {
    fctx.clearRect(f.dims.left, f.dims.top, f.dims.width, f.dims.height);
  } else if (f.disposalType === 3 && restoreSnapshot) {
    fctx.putImageData(restoreSnapshot, 0, 0);
  }
}

Bonus 1990s browser quirk: Any GIF frame delay <= 10ms (0 or 1 hundredth of a second in the binary header) is silently clamped to 100ms (10 fps) by Chrome, Safari, and Firefox. Old GeoCities banner ads left the delay byte at 0, so browsers invented a floor. If your exporter trusts f.delay === 0 literally, your sprite sheet plays 10× faster in Unity or Godot than it ever did in Chrome!

2. Cutting Uneven & AI-Generated Sheets (Edge Flood-Fill + Proximity Join)

Clean pixel-art sheets sit on a strict 32×32 or 64×64 grid. Real-world sheets downloaded from itch.io forums — or generated by AI models — almost never do. They have a solid #00ff00 or #14121f backdrop, drifted spacing, and detached sword slashes.

In the sprite sheet cutter, two passes turn a messy sheet into jitter-free frames:

Pass A: Border-seeded flood fill (so black outlines survive a dark backdrop)

If you simply delete every pixel matching the top-left corner color (kr, kg, kb), a character with black boots and black outlines on a dark sheet gets Swiss-cheesed.

Instead, seed a DFS stack only from the 4 outer edges of the image:

const stack = new Int32Array(W * H);
const seen = new Uint8Array(W * H);
let top = 0;

const push = (p: number) => {
  if (!seen[p] && (alpha(p) <= 8 || colorMatches(p, keyRgb, tolerance))) {
    seen[p] = 1;
    stack[top++] = p;
  }
};

// Seed ONLY from top/bottom rows and left/right columns
for (let x = 0; x < W; x++) { push(x); push((H - 1) * W + x); }
for (let y = 0; y < H; y++) { push(y * W); push(y * W + W - 1); }

while (top > 0) {
  const p = stack[--top];
  setAlphaZero(p);
  // push 4-neighbors...
}

The backdrop melts away right up to the outer silhouette, while identical colors inside the character stay untouched.

Pass B: Proximity box merging + foot anchoring

Once the backdrop is transparent:

Run 8-connected component labeling on alpha > 8 to find every pixel island.
Merge bounding boxes within join pixels (e.g. 4px) of each other so a detached wand spark or drop shadow stays married to its character instead of becoming "Frame 7.5".
Pad every cut frame to the largest frame's W × H anchored at bottom-center. Why bottom-center instead of dead-center? Because when a character jumps or swings overhead, their height grows upward — center-anchoring makes their feet levitate off the floor!

3. Scaling Pixel Art Without Turning It to Soup (`EPX` in 15 Lines)

Game devs constantly need a 32×32 sprite enlarged to 256×256 for Steam capsules, UI portraits, or high-DPI canvases. Bilinear filtering blurs it into vaseline. Plain Nearest Neighbor keeps razor-sharp squares:

Nearest Neighbor is usually what you want inside a retro engine. But what if you want rounded diagonals without inventing blurry anti-aliased colors?

Enter EPX (Eric's Pixel Expansion) — written by Eric Johnston at LucasArts around 1992 when porting SCUMM engine classics to higher-res color Macs (later famous as Scale2x):

For every pixel P with cardinal neighbors A (up), B (right), C (left), D (down), P expands into a 2×2 block, rounding off corners wherever two adjacent neighbors agree:

function epx2x(src: Uint32Array, w: number, h: number): Uint32Array {
  const W = w * 2;
  const out = new Uint32Array(W * h * 2);

  for (let y = 0; y < h; y++) {
    for (let x = 0; x < w; x++) {
      const p = src[y * w + x];
      const a = y > 0     ? src[(y - 1) * w + x] : p;
      const d = y < h - 1 ? src[(y + 1) * w + x] : p;
      const c = x > 0     ? src[y * w + x - 1]   : p;
      const b = x < w - 1 ? src[y * w + x + 1]   : p;

      const o = y * 2 * W + x * 2;
      out[o]         = c === a && c !== d && a !== b ? a : p;
      out[o + 1]     = a === b && a !== c && b !== d ? b : p;
      out[o + W]     = d === c && d !== b && c !== a ? c : p;
      out[o + W + 1] = b === d && b !== a && d !== c ? d : p;
    }
  }
  return out;
}

Look closely at the assignments: zero new colors are ever synthesized. Every output pixel is copied verbatim from src via Uint32Array integer comparisons! And if you actually want painterly vector-like curves, you can step up to Hyllian's xBR:

(Production gotcha: people often upload "pixel art" from Twitter/Discord that was **already* enlarged 4× with Nearest Neighbor, so each visible "pixel" is really a 4×4 block. Run EPX or xBR on pre-upscaled art and only the microscopic corners of each 4×4 block round off! In the pixel art upscaler, we scan k = 32..2 first to detect if every k×k block is identical, and warn you what native scale the sprite is actually hiding at.)*

4. Why `canvas.toBlob()` Chokes on 200-Frame ZIP Exports

One last browser trap: when someone slices a 180-frame animation and clicks Frames ZIP, calling await canvas.toBlob() inside a for loop crawls in Chromium because toBlob schedules async GPU readbacks and full PNG compression one at a time.

Instead, grab ctx.getImageData(0, 0, w, h).data.buffer, encode each PNG synchronously with UPNG.encode([buffer], w, h, 0), and bundle all the Uint8Arrays with fflate's zipSync at level: 0 (PNGs are already Deflate-compressed — re-compressing them inside a ZIP burns CPU for ~0.3% savings). Yield every 8 frames with setTimeout(r, 0) so the UI never drops a frame, and 180 sprites zip up in well under a second.

All five tools (GIF → sheet, sheet → GIF, cutter, frame packer, and pixel-art upscaler) run 100% locally in your browser at giftospritesheet.com — including direct .tres SpriteFrames export for Godot 4, TexturePacker JSON, VRChat 1024×1024 emoji presets, and Sparrow v2 XML.

If you've ever built a custom asset pipeline for a 2D game, what's the most cursed sprite sheet an artist (or AI) ever handed your importer?

Single elimination, double elimination or round robin: pick by the numbers

Crane Zhou — Fri, 13 Nov 2026 19:25:59 +0000

The format decides how many games you have to fit into the day and how many each team is guaranteed. Choose from those two numbers.

Games needed for N teams

Single elimination: N − 1
Double elimination: 2N − 2, plus 1 if the final is replayed
Round robin: N × (N − 1) ÷ 2

So 8 teams is 7, 14 or 28 games. 16 teams is 15, 30 or 120.

Games guaranteed per team

Single elimination: 1
Double elimination: 2
Round robin: N − 1

Choose single elimination when time or courts are short, or the field is large. It is the only format where 32 teams finish in an afternoon. Half the teams play once and go home.

Choose double elimination when you want every team to play at least twice and the best team to win. It needs about twice the games.

Choose round robin when the group is small and everyone came to play: six friends, a class, a league night. Past ten teams or so it only works over several weeks, or as pools of four or five that feed a bracket.

Courts matter as much as teams. On one court, 8 teams in double elimination is 14 time slots. On two courts it is 8.

The full guide, with a table of time slots for one to four courts: https://bracketmaker.co/blog/single-vs-double-elimination-vs-round-robin

Make any of the three, free: https://bracketmaker.co

Written with AI assistance.

What one SeniorMatch account saw free and paid, on the same day

Crane Zhou — Fri, 13 Nov 2026 19:15:28 +0000

On 12 November 2026 I read the same SeniorMatch member account twice in one day: in the morning as a free member, in the afternoon with Premium switched on. Same profile, same age range, same gallery. Only the paid tools changed.

The test

With the location left on Anywhere and the gallery sorted the default way, the first 40 cards came from 24 different states, provinces and countries. 29 were in the United States, 3 in Canada, the rest elsewhere. The median age was 63.5.

Then I opened the Advanced tab, which only exists on Premium, and changed one thing: Sort by, Nearest first. 39 cards loaded. All 39 were in Ontario, the province on the profile.

What paying actually changed

Nobody new appeared. Those 39 people were members before I paid and after, and a free account could have found them by searching the province by name, which costs nothing.

What Premium changed was the order and the effort. Nearest first puts the people you could drive to at the top without building a search each time. The other 13 advanced filters narrow that list by relationship status, religion, smoking, whether the photo is verified, and so on. And Premium lets you write first. On a free account you can reply when a paying member writes to you, but you cannot open a conversation.

What it does not change

The size of the pool near you, or whether the people in it answer. Premium is a set of tools over the list you can already see. It does not add anyone to it, and it does not screen anyone: SeniorMatch says in capitals in its own service agreement that it runs no criminal background screening, on any tier.

How to use that if you are deciding

Set your state and your age range on the free account, then count the people you would actually meet. If that number is small, Premium sorts a short list. If it is healthy, one month is a fair test of whether they write back.

The longer version, with screenshots and the date of every figure, is at https://seniormatchreview.com/answers/is-seniormatch-premium-worth-it/

Elena works at SeniorMatch. SeniorMatch Review earns a commission when readers register through its links.

Measuring reaction time in the browser: six things that went wrong

Crane Zhou — Fri, 13 Nov 2026 16:19:54 +0000

I built a small site with twelve reflex mini-tests (Aging Curve Test, in Korean). Timing a click sounds like one subtraction. These are the things that made the numbers wrong before they were right.

1. event.timeStamp and performance.now() are not always the same clock.
The obvious code records performance.now() when the signal is shown and subtracts it from event.timeStamp when the player clicks. In one Chromium-based browser I tested in, the two values were on different time bases, so every reaction came out negative and was rejected as "too early". The fix was a small function that checks whether an event timestamp is plausibly close to performance.now() and falls back to performance.now() when it is not.

2. The signal is not on screen when you set the state.
Changing a colour in React does not put it on the glass. I record the show time immediately, then correct it inside requestAnimationFrame, which is closer to the frame the player actually sees. Without that, everyone is one frame faster than they deserve.

3. One trial is mostly luck.
The reaction test takes five trials and reports the median. A single lucky anticipation or one blink no longer moves the result.

4. People anticipate.
Anything faster than 100 ms after the signal is treated as a guess and the trial is repeated. So is a press before the signal. The wait before the signal is random so it cannot be counted.

5. Holding a key is not clicking.
For the clicks-per-second test, keydown events with repeat: true are ignored. Otherwise holding the space bar gives 30 clicks a second.

6. Mistakes need a price.
In the choice-reaction, aim, Stroop and go/no-go tests, speed alone rewards mashing. Each error adds a fixed number of milliseconds to the average (25, 15, 35 and 50 ms). The numbers are published on each test's page so nobody has to guess how the score was made.

Scoring. Each test maps a raw value to 0–100 between two published anchors. For simple reaction time, 190 ms is 100 points and 480 ms is 0. For comparison, Human Benchmark reports a median of 273 ms over 81 million clicks. The six ability scores are averaged and turned into an age with one line: 18 + (100 - total) * 0.6. It is a game, not a measurement of anything medical, and the site says so.

Why 24? The curve drawn on the site peaks at 24 because of Thompson, Blair and Henrey (2014), a PLOS ONE study of 3,305 StarCraft 2 players aged 16 to 44 that found in-game reaction times begin to slow at about that age (doi:10.1371/journal.pone.0094215).

Everything runs in the browser: there is no account, and results stay in localStorage. The scoring rules are written out at agingcurve.org/guide.

Disclosure: I run the site. This post was drafted with AI assistance from my own notes and code.

3 Weird Bugs I Hit Rendering Typing-Text GIFs in Plain Canvas (Clipped g's, 1-Bit Halos, and Classic Outlook)

Crane Zhou — Fri, 13 Nov 2026 14:04:59 +0000

A few weeks ago I shipped Typing Text GIF, a small client-side tool that renders typing and typewriter text animations into looping GIFs or APNGs right in the browser.

You'd think "draw some text on an HTML5 <canvas> and encode a GIF" is a solved weekend afternoon project. It almost is — until the bug reports roll in:

"Why does the bottom of the letter g get chopped off when I pick a serif font?"
"Why does my transparent GIF look like a 1998 GeoCities sticker with a crunchy white halo on dark mode?"
"I put this in my Outlook signature and my boss says I just sent him a blank rectangle with a pipe character."

All three of these have tiny, surprisingly fun fixes in plain TypeScript. None of them require a backend, ffmpeg, or WASM.

Here is what was actually going wrong under the hood.

Bug #1: `fontSize` is a lie (why `g` and `y` lose their tails)

My first draft sized the canvas height to something naive like fontSize * 1.25 + padding * 2 and drew text centered at height / 2 with textBaseline = "middle".

That works fine for Inter typing "HELLO WORLD". Then someone types "gypsy jazz" in a bouncy display font, or adds an uppercase Å on the same line as a p, and the descenders get guillotined right at the bottom edge of the frame.

fontSize: 48 does not mean "every letter fits inside 48 pixels." It's the em-square size. Depending on the font's metrics, ascenders and descenders regularly poke outside it, and "middle" baseline alignment varies subtly across browser text engines.

Luckily, modern 2D canvas gives you the font's real metrics right off ctx.measureText():

function measureLine(ctx: CanvasRenderingContext2D, fontCss: string) {
  ctx.font = fontCss;
  // Probe string with tall ascenders, deep descenders, and diacritics
  const m = ctx.measureText("Mgjpqy|ÅÉ");

  const ascent = Math.ceil(
    m.fontBoundingBoxAscent ?? m.actualBoundingBoxAscent
  );
  const descent = Math.ceil(
    m.fontBoundingBoxDescent ?? m.actualBoundingBoxDescent
  );

  return {
    ascent,
    descent,
    lineHeight: ascent + descent,
  };
}

Two details make this rock-solid:

Prefer fontBoundingBoxAscent over actualBoundingBoxAscent. If you measure the actual bounding box of each frame as letters type in one by one, "a" has a tiny height, then "ag" suddenly gets taller — so your text jumps vertically mid-word! fontBoundingBox* gives you the font-wide ceiling and floor regardless of which characters have been typed so far.
Draw on "alphabetic" baseline using top + ascent. Instead of guessing where "middle" lands, compute const y = top + rowIndex * lineHeight + ascent and set ctx.textBaseline = "alphabetic". Every glyph sits on the exact same baseline from frame 1 to frame 90, and g, j, p, q, y keep their tails.

Bug #2: The 1998 GeoCities Halo on Transparent GIFs

Canvas renders crisp, anti-aliased text by blending edge pixels to partial alpha (alpha = 0.15, alpha = 0.62, etc.).

The GIF89a spec from 1989 does not know what partial alpha is. In a GIF, a pixel is either 100% opaque or 100% transparent (1-bit transparency, controlled by a single transparentIndex in the 256-color palette).

If you render white text onto a transparent canvas (rgba(0, 0, 0, 0)) and hand those raw bytes to a GIF quantizer:

Semi-transparent edge pixels have RGB values mixed with whatever was underneath (usually black 0,0,0 or white 255,255,255),
Every pixel above your alpha threshold snaps to 100% opaque,
And suddenly your smooth white text has a crusty grey/black outline around every curve.

If the user actually needs true 8-bit smooth alpha over an arbitrary gradient, the honest answer is export APNG (browsers and iMessage love APNG, and upng-js encodes it cleanly).

But email clients, GitHub READMEs, and Notion embeds still expect .gif. The trick old-school Photoshop Web Export used — and the one that still works like magic — is matte pre-blending:

/**
 * Blend semi-transparent edge pixels against the target background color
 * BEFORE snapping alpha to 1-bit.
 */
function matteAlpha(px: Uint8ClampedArray, matteHex: string) {
  const mr = parseInt(matteHex.slice(1, 3), 16);
  const mg = parseInt(matteHex.slice(3, 5), 16);
  const mb = parseInt(matteHex.slice(5, 7), 16);

  for (let i = 0; i < px.length; i += 4) {
    const a = px[i + 3] / 255;
    if (a === 0) continue;

    // Composite the glyph's edge pixel over the destination matte color
    px[i]     = Math.round(px[i]     * a + mr * (1 - a));
    px[i + 1] = Math.round(px[i + 1] * a + mg * (1 - a));
    px[i + 2] = Math.round(px[i + 2] * a + mb * (1 - a));

    // Now snap to 1-bit GIF alpha
    px[i + 3] = a >= 0.35 ? 255 : 0;
  }
}

If your GIF is going onto a dark GitHub README (#0d1117), you set the matte to #0d1117. All the interior pixels of the background stay genuinely transparent (a = 0), while the 1px anti-aliased fringe around each letter fades toward #0d1117 instead of white. Zero halo.

Also: remember dispose: 2 (restore to background) in your GIF encoder when transparent is enabled! Otherwise frame 2 draws right on top of frame 1 instead of clearing the previous cursor position.

Bug #3: Classic Outlook Only Ever Sees Frame 0

If you build a typing animation for "Jane Doe · Founder", what is on Frame 0?

Usually: an empty canvas with a lonely blinking cursor |.

Now drop that GIF into an animated email signature.

Gmail, Apple Mail, and modern Outlook on Mac/Web play the loop happily. Classic Outlook for Windows (2007–2019) — which still uses the Microsoft Word rendering engine under the hood — refuses to animate GIFs and freezes permanently on Frame 0.

Congratulations: half of your enterprise recipients just got a blank rectangle with a vertical bar at the bottom of your email.

You don't need a separate static fallback image to fix this. Since a looping GIF is a ring buffer of frames, rotating the array doesn't change the loop at all:

if (settings.fullFirstFrame && settings.loop) {
  // Find the exact frame where Phrase 0 finishes typing out
  const holdStart = frames.findIndex(
    (f) => f.phrase === 0 && f.chars === [...phrases[0]].length
  );

  // Rotate the timeline so Frame 0 IS the completed headline!
  return [
    ...frames.slice(holdStart),
    ...frames.slice(0, holdStart),
  ];
}

Think about what happens in both worlds:

In Gmail / Apple Mail: The GIF opens on "Jane Doe · Founder", holds for 1.5 seconds with a blinking cursor, backspaces it, types "Book a call: cal.com/jane", backspaces, and types "Jane Doe · Founder" right back to the start of the loop. Seamless.
In Classic Outlook on Windows: Frame 0 is "Jane Doe · Founder". It looks like a crisp, intentional static banner.

One slice call, bug gone forever.

Bonus: Fake Typewriter Ink That Doesn't Flicker

When I added the typewriter text GIF mode, I wanted each letter to land slightly crooked, with uneven ribbon ink (alpha between 0.78 and 1.0).

If you reach for Math.random() inside your draw() function, every letter jitters wildly like a ransom note having a caffeine overdose, because draw() runs once per frame, not once per character!

Instead, hash the character's index with a tiny deterministic sine hash:

const noise = (seed: number) => {
  const x = Math.sin(seed * 127.1 + 311.7) * 43758.5453;
  return x - Math.floor(x);
};

// Inside the per-glyph loop:
const dy    = (noise(glyph.index * 3.1 + glyph.x) - 0.5) * fontSize * 0.06;
const rot   = (noise(glyph.index * 7.7 + 1) - 0.5) * 0.05;
const alpha = 0.78 + noise(glyph.index * 5.3 + 2) * 0.22;

Now the 4th letter 'e' gets the exact same -1.2px vertical slip and 84% ink density on frame 4, frame 5, and frame 60 — and if you re-export with the same text tomorrow, you get the exact same bytes out.

If you want to poke around the rest of the canvas + gifenc implementation, the whole engine is MIT-licensed on GitHub (fancydirty/typing-text-gif), or you can try breaking it live at typingtextgif.com.

What's the weirdest format edge case a 35-year-old spec has ambushed you with lately?

The Weirdly Petty Engineering Behind Printing a Straight Barcode Sticker

Crane Zhou — Fri, 13 Nov 2026 12:13:14 +0000

Most software bugs are dramatic. A database locks up, a payment webhook drops on the floor, or an OAuth token expires in the middle of a demo.

Barcode bugs are not dramatic. They are passive-aggressive.

Everything looks gorgeous on your 5K monitor. Then you hit Print, peel a sticker off row 9 of an Avery 5160 sheet, and the bottom guard bars are sliced clean across the perforation line. Or worse: you run a thermal roll through a 203 DPI Zebra printer, the label looks crisp to your human eyes, and the fulfillment center scanner refuses to beep.

Over the past couple of weeks building and rebuilding UPCLabelMaker, we spent an embarrassing amount of time chasing tiny, stubborn physical-world bugs like these. Not AI prompts. Not distributed consensus. Literally tenths of a millimeter of black ink on sticky paper.

Here are four of the dumbest, most interesting traps we hit—and how we fixed them after actually decoding and measuring every single generated file.

1. The 203 DPI Thermal Head Math Problem (Why "Clean Vector" Still Bleeds)

If you print an Amazon FNSKU sticker on a laser sheet, you have 300 or 600 DPI to burn. Nobody cares if a barcode bar is 0.330 mm or 0.334 mm.

If you print on a direct-thermal shipping printer (Zebra LP2844, Rollo, Munbyn), the printhead usually runs at 203 DPI. That means each tiny heating element is exactly 0.125 mm wide—or in PostScript points, 72 / 203 ≈ 0.35468 pt.

Now watch what happens when you draw a "mathematically clean" 0.33 mm narrow bar onto a 2 × 1 inch PDF:

0.33 mm / 0.125 mm = 2.64 heating elements.

A thermal printhead cannot turn on 64% of a resistor. So the printer driver rounds—sometimes 2 dots, sometimes 3 dots—and suddenly your narrow bars and narrow spaces aren't the same width anymore. To a human, it looks fine. To a warehouse laser scanner expecting strict module ratios, it reads like a stutter.

In our 2 × 1 in thermal label generator and PDF engine (src/lib/pdf-engine.ts), we stopped pretending thermal printers have infinite resolution. On roll stock, we snap the narrow module width and the horizontal barsX starting coordinate directly to integer multiples of 72 / 203 points:

const dotPt = 72 / 203; // 1 physical heater dot at 203 DPI
const totalMods = modulesLen + quietMods * 2;
const maxDotsPerMod = Math.max(1, Math.floor(maxSymW / totalMods / dotPt));
const idealDots = Math.round(rawModuleW / dotPt);
const dotsPerMod = Math.min(maxDotsPerMod, Math.max(2, idealDots));
const moduleW = dotsPerMod * dotPt;
const barsX = Math.round(rawBarsX / dotPt) * dotPt;

Two heating elements per bar (0.25 mm) on a 2 × 1 inch label leaves a solid 7.2 mm of clear white space on both sides of a 10-character X00 FNSKU. Every bar lands squarely on physical heater elements instead of fighting the driver's dithering.

2. The "Helpful" Truncation Bug That Prints Someone Else's Barcode

When we built an automated verification script to decode all 48 combinations of our PDF matrix (4 barcode formats × 4 paper stocks × 3 layout modes) plus single-label exports, it immediately caught a classic developer assumption.

Suppose a seller pastes a 14-digit GTIN-14 case code into a UPC-A form (which takes 11 or 12 digits).

What does a "forgiving" form usually do? It slices the string to 11 digits and recomputes a check digit.

Wait—think about what that actually does in a warehouse. If you chop 3 digits off a 14-digit GTIN-14 and recalculate the Modulo-10 check digit, you still get a 100% valid, scannable UPC-A barcode. It just belongs to a completely different product.

That is way worse than an error message. So we ripped out silent truncation. Now, if someone enters 14 digits on the UPC-A barcode generator or EAN-13 label generator, it flat-out refuses to truncate it and tells them a 14-digit code belongs in a GS1 DataMatrix 2D label (where AI (01) expects GTIN-14). And if you just want to check or fix a broken 12th/13th digit without guessing, the check digit calculator flags mismatches explicitly.

Same deal in our bulk barcode generator: if a CSV row has a wrong check digit, we list it and skip it instead of silently altering your inventory IDs.

3. Why Your PNG Barcode Looks Giant When Pasted Into Word

Export a single 1D barcode as a PNG for a product packaging mockup or a Word sheet, drag it into Microsoft Word, and suddenly it takes up half the page.

Why? Because HTML <canvas> exports PNGs with no pHYs DPI metadata chunk (or browsers default it to 72/96 DPI). So when you draw a crisp high-res image at 600 DPI pixel dimensions (e.g. 900 px wide) without writing the physical pixel-per-meter chunk into the PNG binary, Word assumes 96 DPI and blows your 1.46-inch UPC up to 9+ inches.

Our single-label PNG exporter writes the exact pHYs chunk (23622 pixels/meter = 600 DPI) into the PNG byte stream before download, and locks the module width to the exact 0.330 mm GS1 100% spec. Drop it into Word or Figma and it lands at physical retail size on the first try.

4. Word Templates Lie About Row Height (and Seller Central Wastes 60% of Your Sheet)

Two things constantly surprise people who just want to print stickers without learning GS1 specifications:

Why almost every free Avery 5160 Word template drifts by Row 7: In Word, table rows default to "At least 1.0 in" instead of "Exactly 1.0 in" (1440 twips). The moment one product name wraps to two lines, row 4 grows by 4 millimeters, and rows 5 through 10 quietly walk off their die-cut stickers. Our downloadable .docx templates for Avery 5160 and Google Docs label templates use fixed table layouts, explicit spacer columns for the 3.175 mm horizontal gaps, and exact twip row heights so text can never shove row 8 down.
Why Amazon Seller Central wastes partial sticker sheets: If you download an FNSKU PDF from Seller Central, it puts one SKU per 30-up page. Ship 8 units each of 3 different products? Enjoy throwing away 66 blank stickers. We added multi-SKU mixing on our Amazon FNSKU label generator (plus an FBA 30-up PDF to 2×1 thermal converter that parses the PDF text streams directly in pure TypeScript without spawning headless Chrome or Ghostscript), and wrote up the exact FBA sticker dimensions in our Amazon FNSKU label size guide and X00 barcode guide.

The Lesson: Screenshots Lie, Decoders Don't

Early on, we judged label outputs by looking at screenshots. Bad idea. A barcode that is 0.4 mm too narrow or a title that clips 2 pixels into a quiet zone looks totally normal to a developer glancing at a preview.

Nothing keeps you honest like wiring up a headless verification script that actually generates every PDF, rasterizes it, decodes the barcodes with a real scanner library, and measures bounding boxes against the physical paper margins. Every time we run that check, we trust our eyes a little less and our calipers a little more.

If you've ever fought a printer scaling dialog ("Fit to Printable Area" is the mortal enemy of sticker sheets—always use Actual Size / 100%) or had to convert Seller Central's 30-up PDFs for a thermal roll, feel free to poke at UPCLabelMaker or our plain-paper Avery 5160 alignment test and tell me what still breaks on your printer.

What makes a custom Yu-Gi-Oh! card look real

Crane Zhou — Wed, 11 Nov 2026 15:40:12 +0000

The fastest way to make a custom Yu-Gi-Oh! card is a browser card maker: pick a frame, add a picture, type the name, Type line, effect text and ATK/DEF, then download the PNG. No account, nothing to install. What takes time is making the result read like a card Konami might have printed. The long version, with stat tables and comparisons, is in the full guide to making custom Yu-Gi-Oh! cards; this is the short one.

What goes on a card, part by part

The rulebook labels seven things on a Monster Card: name, Attribute, Level, Type, card number, ATK/DEF and description box. Printed cards carry a little more.

Name — the top bar. Two cards with the same name count as the same card.
Attribute — top right. DARK, EARTH, FIRE, LIGHT, WATER or WIND. Spells and Traps show a SPELL or TRAP symbol instead.
Level, Rank or Link — Level stars sit under the name and run from the right, 0 to 12. Xyz Monsters use a Rank with stars starting from the left. Link Monsters have neither; the Link Rating sits bottom right and equals the number of arrows.
Type line — first line of the text box, in brackets, in this order: Type, card type, ability, Tuner, then Effect or Normal, e.g. [Zombie/Tuner/Effect].
Card text — effect text, or italic flavour text on a Normal Monster. Extra Deck monsters list materials on the first line.
ATK/DEF — bottom of the text box, multiples of 100 on most cards.
Set number — under the picture on the right, in the form AAAA-RR###. Invent your own, such as FAN-EN001. Passcode goes bottom left, eight digits; Tokens have none.

Leave off Konami's copyright line and the foil Eye of Anubis square: they mark an official card, yours is not one. Put your own credit there instead, and do not reuse a real card's passcode.

Pick the frame before anything else

The frame colour tells a player how the card is summoned, so it has to match. Yellow is a Normal Monster with no effect, orange an Effect Monster, blue a Ritual. Fusion is violet, Synchro white, Xyz black, Link dark blue with a honeycomb texture; those four need materials. Spells are green, Traps purple, Tokens grey.

For a gift or a joke card, take the yellow Normal frame over the orange one every time. A Normal Monster gets two lines of italic flavour text, which is exactly where the joke about your friend goes.

Stats that look right for the Level

Level is not decoration. A Level 5 or 6 monster needs one Tribute to Normal Summon and Level 7 or higher needs two, so stats climb with Level. The observed ceilings are roughly 1,750 ATK at Level 3, 2,000 at Level 4, 2,600 at Level 6, 3,000 at Level 8, 4,000 at Level 10 and 5,000 at Level 12; cards that break a ceiling usually carry a drawback.

Effects are paid for in stats. Blue-Eyes White Dragon does nothing and sits at 3000; Elemental HERO Stratos searches your deck and sits at 1800. If your Level 4 has a good effect, 1,500 to 1,800 ATK is the honest range. A Level 4 with 2,000 ATK and a paragraph of upside is the classic first custom card, and the table will groan.

Writing an effect that reads like a real one

Since 2011 English cards have used Problem-Solving Card Text, and the punctuation carries rules. Text before a colon is the activation condition; before a semicolon is what you do to activate it, such as paying a cost or choosing a target; the rest is what happens. Write one effect in that shape, give it a real cost, and add the modern limiter: You can only use this effect of "Your Card's Name" once per turn. Recent printings also say GY where old cards spelled out Graveyard.

Getting artwork and printing it

The picture window on a standard frame is square, so draw wider than you need and let the maker crop to fill; you can drag and zoom afterwards. The large download is 1,626 × 2,370 pixels, so artwork around 1,300 pixels on a side is plenty.

Printing is where scale gets people. A Yu-Gi-Oh! card is 59 × 86 mm, smaller than a poker card, so do not let the printer dialog resize it. The card maker saves your cards so it can lay nine of them on a Letter or A4 sheet at that size, 300 dpi, with cut marks.

What goes wrong

Too much text is the big one. Real cards squeeze letters sideways before dropping to a smaller size, and a good maker does the same, but the smallest sizes are hard to read. Mixed-up mechanics give a card away fastest: a Link Monster with a DEF value, an Xyz Monster described as "Level 4", a Synchro with no materials line, a yellow Normal frame with an effect in the box. A player spots any of those in a second.

One limit before you sleeve a card up for locals: Konami's tournament policy (version 2.5, in effect since September 5, 2025) bans proxy and counterfeit cards from sanctioned events even if you own the real card. Custom cards are for kitchen-table games where everyone agreed to them, never for selling as the real thing.

CSS sprite sheet animation: getting steps() right

Crane Zhou — Tue, 10 Nov 2026 18:44:53 +0000

Put the sheet on an element as a background, size the element to one frame, and animate background-position across the sheet with a steps() timing function. For 8 frames of 64 × 64 in one row:

.sprite {
  width: 64px;                 /* one frame */
  height: 64px;
  background: url("walk.png") 0 0 no-repeat;
  animation: play 0.8s steps(8) infinite;   /* 8 frames at 10 fps */
}

@keyframes play {
  to { background-position: -512px 0; }     /* 8 x 64px: the whole sheet */
}

<div class="sprite" role="img" aria-label="Character walking"></div>

Every snippet ran in Chromium 156, reading computed background-position every 5 ms; not Safari or Firefox.

Why steps(N) ends at the full sheet width

Duration is frames over frame rate. The end position trips people up: the last frame sits at -448px (7 × 64), so that looks like the stop. But steps(8) is steps(8, end) — 8 equal holds, the last jump at the end — so the to value never shows. Ending at -512px lands the holds on 0, -64, -128 … -448.

The classic bug mirrors it: end at -448px with steps(8) and every step is 56px, so the first frames look fine and the last show two halves.

The jump-none form is the other correct answer, and I write it by hand even though a forward loop looks identical:

.sprite {
  animation: play 0.8s steps(8, jump-none) infinite;
}

@keyframes play {
  to { background-position: -448px 0; }     /* 7 x 64px: the last frame */
}

A sheet with more than one row

One steps() walks in a straight line; a grid must go across, drop, and go across again. Use one keyframe per frame with steps(1), which holds each value until the next:

.sprite {
  width: 64px;
  height: 64px;
  background: url("walk-grid.png") 0 0 no-repeat;   /* 4 columns x 2 rows */
  animation: play 0.8s steps(1) infinite;
}

@keyframes play {
  0%    { background-position: 0 0; }
  12.5% { background-position: -64px 0; }
  25%   { background-position: -128px 0; }
  37.5% { background-position: -192px 0; }
  50%   { background-position: 0 -64px; }
  62.5% { background-position: -64px -64px; }
  75%   { background-position: -128px -64px; }
  87.5% { background-position: -192px -64px; }
}

Each percentage is frame index over frame count, with no 100% keyframe on purpose, so the last frame holds to the end. Uneven timing is free — keyframes 10% apart held frame 8 for 240 ms.

Nobody types that for 40 frames. The GIF to sprite sheet tool and its sprite sheet maker both write this block, or the steps(N) version for a single row, from a Copy CSS button.

For a full grid, two animations on separate axes do the same job:

.sprite {
  width: 64px;
  height: 64px;
  background: url("walk-grid.png") 0 0 no-repeat;
  animation:
    across 0.4s steps(4) infinite,    /* one row: 4 frames */
    down   0.8s steps(2) infinite;    /* 2 rows, each lasting one "across" */
}

@keyframes across { to { background-position-x: -256px; } }
@keyframes down   { to { background-position-y: -128px; } }

Same eight positions at the same times in my test — but not with empty cells, which play as blanks.

Scaling up without blur

Multiply four numbers by one whole number — width, height, background-size, end position — and add image-rendering: pixelated. At 4×:

.sprite {
  width: 256px;                /* 64 x 4 */
  height: 256px;
  background: url("walk.png") 0 0 / 2048px 256px no-repeat;   /* sheet size x 4 */
  image-rendering: pixelated;
  animation: play 0.8s steps(8) infinite;
}

@keyframes play {
  to { background-position: -2048px 0; }
}

background-size is the forgotten one. Without it the 512px sheet sits in a 256px box stepping 256px at a time, so I got frames 1–4, then 5–8, then nothing. MDN defines pixelated as nearest-neighbour scaling to the nearest whole multiple.

Making it responsive

Percentages instead of pixels. background-size: 800% makes an 8-frame row eight elements wide at any width. Positions measure from the far edge: 100% puts the last frame in the box, not one past it — jump-none again.

.sprite {
  width: round(down, 100%, 64px);   /* largest whole multiple of the frame that fits */
  max-width: 256px;
  aspect-ratio: 1 / 1;
  background: url("walk.png") 0 0 / 800% 100% no-repeat;   /* 8 frames wide */
  image-rendering: pixelated;
  animation: play 0.8s steps(8, jump-none) infinite;
}

@keyframes play {
  to { background-position: 100% 0; }
}

round() keeps the scale whole: 192px in a 200px column, exactly 3×, where plain width: 100% gave 3.125× and mixed 3- and 4-pixel art pixels. It shipped in current browsers in May 2024; otherwise set a pixel width per breakpoint. For a grid, use background-size: 400% 200% and offsets of column ÷ (columns - 1).

Play once, reverse, pause on hover

/* Shared keyframes that stop on the last frame */
@keyframes play-to-last {
  to { background-position: -448px 0; }     /* (8 - 1) x 64px */
}

/* Play once and hold the last frame */
.sprite.once {
  animation: play-to-last 0.8s steps(8, jump-none) 1 forwards;
}

/* Backwards, 8 down to 1 */
.sprite.reverse {
  animation: play-to-last 0.8s steps(8, jump-none) infinite reverse;
}

/* There and back: 1 to 8, then 8 to 1 */
.sprite.ping-pong {
  animation: play-to-last 0.8s steps(8, jump-none) infinite alternate;
}

/* Freeze while the pointer is over it */
.sprite.pause-on-hover:hover {
  animation-play-state: paused;
}

/* Still until hovered or focused */
.sprite.play-on-hover {
  animation-play-state: paused;
}
.sprite.play-on-hover:hover,
.sprite.play-on-hover:focus-visible {
  animation-play-state: running;
}

Add forwards to the classic steps(8) rule and the sprite finishes on -512px, one frame past the sheet: an empty box under no-repeat, a snap to frame 1 without it. That is why these rules use jump-none. Hover does not exist on touch, so put play-on-hover on a focusable element — hence :focus-visible.

Respect reduced motion

@media (prefers-reduced-motion: reduce) {
  .sprite {
    animation: none;
    background-position: -192px 0;   /* frame 4, the one that reads best as a still */
  }
}

animation: none alone leaves frame 1 showing, which is not always the best still. In a ping-pong, frames 1 and 8 each hold twice at the turns — usually a natural pause.

Canvas, for per-frame timing or many sprites

CSS runs out when game logic picks the frame, when durations change at run time, or when one element per sprite gets silly. The canvas version is the 9-argument drawImage: source rectangle from the sheet, destination on the canvas.

<canvas id="stage"></canvas>

<script>
const canvas = document.getElementById("stage");
const ctx = canvas.getContext("2d");

const FRAME_W = 64, FRAME_H = 64, COLS = 4;      // a 4 x 2 grid sheet
const durations = [100, 100, 100, 100, 100, 100, 100, 300];   // ms per frame
const total = durations.reduce((a, b) => a + b, 0);

const scale = 3;
const dpr = window.devicePixelRatio || 1;
canvas.width = FRAME_W * scale * dpr;
canvas.height = FRAME_H * scale * dpr;
canvas.style.width = FRAME_W * scale + "px";
canvas.style.height = FRAME_H * scale + "px";
ctx.imageSmoothingEnabled = false;   // after resizing, which resets the context

const sheet = new Image();
sheet.src = "walk-grid.png";

function frameAt(ms) {
  let t = ms % total;
  for (let i = 0; i < durations.length; i++) {
    if (t < durations[i]) return i;
    t -= durations[i];
  }
  return 0;
}

let start, last = -1;
function tick(now) {
  start ??= now;
  const i = frameAt(now - start);
  if (i !== last) {
    last = i;
    const sx = (i % COLS) * FRAME_W;
    const sy = Math.floor(i / COLS) * FRAME_H;
    ctx.clearRect(0, 0, canvas.width, canvas.height);
    ctx.drawImage(sheet, sx, sy, FRAME_W, FRAME_H, 0, 0, canvas.width, canvas.height);
  }
  requestAnimationFrame(tick);
}
sheet.decode().then(() => requestAnimationFrame(tick));
</script>

The frame comes from elapsed time, not from counting requestAnimationFrame calls, so speed does not follow the refresh rate. My run drew at about 30 fps: 100 ms frames changed 0–33 ms late, the 300 ms hold lasted 317 ms. The durations array maps onto the duration field in the JSON atlas the tool exports. One trap: resizing a canvas resets imageSmoothingEnabled.

What goes wrong

Frames slide sideways. No steps(), or a later animation shorthand that drops the timing function, resetting it to ease.
Half of two frames. The step size is not the frame width (448 ÷ 8 is 56), or the sheet has gaps, making the stride frame plus gap.
Blurry. Missing image-rendering: pixelated, a fractional scale, or a PNG smoothed before it reached the browser.
Uneven pixels. Frames that are not a whole number of screen pixels wide: a percentage width, transform: scale(1.37), a parent in vw. At 77.3px a 2px outline rendered 1px.
Too big for a phone. Decoded, a 100-frame row of 256px frames is about 26 MB, and iOS caps a canvas at 4,096 × 4,096.

Sprite sheet, GIF or video?

	Sheet (PNG)	GIF	Animated WebP / APNG
Colour	Full	256 colours	Full
Transparency	Full alpha	On/off	Full alpha
Pause, reverse, play once	Yes	No	No
Code needed	The CSS above	An `<img>`	An `<img>`

Control is the reason to pick a sheet: a GIF plays when it loads, and CSS cannot pause it or stop it for reduced motion. GIF transparency is all or nothing too, so shadows get a hard fringe. File size I will not promise either way — export both and look. If nobody interacts with it, an animated WebP is simpler; past a few seconds, use video.

The full version, with every measurement and the browser sources, is at CSS sprite sheet animation on giftospritesheet.com.

Reading Phantom Blade Zero's PBZS v3 save container in the browser

Crane Zhou — Tue, 10 Nov 2026 12:08:37 +0000

Phantom Blade Zero keeps every save slot in one file, PBZSaveGame.sav. I wanted a save editor that runs entirely in a browser tab, so nothing gets uploaded, and that meant reading the container in JavaScript. These are my notes on the format, called PBZS v3 after its magic bytes, and on the three things that cost me the most time.

The container layout builds on the MIT-licensed PBZ-Editor project and the oozextract contributors. What I added is the browser implementation and the checks described below.

Where the file lives

On Steam the save is not in %LOCALAPPDATA% like most Unreal Engine games. It sits inside the install folder:

<SteamLibrary>\steamapps\common\PBZ\ProjectPBZ\Saved\SaveGames\Steam\<17-digit SteamID>\PBZSaveGame.sav

The same folder holds 1RealTime, 2Hourly and 3Daily, which are rolling backups of the whole container.

The 12-byte header

The first 12 bytes are cleartext:

Offset	Size	Meaning
0x00	4	ASCII `PBZS`
0x04	1	Container version, `0x03`
0x05	1	Flags, observed as `0x01`
0x06	2	Slot count, uint16 LE
0x08	4	Size of the encrypted directory block, uint32 LE

Sealed blocks: the tag comes first

After the header comes an encrypted directory, then one encrypted block per slot. Every sealed block has the same 36-byte preamble:

PBZS 01 01 00 00 (8 B) | nonce (12 B) | GCM tag (16 B) | ciphertext

This was the first trap. AES-GCM libraries, WebCrypto included, expect ciphertext || tag. Here the tag sits before the ciphertext, so you have to move those 16 bytes to the end before decrypting:

const nonce = block.subarray(8, 20);
const tag = block.subarray(20, 36);
const body = block.subarray(36);
const joined = new Uint8Array(body.length + 16);
joined.set(body, 0);
joined.set(tag, body.length);
const plain = await crypto.subtle.decrypt({ name: "AES-GCM", iv: nonce }, key, joined);

The decrypted directory is a packed list of entries:

uint16 nameLen | name (UTF-8) | uint8 algorithm | uint8 flag | uint32 rawSize | uint32 offset | uint32 blockSize

Slot names look like AutoSave0, ManualSave1 and __Advanced__. The last one holds account-wide state such as the wardrobe.

Compression: Oodle Kraken in the browser

Each slot decrypts to a compressed buffer, and the algorithm byte says how: 0 is raw JSON, 1 is zlib, 2 is Oodle Kraken. The game writes Kraken for everything.

That was the second trap, because there is no Kraken decoder in a browser. I compiled an open-source Kraken decompressor to WebAssembly. The format also defines zlib and uncompressed slots, so a writer has options. When the editor saves, every slot you did not touch keeps its original ciphertext byte for byte.

The key is a per-build constant

The AES-256 key is not in the save and is not derived from the Steam account. It is a constant in PBZ.exe: a 64-byte block that follows the UTF-16LE string sealed but block is PLAINTEXT. XOR the first 32 bytes with the last 32 and you have the key. GCM authentication of the directory block tells you whether you found the right one.

Two consequences:

Saves are not bound to an account. The 17-digit SteamID only names the folder.
A game update could change the key. Patch 1.0302256 (4 November 2026) did not: a save written two days after it still opens with the key from the launch build.

What is inside a slot

A slot is plain UTF-8 JSON. Inventory lives in trees such as MainWeaponInfos, ShaChiWeaponInfo, AccessoryInfos and MedicineInfos.

The third trap was mine. I first read WeaponLevel as a small "+N" grade with an offset. It is simply the level the upgrade screen shows: 1 for a new weapon, 30 at the first-playthrough cap, up to 60 in New Game Plus. A finished Cycle 10 save holds every weapon at 60. Check your assumptions against a real late-game file.

The result

The editor and the full byte-level write-up are here:

Save editor: https://phantombladezerosaves.com/save-editor/
Format specification: https://phantombladezerosaves.com/save-file-format/
Spec as a repository: https://github.com/fancydirty/phantom-blade-zero-save-format

It is an unofficial fan project and is not affiliated with S-GAME. Back up the whole SteamID folder before you replace or edit anything.

CSS typing animation: a typewriter effect that survives any font, any length and line wraps

Crane Zhou — Tue, 10 Nov 2026 10:31:09 +0000

For a single line in a monospace font, CSS can do this on its own: animate the element's width from zero to the length of the text in ch units, use steps() with the same number so it grows one character at a time, and let a right border be the cursor. Copy the first block below. If your font isn't monospace, the text needs to wrap, or someone else will be editing the words, skip to the per-letter version.

The copy-paste version

<p class="typing">Ship it before the coffee cools.</p>

.typing {
  width: 32ch;                 /* characters in the line, spaces included */
  white-space: nowrap;
  overflow: hidden;
  font-family: ui-monospace, Menlo, Consolas, monospace;
  border-right: 0.1em solid;   /* the cursor */
  animation:
    typing 3.2s steps(32),
    blink 0.75s step-end 6;
}
@keyframes typing { from { width: 0 } }
@keyframes blink { 50% { border-color: transparent } }

@media (prefers-reduced-motion: reduce) {
  .typing { animation: none; }
}

When you change the text, change two numbers. width and steps() both have to equal the character count, and spaces and punctuation count too. "Ship it before the coffee cools." is 32 characters, so it's 32ch and steps(32). The duration is up to you; 100 ms per character (3.2s here) reads as quick but human.

How steps() makes it type

Without steps() the width would grow smoothly and you'd see letters slide in half-cut. steps(32) splits the 3.2 seconds into 32 equal jumps, and because every glyph in a monospace font is exactly 1ch wide (ch is the width of the "0" glyph), each jump uncovers exactly one character.

The second argument of steps() decides where each jump lands. It defaults to end, so nothing shows for the first 100 ms and the last character appears right as the animation ends. steps(32, jump-start) shows the first letter immediately, which feels snappier if the line is the first thing on the page. The cursor uses step-end for the same reason: the border switches between visible and transparent instead of fading.

Why ch and not width: 100%

The CSS-Tricks snippet from 2016, still the top result for this search, animates to width: 100%. A percentage width is a share of the parent, so in an ordinary block container 100% means the whole column, and the cursor keeps travelling long after the text has ended. When I ran it in a normal page, the cursor stopped about 600px to the right of the full stop. It works in their demo because the container there is sized by the text (their notes say the demo relies on flexbox), so 100% of the parent happens to equal the text. Animating to 32ch doesn't depend on the parent at all, which is why I'd use it.

What goes wrong with the classic version

Swap the font for anything proportional and it breaks in two ways at once. A "W" is far wider than an "i", so the 1ch jumps no longer line up with letters and you get characters cut through the middle while it types. And 32ch is no longer the width of the text: with Georgia, the same code finished with the cursor parked about 180px past the end of the sentence.

On phones, the same white-space: nowrap that keeps the reveal on one line means the line can never wrap. At 28px that sentence is about 540px wide; on a 375px phone the end of it is simply cut off. You can shrink the font with a media query, but a longer headline will hit the same wall.

And it doesn't survive editing. The moment a client edits the headline in a CMS, the character count is wrong and the cursor either stops early or overshoots. If anyone other than you will touch the words, use the next version.

Any font, any length, any number of lines

Instead of uncovering a box, put every letter in its own span, hide them all with visibility: hidden, and reveal each one after a delay of its index times the speed. Hidden letters still take up their space, so the browser lays out the finished text before anything appears: lines wrap where they normally would, and nothing jumps when the last word lands. There's nothing to count and no font restriction.

<h1 class="type">Any font, any length, and it wraps onto as many lines as it needs.</h1>

.type { --speed: 55ms; }

.type .ch {
  position: relative;
  visibility: hidden;
  animation: show 0s calc(var(--i) * var(--speed)) forwards;
}
.type .ch::after {               /* the cursor, shown on the newest letter */
  content: "";
  position: absolute;
  top: 0.15em;
  bottom: 0.1em;
  right: -0.06em;
  width: 0.06em;
  background: currentColor;
  opacity: 0;
  animation: caret var(--speed) calc(var(--i) * var(--speed));
}
.type .ch:last-child::after {
  animation: blink 1s calc(var(--i) * var(--speed)) step-end 4;
}
@keyframes show  { to { visibility: visible } }
@keyframes caret { from, to { opacity: 1 } }
@keyframes blink { 0%, 50% { opacity: 1 } 50.01%, 100% { opacity: 0 } }

@media (prefers-reduced-motion: reduce) {
  .type .ch,
  .type .ch::after { animation: none; visibility: visible; }
}

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

The cursor is a thin ::after bar on each letter that's only visible during that letter's own slot, so it always sits after the newest character, including at the start of a new line. The last letter keeps it and blinks four times.

Something has to write those spans, and for that I use a short script. It doesn't animate anything; it splits the text once, keeps a full copy for screen readers, and hands the timing back to CSS. If the script never runs, the heading just shows as normal text.

for (const el of document.querySelectorAll(".type")) {
  const text = el.textContent.trim().replace(/\s+/g, " ");
  const label = document.createElement("span");
  label.className = "sr-only";
  label.textContent = text;
  const shown = document.createElement("span");
  shown.setAttribute("aria-hidden", "true");
  [...text].forEach((char, i) => {
    const s = document.createElement("span");
    s.className = "ch";
    s.style.setProperty("--i", i);
    s.textContent = char;
    shown.append(s);
  });
  el.replaceChildren(label, shown);
}

Dropping the script with sibling-index()

If your templates already output one span per letter (a static site generator can do this at build time), CSS can number them itself. sibling-index() returns an element's position among its siblings and, according to MDN, has worked in all major browsers since August 2026. Registering --i as an integer makes it resolve on the letter and pass the number down to the cursor. Replace the inline --i with this:

@property --i { syntax: "<integer>"; inherits: true; initial-value: 0; }

.type .ch { --i: calc(sibling-index() - 1); }

I tested this in Chrome only. Older browsers ignore it, so the letters simply appear together, which is an acceptable fallback.

Screen readers and reduced motion

The classic version is easy here: the text is in the page the whole time, just clipped, so a screen reader reads the full line whatever the animation is doing. The per-letter version isn't. Some screen readers announce a run of single-letter spans as separate letters, which is why the script hides the animated copy with aria-hidden="true" and adds a visually hidden copy of the sentence. I used a hidden span rather than aria-label because ARIA doesn't allow naming plain p and span elements, and a hidden span works on any element. In Chrome's accessibility tree the heading above comes out as the single sentence.

Both versions include a prefers-reduced-motion block that shows the finished text straight away. Notice too that neither cursor blinks forever. WCAG 2.2.2 asks for a way to pause anything that moves or blinks for more than five seconds next to other content, and a cursor blinking under your headline counts. Giving the blink an iteration count (6 × 0.75s, 4 × 1s) keeps it under five seconds, which is simpler than adding a pause button. The same rule applies to the typing itself, so a paragraph that takes ten seconds to type out is a problem twice over.

When to stop using CSS

Once you want words that type, delete themselves and get replaced ("We build websites / apps / stores"), CSS can still do it: Temani Afif's version stacks the phrases in a grid and slides between them. But the phrase count is baked into three linked numbers, and you can't hold one word longer than another. A short script is easier to change; the JavaScript typing animation guide has a tested version with backspace, plus what typed.js and TypeIt cost for commercial sites now.

And there are places where neither runs. Can I Email estimates that only about a third of email clients support @keyframes (their data was last tested in 2021). GitHub READMEs strip styles, and Notion pages and Google Slides have no CSS at all. In those places the same effect works as an image. The typing text GIF maker renders this exact animation, cursor included, as a GIF or animated PNG, so the effect looks the same in an email signature as it does on your site.

Originally published at typingtextgif.com. The GIF renderer mentioned above is open source: fancydirty/typing-text-gif.

Inside Phantom Blade Zero's PBZS v3 Save Format (AES-256-GCM + Oodle Kraken in the Browser)

Crane Zhou — Tue, 03 Nov 2026 12:42:38 +0000

Most Unreal Engine 5 action RPGs on PC drop your save files into %LOCALAPPDATA%\<ProjectName>\Saved\SaveGames\. If you go looking there for Phantom Blade Zero, all you'll find is GameUserSettings.ini and shader caches.

While building a client-side browser save editor and starter-save archive at phantombladezerosaves.com, we had to document where the Steam build actually writes PBZSaveGame.sav and how its custom PBZS v3 binary container seals and compresses slot records. Here is a breakdown of the format and the two quirks that trip up standard WebCrypto and compression libraries.

1. Where Steam Actually Stores `PBZSaveGame.sav`

Instead of your Windows user profile, Phantom Blade Zero writes saves directly inside the Steam library folder next to the game installation:

<SteamLibrary>\steamapps\common\PBZ\ProjectPBZ\Saved\SaveGames\Steam\<17-digit-SteamID64>\PBZSaveGame.sav

Inside that 17-digit folder sit four items:

PBZSaveGame.sav — a single archive holding all manual slots, autosaves, and your account wardrobe.
1RealTime\, 2Hourly\, and 3Daily\ — automatic rolling backup directories rotated by the game while you play.

One useful discovery from decrypting the container: neither the outer directory nor the inner slot JSON stores your 17-digit SteamID64. The number only names the folder on disk. That means any valid PBZSaveGame.sav can be dropped into your own SteamID64 folder and loaded at the Bell checkpoint without re-signing an account ID (see our Steam save location & backup guide and account transfer walkthrough for the Steam Cloud sync ordering).

2. The 12-Byte PBZS v3 Header

Only the first 12 bytes of PBZSaveGame.sav are stored in cleartext:

Offset	Size	Type	Meaning
`0x00`	`4 B`	ASCII	Magic bytes `PBZS` (`50 42 5A 53`)
`0x04`	`1 B`	`uint8`	Container version (`3` in Steam build `26266538`)
`0x05`	`1 B`	`uint8`	Flags (`1`)
`0x06`	`2 B`	`uint16 LE`	Total number of slot records in the archive
`0x08`	`4 B`	`uint32 LE`	Byte length of the encrypted directory block starting at offset `12`

Because the header gives you both slotCount and directorySize, you can verify whether a file is an intact PBZS v3 archive without having the decryption key: 12 + directorySize must land on a sealed block boundary, and walking slotCount blocks from there must reach EOF with zero trailing bytes.

3. Quirk #1: Out-of-Line AES-256-GCM Authentication Tags

Immediately after byte 12 sits the directory block, followed by one sealed block per save slot (__Advanced__, __Achievements__, AutoSave0, ManualSave1, NightmareRun0, etc.). Every sealed block shares a 36-byte preamble:

PBZS 01 01 00 00 (8 B)  |  nonce (12 B)  |  GCM tag (16 B)  |  ciphertext (N B)

Most crypto APIs — including browser WebCrypto (crypto.subtle.decrypt) — expect the 16-byte AES-GCM authentication tag to be appended to the end of the ciphertext (ciphertext || tag). PBZS v3 stores the 16-byte tag before the ciphertext at bytes 20..36.

To decrypt a block in the browser with WebCrypto, you slice the 12-byte nonce from 8..20, copy ciphertext (36..end) followed by tag (20..36) into a contiguous Uint8Array, and pass that buffer to crypto.subtle.decrypt({ name: 'AES-GCM', iv: nonce, tagLength: 128 }, key, combined).

If the key is wrong or a single byte was corrupted in transit, GCM authentication fails immediately before touching the payload.

4. Quirk #2: Oodle Kraken Slot Payloads vs. `zlib` Re-Encoding

Decrypting the directory block reveals a packed table of slot entries:

uint16 nameLen | name (UTF-8) | uint8 algorithm | uint8 flag | uint32 rawSize | uint32 offset | uint32 blockSize

The algorithm byte specifies how each slot's UTF-8 JSON was compressed prior to encryption:

0 — Uncompressed raw bytes
1 — Standard zlib deflate stream
2 — Oodle Kraken

Every native save written by the game uses algorithm = 2 (Oodle Kraken), but the game's loader natively accepts algorithm = 1 (zlib) as well. That makes a pure browser editor practical: we ship a compiled WebAssembly Oodle Kraken decoder (ooz.wasm) to decompress native algorithm = 2 slots in the tab, modify only the touched JSON keys, and re-pack modified slots with zlib while copying untouched slots through with their original ciphertext byte-for-byte intact.

Full byte-level notes live in the PBZS v3 Format Specification and the open-source verifier repo at github.com/fancydirty/phantom-blade-zero-save-format.

5. Inside the Slot JSON: The `+1` Weapon Grade Offset

Once a slot is decompressed, the payload is clean UTF-8 JSON:

Player.Dust holds your currency balance as a standard signed integer.
Inventory.InventoryInfos maps material and goods IDs (such as Weapon_Material_* and Medi_Material_*) to { CurrentAmount, MaxAmount }.
Inventory.MainWeaponInfos and Inventory.ShaChiWeaponInfo store weapon ownership and upgrade levels.

One detail that catches manual JSON editors off guard: weapon grades are stored one higher than the +n shown in the game's UI. An un-upgraded base weapon (+0) is stored as 1 (or omitted), and the first-cycle ceiling of +7 is stored as 8. Outfits are stored globally inside the __Advanced__ slot rather than inside individual manual saves. We published the full mapping of internal string keys to English and Chinese names on the Phantom Blade Zero Item IDs page.

Try the Local Browser Save Editor or Starter Saves

If you want to inspect or edit your own PBZSaveGame.sav without installing desktop trainers or Cheat Engine tables (which frequently break when a Steam hotfix shifts memory pointers — see our Save Editor vs. Trainers comparison):

Phantom Blade Zero Browser Save Editor — runs 100% locally in your browser tab via WebCrypto and WASM; no files are ever uploaded.
Cycle 1 All-Weapons Starter Save, Cycle 1 Max Dust & Materials Save, and Cycle 10 & 66 Days Mode Save — decrypted, verified against Steam build 26266538, and published with SHA-256 hashes.

DEV Community: Crane Zhou

A site that has to change at midnight: daily data with GitHub Actions and static hosting

Why "Optimized" GIFs Turn Into Haunted Sprite Sheets (And 4 Tiny Canvas Fixes for 2D Game Devs)

1. Reconstructing "Optimized" GIFs Without Ghost Limbs

2. Cutting Uneven & AI-Generated Sheets (Edge Flood-Fill + Proximity Join)

Pass A: Border-seeded flood fill (so black outlines survive a dark backdrop)

Pass B: Proximity box merging + foot anchoring

3. Scaling Pixel Art Without Turning It to Soup (EPX in 15 Lines)

4. Why canvas.toBlob() Chokes on 200-Frame ZIP Exports

Single elimination, double elimination or round robin: pick by the numbers

What one SeniorMatch account saw free and paid, on the same day

The test

What paying actually changed

What it does not change

How to use that if you are deciding

Measuring reaction time in the browser: six things that went wrong

3 Weird Bugs I Hit Rendering Typing-Text GIFs in Plain Canvas (Clipped g's, 1-Bit Halos, and Classic Outlook)

Bug #1: fontSize is a lie (why g and y lose their tails)

Bug #2: The 1998 GeoCities Halo on Transparent GIFs

Bug #3: Classic Outlook Only Ever Sees Frame 0

Bonus: Fake Typewriter Ink That Doesn't Flicker

The Weirdly Petty Engineering Behind Printing a Straight Barcode Sticker

1. The 203 DPI Thermal Head Math Problem (Why "Clean Vector" Still Bleeds)

2. The "Helpful" Truncation Bug That Prints Someone Else's Barcode

3. Why Your PNG Barcode Looks Giant When Pasted Into Word

4. Word Templates Lie About Row Height (and Seller Central Wastes 60% of Your Sheet)

The Lesson: Screenshots Lie, Decoders Don't

What makes a custom Yu-Gi-Oh! card look real

What goes on a card, part by part

Pick the frame before anything else

Stats that look right for the Level

Writing an effect that reads like a real one

Getting artwork and printing it

What goes wrong

CSS sprite sheet animation: getting steps() right

Why steps(N) ends at the full sheet width

A sheet with more than one row

Scaling up without blur

Making it responsive

Play once, reverse, pause on hover

Respect reduced motion

Canvas, for per-frame timing or many sprites

What goes wrong

Sprite sheet, GIF or video?

Reading Phantom Blade Zero's PBZS v3 save container in the browser

Where the file lives

The 12-byte header

Sealed blocks: the tag comes first

Compression: Oodle Kraken in the browser

The key is a per-build constant

What is inside a slot

The result

CSS typing animation: a typewriter effect that survives any font, any length and line wraps

The copy-paste version

How steps() makes it type

Why ch and not width: 100%

What goes wrong with the classic version

Any font, any length, any number of lines

Dropping the script with sibling-index()

Screen readers and reduced motion

When to stop using CSS

Inside Phantom Blade Zero's PBZS v3 Save Format (AES-256-GCM + Oodle Kraken in the Browser)

1. Where Steam Actually Stores PBZSaveGame.sav

2. The 12-Byte PBZS v3 Header

3. Quirk #1: Out-of-Line AES-256-GCM Authentication Tags

4. Quirk #2: Oodle Kraken Slot Payloads vs. zlib Re-Encoding

5. Inside the Slot JSON: The +1 Weapon Grade Offset

Try the Local Browser Save Editor or Starter Saves

3. Scaling Pixel Art Without Turning It to Soup (`EPX` in 15 Lines)

4. Why `canvas.toBlob()` Chokes on 200-Frame ZIP Exports

Bug #1: `fontSize` is a lie (why `g` and `y` lose their tails)

1. Where Steam Actually Stores `PBZSaveGame.sav`

4. Quirk #2: Oodle Kraken Slot Payloads vs. `zlib` Re-Encoding

5. Inside the Slot JSON: The `+1` Weapon Grade Offset