Fix texture sampling calculations for CPU pipeline

[adroitwhiz]

Resolves

Resolves scratchfoundation/scratch-vm#2076, plus some of #214
Resolves scratchfoundation/scratch-vm#2077

EDIT: may fix scratchfoundation/scratch-gui#2860

Proposed Changes

Well, this is a bit of a weird one. The first change (snapping candidate bounds to ints) fixed the test project given in scratchfoundation/scratch-vm#2076, but when I created a test project, it still failed! The second change (changing silhouette sampling math) fixed the test project I added to the suite. While I'd prefer to separate it out, both changes are necessary to fully resolve the issue.

EDIT 2: I put some more work into this, and now, the CPU renderer is pixel-perfect, barring rounding differences and antialiasing.

This PR:

1. Changes _candidatesTouching, used for "touching sprite" queries, to expand the bounding boxes of all candidate drawables to integer coordinates, as is already done for the query drawable in _touchingBounds.
2. Changes Silhouette "color/point at position" functions to scale the point position back up by the silhouette's dimensions, instead of its dimensions - 1. This is because texture space goes from [0, 1] inclusive, not [0, 1) exclusive.
3. Offsets Drawable.getLocalPosition's input Scratch-space vector by 0.5, and texture-space vectors in Silhouette by -0.5, because OpenGL samples pixel centers at half-integer coordinates.
4. Changes Silhouette.getPoint and Silhouette.getColor to clamp their coordinates, matching the behavior of the GL_CLAMP_TO_EDGE behavior used in the GL renderer.
5. Moves the point-in-bounds check from Drawable.getLocalPosition to Silhouette.isTouching[Nearest/Linear] to support the "clamp to edge" sampling.
6. Updates the "cpu-render.html" test page to match the "index.html" test page, so that it will actually load projects. done in Attach V2 adapters in CPU render playground #484
7. Adds a black border around the stages in the "cpu-render.html" test page to make it easier to line the stages up in image editing software, especially if the backdrop is white
8. Re-enables linear silhouette sampling now that the math is correct. This would be better separated into another PR.

EDIT 2019-02-07:

9. Adds back in the alpha test in sprite.frag, but only in the silhouette draw mode. This was done by me some time in the past, but I can't remember when and the commits were squashed. This was apparently done in Use premultiplied alpha everywhere, take 2 #515.
10. Includes some commits from Adjust CPU isTouchingColor to match GPU results (again) #419:

• Adjust the loops in isTouchingColor to avoid testing extra edge pixels
• Iterate drawables in the same order on CPU & GPU
• Fix exception on first button click
• Add touching-color test to verify stencil use
• Run test projects in each GPU usage mode
• Make touching-color test more robust against GPU imprecision

11. Doesn't apply the ghost effect to isTouchingColor's drawable on the CPU path. This was already excluded in the GPU path, which made the existing color-touching-tests.sb2 test pass, but running tests on both the CPU and GPU reveals the issue.
12. Doesn't include text bubbles in "touching color" tests. An important note on compatibility: doesnt-touch-say-bubble is flaky, and should never have passed. As far as I can tell, ever since the release of Scratch 3.0, if a sprite has been touching a text bubble, it will count as touching white in most cases. As such, you may want to consider marking "say" bubbles' touchability as a known incompatibility between 2.0 and 3.0.

Reason for Changes

Regarding (1), if a Drawable's bounds lie at a half-pixel, that pixel will still render as partially opaque and should be considered "inside" the drawable. If not, you could end up with e.g. subtle subpixel differences between a sprite's "fast" bounds and its convex hull bounds which result in inconsistent collision detection, as in scratchfoundation/scratch-vm#2076.

Regarding the rest, these changes make "touching" tests more closely match Scratch 2.0 [EDIT: and also correct!], and make "touching color" tests match the GPU better [EDIT: and also correct!]. See, for example, this project (rename to .sb2).

Test Coverage

I have added a test for the issue described in scratchfoundation/scratch-vm#2076.

[thisandagain]

/cc @cwillisf @kchadha @BryceLTaylor

[adroitwhiz]

@gnarf since you wrote the CPU renderer code, you may find this of interest.

[adroitwhiz]

@fsih b3bcbe4 fixes an issue introduced with #515--it was revealed by running tests in both CPU and GPU mode.

I haven't seen any projects "in the wild" that are broken, but if you want me to git cherry-pick that commit into a new PR, I'd be happy to do so.

[fsih]

This looks good pending compatibility bug hunt, thanks for digging through all this!

[fsih]

FYI I tried reproing #432 using https://scratch.mit.edu/projects/301945007/editor on various browsers (but not a surface) and didn't get repro with this patched

[fsih]

@cwillisf saw the issue where the cat does not touch the bread on a lower pixel density device, but it was also on prod. We think that the pr that was rolled back was not the cause of this issue, rather it's that the higher density mip map is overwriting the silhouette on higher density devices, and the lower density silhouette doesn't touch the bread. New issue filed: #656

[adroitwhiz]

@fsih @cwillisf Any chance of this PR going in? Not sure if you still need to figure out QA...

There are other "touching" fixes I want to make that would be kinda pointless without this one going in first.

[adroitwhiz]

Rebased this on the latest develop branch; the only merge conflict I had to resolve was the _makeOrthoProjection change in extractDrawable, which I moved to extractDrawableScreenSpace.

[fsih]

Hey @adroitwhiz, really sorry for the lag on this ): unfortunately we don't have the bandwidth right now to put in these changes, so they likely won't be going in soon.

[adroitwhiz]

@cwillisf Is there any path to getting this change put in at any point and mitigating any potential project breakage?

Over the years I've had various thoughts about writing my own Scratch runtime or something similar, and every time, I end up going "ugh, but I'll have to replicate 3.0's busted sprite collision code..."

If Scratch itself ever decides to rewrite the renderer (perhaps when rewriting the rest of the editor?), it might have to replicate these bugs too.

I feel like the longer this PR stays in limbo, the more projects will be created that rely on the broken behavior (and it is broken in many, many ways. The "touching" results don't visually match the sprite, the hitbox changes when you click the sprite and its bounds become tighter, and the magnitude of the error grows the smaller the sprite is).

Most projects should behave similarly if these fixes go in, but I can think of a couple cases where there may be problems:

• Hairline collisions where a sprite is moving parallel to another sprite's hitbox rather than moving towards or away from it. I don't think (m)any projects do this, but I could be wrong.
• Fencing bugs--some projects may depend on sprites being able to go a certain distance off-screen. This PR should shrink hitboxes for the most part, allowing sprites to go further off-screen, but there may be some cases where it doesn't?
  I forgot that fencing uses sprites' axis-aligned bounds, which aren't affected by this change. "if on edge, bounce" does use convex hull bounds, and its behavior would be slightly affected.

I understand that testing this PR across various projects to see the breakage requires a lot of QA work, but not putting this change in also has a cost: you're essentially committing to replicating the broken behavior in all future versions of Scratch.