Under certain circumstances, sampling from a texture atlas cell will sample the neighbouring cell, causing a distinctive fuzzy line on the very edge of the sprite.
This is caused when the neighbouring cell has data in the outermost row/column of pixels. When the shader samples a texel with non-integer coordinates, it can interpolate partially into that data. Non-integer texel coordinates occur when the game object is scaled, rotated, or moved to non-integer coordinates.
The contributing factors are both common:
Cells without gutters (1-pixel empty margins are difficult to create with TextureAtlas JSON, and potentially impossible with SpriteSheet objects)
Free movement of assets/cameras
There are solutions, but they're not optimal:
Add gutters to all assets (this may introduce transparent glitches into tiling surfaces)
Lock transforms to integer translation and scale and right-angle rotations only (potentially jagged)
Use NEAREST texture interpolation instead of LINEAR (this doesn't necessarily work, either)
I've tried messing about with the shaders, but it's not great. It turns out that texel coordinates don't give up interpolation without a fight.
This merits documentation and further investigation.
Under certain circumstances, sampling from a texture atlas cell will sample the neighbouring cell, causing a distinctive fuzzy line on the very edge of the sprite.
This is caused when the neighbouring cell has data in the outermost row/column of pixels. When the shader samples a texel with non-integer coordinates, it can interpolate partially into that data. Non-integer texel coordinates occur when the game object is scaled, rotated, or moved to non-integer coordinates.
The contributing factors are both common:
There are solutions, but they're not optimal:
I've tried messing about with the shaders, but it's not great. It turns out that texel coordinates don't give up interpolation without a fight.
This merits documentation and further investigation.