Skip to content

v1.4.0 — exact odds, and a canvas you can zoom

Choose a tag to compare

@corderro-artz corderro-artz released this 15 Sep 06:23
· 17 commits to main since this release

Two features and a fix to the harness. 2,219 tests, 0 failures.

The combined chance is exact now, when the CookBook is at hand

The Set browser's this combo 1 in N was the product of the rarity rows above it, and
that is an estimate twice over: it assumes the layers roll independently, and it is
built from the shares this Set happened to produce rather than from the weights the
book asked for.

CookBookLocator already finds a Set's book by hash — so a folder of a dozen books
produces no answer rather than a wrong one — and SelectionOdds (in Core, so the CLI
and the GUI cannot disagree) prices an asset from it. Generation is rejection sampling,
so the correction is the whole feature:

           w_r/W  ×  P(layers)
  P  =  ------------------------------------------------
         SUM over recipes of  w/W  ×  P(it rolls legal)

The denominator sums over the whole book, not one recipe, because a rule violation
throws the recipe roll away too. With no rules anywhere it is exactly 1 and the figure
reduces to the product — which is the right relationship between the two: the estimate
is this model with its correction dropped.

On the test book, whose background rolls 70/30 and whose aura rolls 60/40 with a rule
excluding one pair, the surviving combinations are worth 47.73%, 31.82% and
20.45%. Multiplying the Set's own twelve-asset shares says 48.61%.

Giving up costs a direction, not the answer: every legal mass is at most 1, so a book
too large to walk reports the numerator as a true floor — at most 1 in N — rather than
a guess. And it reads the book as manifests alone (ArchivePeek.CookBookTree),
because a probability is a few dozen weights and a full read would pull every variant
PNG in the collection into memory to reach them.

Without a book beside the Set nothing changes except honesty: the figure carries a ~
and its tooltip says what it assumed.

The canvas zooms and pans

An 8px sprite in the editor's tile is forty device pixels to the art pixel. A 512px
drawing in the same tile is under two thirds of one — finer than the backdrop will even
draw a lattice at.

  • Wheel to zoom, anchored on the pointer.
  • Middle-drag, or the arrow keys, to pan.
  • + / - / 0, and a chip at the corner of the canvas whose label is the current
    zoom and whose click is fit.

The zoom exists in exactly one function — the one the pointer, the marquee and the
backdrop lattice are already mapped through — so the pixel you click is the pixel you
paint, and the lattice stays in phase with the art, at every magnification.

The editor opens in the view you left

The pixel grid, its step, the preview tile's size and which half of the rail is showing
are remembered between sessions. An author who paints 16px sprites on an 8px lattice was
setting that on every layer they opened.

Zoom and pan are deliberately not remembered — they belong to the image, and opening
an unrelated layer magnified and panned into a corner is a lost canvas rather than a
restored preference.

And four screenshots that were of the wrong thing

The harness's four REFERENCES frames reached that panel by scrolling the colorize rail
to its end. Splitting the rail into two tabs moved the panel out of that scroller and
the scroll became a no-op — leaving four frames named refs, every one a picture of the
colorize rail, with the tab bar beside them announcing "REFERENCES 3/5" about a panel
nothing showed. Nothing failed, because a capture asserts nothing. It asserts this much
now.

Downloads

Size .NET 10 needed
Portable 84 MB no — unzip anywhere and run. Start here if you are unsure.
Single file 76 MB no — one .exe. Unpacks itself on first run, so that launch is slower.
Single file, .NET 14 MB yes — one .exe, runtime left out.
Framework-dependent 14 MB yes — the same, as a folder.

The two .NET builds need the .NET 10 desktop
runtime
; the other two carry everything.