X and Y positions differ at edge of stage between Scratch 2 and 3

[ktbee]

Expected Behavior

When you send a sprite off stage (say X position = 1000 and Y = 0), its position should be limited to the edge of the stage and its X and Y values should be the same in Scratch 2 and 3.

Actual Behavior

The X or Y value that goes off stage is slightly different in Scratch 3 vs. Scratch 2. In Scratch 2, the X and Y values are integers. In Scratch 3, they are floating point numbers that are within about .5 pixels of the Scratch 2 position value.

Steps to Reproduce

I've created an sb2 project as a potential scratch-test that reproduces this issue well. You can find this file below:

sprite-goes-off-stage.sb2.zip

The repro steps:

• In the Scratch 2 offline editor, send a sprite off stage and use the "say" looks block to display the "x position" motion block or the "y position" motion block.
• Save the sb2 project and load it in Scratch 3
• Observe that the X or Y value for when the sprite tries to go off stage (for example go to 1000,0 or to 0,1000) is different than the values for Scratch 2.

Operating System and Browser

Mac OS 10.14 Chrome 71.0.3578.98

[ktbee]

Looks like there are a couple of factors behind why there's incompatibility between Scratch 2 and 3 for where a sprite is position when it tries to go off stage. I addressed one of the more straight forward ones in this PR, where we need to use Math.ceil and Math.floor.

This PR fixes a lot of the inconsistencies in the sprite-goes-off-stage test linked above, but a few remain. For some of the sprites, the first time its position is checked, the test passes. When the sprite moves to other coordinates that would put it off stage, the tests fail. The sprite's X and/or Y position is off by either negative one or rounded down, and it is because its width and height are a little different (less) after moving the sprite than when its height and width are checked the first time. This difference in height and width calculation comes from whether aabb is calculated using drawable.getBounds or drawable.getAABB. And the main difference between those two functions seems to be whether they return an existing aabb or whether they use hull points to create the aabb it returns.

@mzgoddard and I spent some time looking at the Scratch 2 code for this, and one question we have is whether geomShape.getRect(parent) always returns the aabb or whether it ever uses hull points. It's a little hard to tell since getRect is a builtin function in Flash and so not very easy to see the source code for. We checked in with @cwillisf about this question offline, but if anyone else has some thoughts/insight this, please feel free to comment!

[ktbee]

We're closer on this one! #409 fixes the off-stage position for bitmaps, but there is likely still a lot of investigation left for determining why SVG skins have incompatible positions when sent off stage. We tried some experimentation with drawable.getBounds and adjusting the aabb's position by the SVG's stroke width (which was also scaled by the drawable's _scale), which did help in some cases. However, it didn't solve all of the sprite-goes-off-stage test's incompatibilities. A good next step would be to compare how Scratch 2 renders an SVG and compare that to an SVG's hull points in Scratch 3.