Pixel-Perfect by Construction

A story about awkward ratios, symbolic case lattices, and why integers still win

There’s a moment in every graphics engine where you think:

“This is probably correct.”

And then there’s the moment when you know it is.

This week I crossed that line.

PixelPlex — my integer-based, symbolically-specialized blitting engine — just passed 100% of its full combinatorial verification space. Not a friendly subset. Not “typical sizes.” The whole thing.

Including the awkward ones.

Including the ones that normally hide rounding bugs.

Including the ones that only fail when clip regions, scaling ratios, and thread slicing line up just wrong.

And that didn’t happen by accident.

The problem with “it looks right”

Graphics code is deceptive.

You can scale an image, clip it, render it, and everything looks fine. But visual correctness is a weak signal. Your eye is very forgiving — your GPU less so — and your users least of all.

Most image engines rely on floating point math and hope rounding error behaves.

PixelPlex does not.

PixelPlex uses a fully integer Digital Differential Analyzer (DDA) to map destination pixels to source pixels. No floats. No drift. No platform variance.

That gives you deterministic scaling:

sx = floor(dx * sd / dd)

But writing that formula is easy.

Making it correct under:

clipping
arbitrary ratios
multithreading
upside-down coordinate systems
and seam slicing

…is not.

Enter the awkward sizes

Friendly ratios like 512 → 256 hide bugs.

But 817 → 490 does not.

Neither does:

1361 → 816
817 → 1361
490 → 816
1361 → 490

These sizes create remainder patterns that force your DDA to make hard decisions:

when to carry
when to increment
when to skip

If your phase is wrong by even one step, the error shows up deep in the image — not at the edges.

That’s where most blitters quietly fail.

The idea: encode the source coordinates into the pixels

Instead of guessing whether a pixel came from the right place…

I encoded the source coordinates into the pixel values themselves.

Each source pixel contains:

R = x low byte
G = x high byte
B = y low byte
A = y high byte

So after a blit, I can decode every destination pixel and ask:

“Where did you come from?”

No heuristics. No image diffing. Just math.

But random testing isn’t enough

Random fuzzing is great for exploration.

But I wanted proof.

So I built something new.

CaseSpace: turning combinatorics into a lattice

PixelPlex has multiple dimensions:

source shape (Square / Wide / Tall)
destination shape
width relation (< = >)
height relation (< = >)
source rectangle
clip mode

That’s not a list. That’s a space.

So I built CaseSpace — a mixed-radix symbolic case generator.

Each dimension becomes a digit.

Each digit has its own alphabet.

Each combination gets a unique integer ID.

So instead of:

“Sometimes this breaks…”

I get:

“CASE 405 failed. Re-run with id=405.”

That changes everything.

The first run: friendly sizes

With power-of-two sizes, everything passed.

Good sign — but not proof.

The second run: awkward ratios

That’s where things got interesting.

I started seeing failures like:

expected (205,203) but got (204,203)
CASE 405: srcShape="Square" dstShape="Square" wRel="<"; hRel="<"; srcRect="Whole" clip="Within"

One pixel off.

Only in X.

Only under certain ratios.

Only inside the image.

That’s exactly the kind of bug that ships.

The real culprit: a missing phase seed

After instrumenting both the expected DDA and the runtime DDA, the answer became obvious:

The slice engine was resetting the X remainder to zero at thread boundaries.

So the carry schedule shifted.

Which meant the source coordinate drifted.

Which meant the wrong pixel was sampled — but only at certain columns.

It was invisible unless you looked for it.

One line fixed it:

se.x := P.se.x;

That was it.

But without CaseSpace, I would never have found it.

The final run: full lattice

With the fix in place, I ran the entire CaseSpace lattice.

All shapes.
All ratios.
All clip modes.
All threading paths.

And it passed.

100%.

Every pixel mapped exactly where the math said it should.

Seams aligned.

Threads agreed.

Remainders propagated correctly.

No drift. No cracks. No ghosts.

Why this matters

Most image engines rely on:

floating point math
heuristic testing
visual inspection
and hope

PixelPlex now relies on:

integer math
symbolic specialization
deterministic mapping
and formal verification

It behaves like a GPU rasterizer — but runs on the CPU.

And it proves its own correctness.

Closing thought

This wasn’t just a bug fix.

It was a demonstration of a philosophy:

If your system has structure, you can enumerate it. If you can enumerate it, you can verify it. If you can verify it, you can trust it.

And sometimes, the fastest way to perfect an image engine…

…is to teach it how to count.

CaseSpace: Deterministic Combinatorics for Testing Without Randomness