Fix texture sampling calculations for CPU pipeline #479

Previously, the `color-touching-tests.sb2` test "touches a color that doesn't actually exist right now" would use a sprite with ghost 50, blended against another sprite, to create the color that "doesn't actually exist" when the query sprite is skipped. Unfortunately the blend result was near a bit-boundary and, depending on the specific hardware used, that test could fail on the GPU. When the renderer uses the CPU path this test works fine, though, so the existing problem went unnoticed. To fix the problem I changed the project to use ghost 30 instead, which results in a color that is less near a bit boundary and is therefore less likely to fail on specific hardware. As an example of what was happening: the `touching color` block was checking for `RGB(127,101,216)` with a mask of `RGB(0xF8,0xF8,0xF0)`. On the CPU it would find `RGB(120,99,215)`, which is in range, but on some GPUs the closest color it could find was `RGB(119,98,215)` which mismatches on all four of the least significant bits -- one of which is enabled in the mask.

Fix direction for Y iteration on CPU path For some reason the JavaScript engine insists on running the code instead of doing what the comment says. I guess they should match. Fix (x,y) => point[] conversion comments

This should ensure that CPU/GPU diffs are actually useful, and not improperly shifted.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix texture sampling calculations for CPU pipeline #479

Fix texture sampling calculations for CPU pipeline #479

Commits on Mar 3, 2024

Fix texture sampling calculations for CPU pipeline #479

Are you sure you want to change the base?

Fix texture sampling calculations for CPU pipeline #479

Commits on Mar 3, 2024