An unqualified float uniform takes each stage's default precision, and
those differ -- highp in the vertex stage, mediump in the fragment one.
LOVE 11 linked the pair regardless; LOVE 12 requires both declarations to
carry the same qualifier and refuses the shader:
Cannot compile shader: ERROR: Linking fragment stage: Precision
qualifiers must match: vertex stage: fireflyNight "" fragment stage:
fireflyNight ""
Voxel3D.available() is 'the scene shader compiled', so the refusal takes
the whole 3D pass with it and the overworld silently falls back to flat
2D. That is the current state on iOS, whose shell ships LOVE 12, and it
is latent for every other platform that moves to 12.
Uses LOVE_HIGHP_OR_MEDIUMP, the same macro vWorld and vGrid already carry.
Armed on the occupant-change edge, which happens while the screen is still
mid-wipe -- so the burst spent its whole three-quarter-second life underneath
it. The instrumentation is what settled it: armed=1, quads=450, which is
45 frames times 10 stars, exactly LIFE. It was never missing. It was drawing
where nobody could see it.
Two gates, because the first one was still wrong. Holding the clock until the
scene DREW the side does not help: the battle renders under the wipe for
about a second before the wipe is gone. The burst now waits until the battle
is the top of the stack -- the wipe popped, somebody watching -- and only
then starts. Armed and released are separate moments now, which is what they
always were.
Also, a shiny no longer discolours a PERSON. Both sides can be holding a
trainer pic rather than a Pokemon (the foe's portrait before the send-out,
the player's own back until "Go!"), and the tint was going straight through
it. Shininess is a fact about a Pokemon, not its owner. sideTexture asks the
same two questions it already used to label the finished texture.
And the capture drivers build the party BEFORE pinning the odds. Pokemon.new
is where shininess is decided, so setting odds to 1 first made the player's
own Pikachu shiny too -- which tinted the player's side, which during the
intro is the trainer sprite. That is what "the player trainer sprite seems
discolored" was.
Lineup is now Charizard, Electrode, Vaporeon, Dratini.
Verified by strip: the burst lands in the frames right after the wipe clears,
and the trainer back sprite is its own colour again.
Flat numbers cannot work here and both previous attempts proved it in
opposite directions. The first ring was 7 world units across, which is inside
anything bigger than a Rattata -- and additive drawing keeps the depth test,
so all sixty quads a frame were rejected and nobody saw them. Correcting by
eye gave a ring 24 across starting 20 units up, which is taller than the
tallest Pokemon in the game: it hung in the sky above a Ponyta with nothing
underneath it.
A mon on the map is 5 to 18 world pixels tall (StadiumMon REF_HEIGHT 14). One
ring cannot fit a Diglett and a Gyarados, so every distance is now a fraction
of the mon: Stadium pushes each side's worldHeight and worldRadius into
ShinyFx every frame -- worldRadius exists precisely so "a caller can size
something to its footprint" -- and the burst is measured off those.
Two more things the pictures showed. The ring is an ELLIPSE with its axes
measured separately: flattened enough to read as a ring from the battle's low
seat, a single radius reaches only a third of the body's height, so the top
and bottom stars sit on the Pokemon. And it OPENS from clear of the body
rather than from a point -- springing out of nothing means every star spends
the first frames stacked at the centre, which is the middle of the mon and
looks exactly like the sparkles being stuck inside it.
Shot against Ponyta and Gyarados, an order of magnitude apart in size: the
ring hugs each silhouette from outside and no star lands on either body.
It did not. pending() short-circuited on available(), and available() was
true for any checkout carrying assets/stadium -- so when REV went to 3 for
the shiny variants, such a machine was never pending, was never asked to
rebuild, and quietly went on serving the old set. ready() was false, so
readPack skipped the save-dir cache and read the shipped normal-only packs:
every shiny Pokemon drawn in its ordinary colours, with nothing on screen
saying why. A driver run sitting at "idle 0/151" for twelve thousand frames
is what surfaced it.
pending() is now keyed on ready(), not available(). A checkout with a ROM
spends one loading screen rebuilding a set it had files for; after that it is
current and never pending again. That was the cost the old short-circuit was
avoiding, and it is worth paying once to make a rev bump mean something.
The other half is the players who imported a ROM through the picker rather
than dropping it in baseroms/. beginFrom builds from the bytes and never
keeps them, so on a rev bump there is no ROM to rebuild from -- and with
available() keyed on ready(), the STADIUM rungs would have vanished off the
options row entirely. usable() now separates "these packs are readable" from
"these packs are current": format and count, deliberately not rev. Stale
packs keep the mode working and keep the rungs offered; only the recolour
waits for a rebuild. Losing the shinies until then is a blemish, losing the
mode is not.
readPack orders the two accordingly: a current cache always wins, a stale one
wins only when there is no shipped set to prefer instead -- so a cache from
an extractor rev we have since fixed cannot shadow good files, while a player
whose only copy IS that cache still gets Pokemon on the field.
Verified by rolling the marker back to rev 2 and launching: ready=false,
usable=true, available=true, pending=true, and the build runs unprompted.
The texel transform is wrong for palettes, and silently so. A lookup table
answers only the colours it contains -- the ones its MODEL is painted with --
and the engine's ADVANCED palettes are a different set entirely: BLUEMON's
blue is not any blue on the Gyarados model. Asked to shift a palette, the
table returned it unchanged, so the five table species produced no sprite
shift at all and the most dramatic shiny in the game came out identical.
paletteTransform picks the right tool per species: the slide where there is
one, the tint multiplier (which IS derived from the table) where there is
not. 149 of 151 palettes now move; the two that do not are Jigglypuff and
Wigglytuff, whose shiny genuinely leaves the body almost where it was.
Plus the two tools that make the comparison sheet. Worth saying why it is a
palette job at all: Gen 1 battle pics carry no colour -- they are four-shade
DMG grey, and every bit of colour is the palette laid over them. So a shiny
sprite is the same pixels under a shifted palette, and a sheet built any
other way would be showing something the game never draws.
Sheet at .claude/shiny_update/7_sprites_all151.png, every species beside its
own control.
Four things, all found by shooting the feature rather than by reading it.
The flat-pic tint was a no-op for the five colour-table species. tintFor ran
synthetic reference colours through the lookup, none of them were IN it, so
every ratio came back 1 and the tint was discarded -- a shiny Gyarados drew
an ordinary blue pic. Those species now measure the tint from the table's own
entries.
It was also a no-op for most SLIDE species, for a better-hidden reason: a hue
rotation moves red toward cyan and cyan toward red, so averaged over a
balanced set of references the ratios cancel and every species reports no
tint. Charizard and Ponyta both came back neutral. The tint is now measured
against the colour each species is actually MADE of -- a modal body colour,
generated into data/shiny_colors.lua as `dom`. 132 of 151 now carry a usable
tint; the rest genuinely shift too little for one to mean anything.
The sparkle drew sixty quads a frame that nobody could see. It was built to
numbers a tenth of the scale of a mon card -- a ring seven units across,
inside a Gyarados -- and additive drawing keeps the depth test, so all of it
was rejected. Sized against the card now, and pulled toward the camera the
way the move-animation card is.
And the summary PIC cannot be recoloured by touching pixels: the art is
four-shade DMG grey and the colour is applied afterwards by the palette pass.
That attempt is reverted, with the reason left where the next person will
look for it. The star is the designation that works there.
Also: tools/shiny_colors.py now resolves its own paths instead of hardcoding
a worktree, and the extract test gained a hard failure when NOTHING
recolours -- which is what a missing colour table looks like from the
outside, and it passed through it once already.
Evidence in .claude/shiny_update, every case beside its own control.
Shiny Pokemon: derived from DVs via the engine's own Stats.isShiny, models
recoloured as part of the Stadium extraction, flat art tinted, a sparkle on
arrival and a star on the status page.
Verified on the merged tree rather than only on the branch, since
shadow-toggle moved underneath it (the new menus work): the mod loads clean,
tests/shiny_test passes 49, and the extraction still reproduces all 151
packs byte-for-byte against the Python oracle with 151 shiny variants
alongside.
ShinyPalette loaded data/shiny_colors.lua by guessing cwd-relative paths
when V.data was absent, which is the headless case. Run from the project
root, none of the guesses hit -- so the extraction built all 151 species,
recoloured none of them, and reported PASS. The packs were correct; there
simply were no shiny variants in them, and nothing in the output said so.
Two fixes, because either alone leaves the trap open:
V.path is now consulted first, so the file is found relative to the MOD
the way every other resource is. The extract test's stub sets it to
whatever --mod it was given.
A count of zero recoloured is now a failure. That is precisely what a
missing colour table looks like from the outside, and a test that passes
on it is not testing the feature. It was caught by noticing the number
change between two runs that differed only in where they were started
from -- which is too thin a thread to hang it on.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Gen 1 has no shininess of its own, but it has the four DVs Gen 2 reads to
decide it -- and the engine already ships that reading (Stats.isShiny, its
own comment calling it "the RBY virtual shiny", allowlisted for mods
precisely so an indicator mod can call it). Nothing new is stored on a
Pokemon and nothing migrates: every save already contains the answer, and
this starts drawing it. Random DVs land on the pattern 1 in 8192, which is
the classic rate and the default the odds dial ships at.
Deriving rather than storing is what makes it survive a save, a box, a
trade and an evolution with no second copy of the truth to drift. mon.shiny
is a cache written from the DVs, never read as the source.
The roll goes in Pokemon.new -- every wild, gift, starter and traded mon is
built there, and it is before the battle bakes its sprite, which
battle.started is already too late for. It draws from the mod's own random
stream so installing this does not shift the sequence damage rolls and
encounter slots come out of. Trainers stay ordinary by themselves: the
engine pins their DVs, as the real games do.
The models are genuinely recoloured, as part of the extraction. Each
species is decoded once, packed as usual, then recoloured and packed again
as NNNs.dsm. The colours are Stadium's own HSL slide (hue in degrees,
saturation and lightness on a -8..+8 scale at 12.5% a step); five species
carry an explicit colour table instead, because Stadium gives them a real
alternate texture that no single slide reproduces -- Jigglypuff's body must
stay pink while its irises rotate to green.
Extraction is the right moment because StadiumFx's generated frames are
still marked there and the packer drops the marker: it is the last point a
flame is distinguishable from a hide. A shiny Charizard has a shiny hide
and an ordinary fire. The normal packs are written BEFORE the recolour, so
they come out byte-identical and stadium_extract_test still diffs all 151
against the Python oracle unchanged -- no format change, no DSM4, no second
implementation to keep in step. REV goes to 3 so an existing cache rebuilds.
Flat art is tinted instead, because the engine bakes a species palette into
a cache with no notion of which individual is drawn. The tint comes from
that species' own slide rather than a generic gold. A multiply can only
darken, so species whose shiny is lighter read quieter there than on the
model; the status page's star is the mode-proof mark.
Tests: 58 assertions in tests/shiny_test.lua, including the colour
transform against 640 real colour pairs lifted from the verified texture
set, the DV model, the read side, and the end-to-end through the engine's
own constructor. stadium_extract_test gains --mod (worktrees have neither
the ROM nor the packs, both gitignored) and now also checks that every
shiny pack is the same length as its twin and actually differs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A cliff mound is drawn as a rim over a body: its top edge, then the same
rock the whole way down. The top face cycles the first two drawn rows to
fill its depth, so it laid that rim again every second tile. The mound the
Diglett's Cave mouth is cut into came out with three rim lines across it
instead of one along its north edge.
Where the drawing says the body is all one tile, lay the rim once and hold
the body after it. Art that genuinely repeats keeps cycling: the Safari
Zone's fence alternates two tiles the whole way down, and there the repeat
is what the drawing says.
Answered per column and per region, because each catches what the other
misses. The columns carrying a mound's cave mouth end in the mouth's own
tiles, so per column alone they kept cycling while their neighbours held,
leaving rim stubs above the doorway. A region vote alone silences a real
rim-over-body column standing in a region of repeating art, of which the
Safari Zone has three. A column holds if either says so.
Geometry is untouched: the silhouette is pixel for pixel what it was, and
only the texel a top face wears changes. Of 3088 flat-topped runs, the
1336 rim-over-body ones change and nothing else does.
tests/flat_top_test.lua walks every map and fails if any rim-over-body run
revisits an earlier drawn row.
The hip ends of the gabled house and Oak's lab come out as black teeth
marching down the slope instead of battens running with it.
The depth->row map is authored for columns the drawing paints edge to
edge. A tapered column starts further down the band, and the surface was
clamped into its first DRAWN row to stay inside the silhouette -- but a
column's first drawn row is its silhouette CAP, and the cap is outline
black. On a tapered column the map spends most of the roof's depth above
that cap (seven of the gabled house's fifty depth voxels land on it
outright), so the clamp painted one outline pixel the length of the
slope and roofCycle beat against it: black punctuated by the real batten
colour every 4 rows on the house, every 8 on the lab.
Lift to the column's first PAINTED row instead -- the same refusal to
let outline black stand as a face that measure() already makes for the
side faces, which the roof band was never given.
Geometry is untouched: voxel, shell and recess counts are identical for
all 50 templates. verify_roof now asserts no roof surface samples its
column's cap, and tests/roof_cap_shots.lua shoots the two Pallet Town
drawings A/B.
The version bump and CHANGELOG entry are left out deliberately, so this
does not collide with the release flow.
DramaticShape
luisgonzaleznf
Davi D'artemis
Code-Grub
Alonso Avitia