Files
Going-Commando/crates
ReaperOfVeriod f0bc1fbdf4 State which GS rules are wired and which are not
A small doc change with a specific reason.

gc-engine's sampler sat behind a comment claiming it clamped while the code was
`..default()`, which is Repeat. That was caught only because I went looking for
where clamp01 should be used and found the answer was "somewhere that already
claims to do it". The generalisable failure is a reader seeing a rule defined in a
module called gs.rs and assuming the renderer applies it.

So the module now says which rules are wired and which are not:

    CLAMP wrap           yes    gc-engine image_of sets address_mode_u/v
    alpha 0x80 opaque    yes    texture::scale_alpha delegates here
    blend / alpha test    no    bevy AlphaMode cannot express both at once
    mip selection         no    only level 0 is decoded, mip_level is always 0

The last row is the one worth having written down. mip_level is a correct,
tested function that returns 0 for every input the renderer can currently give it,
and nothing in the code says so. It will start meaning something the day multi-level
textures are decoded, and until then it is indistinguishable from a mip selector
that works. That is the same shape as the sampler: a specific, plausible, untested
claim about behaviour sitting where nobody will re-check it.

passes_alpha_test and BlendMode are reference -- correct and tested, but not on the
draw path, and per 43e508a not expressible there in bevy's current enum. Saying so
is better than leaving them looking like pending integrations.

No behaviour change. 278 tests, clippy clean.
2026-10-14 04:46:16 +02:00
..