Vector graphics have enlarged collision boxes [Bug]

[SAODTHEKING]

Expected Behavior

Like scratch 2.0 vector graphics, two sprites return touch output when they are touching.

Actual Behavior

Scratch 3.0 vector graphics return touch output while there is a noticeable distance between the two sprites

increasing sprite size, increases the collision box effect. just like as if it was squared to the size of the sprite (collision box = sprite size^2) or something like that

Steps to Reproduce

I actually have a project ready, its completely broken in 3.0. try (Single player) it in 2.0, then view it on 3.0 https://scratch.mit.edu/projects/198901436/

Just make a simple level and a simple sprite enlarge the level to increase the effect and put an if touching script to =1 else =0 you will find in 3.0 there is a noticeable distance when it gives touching output

Operating System and Browser

Win10/Chrome

Update

After further investigation, i found that zooming in from the browser, decreases the effects of this issue. And when i reached 300% zoom, the problem fixed itself but not completely. At 300% zoom, the problem is present but at 5% of the original issue, which is quite good.

And i also tried different browsers, they also have the same issue.

In conclusion, this issue is related to the browser zoom and the editor (Change size) block, i think there is a misunderstanding between them. Because when i changed every (change size) block to 100%, everything worked and the issue disappeared.

[thisandagain]

/cc @cwillisf @mzgoddard @gnarf

[BryceLTaylor]

I've created a repro project for this: https://llk.github.io/scratch-gui/develop/compatibility-testing.html#239879101

Here's the project that got me started on this. There is a bouncing tire a few screens in that doesn't bounce high enough due to collisions in 3.0 https://llk.github.io/scratch-gui/develop/compatibility-testing.html#199146476

It does seem to make a difference if you are in bitmap or vector.

[gnarf]

@BryceLTaylor Do you think you could rewrite those test cases as sb3 / sb2 integration tests in https://github.com/LLK/scratch-render/tree/develop/test/integration/scratch-tests ?

You can see a bunch of examples of isTouching tests there. Adding a new one is just a matter of getting your touching scenarios to "say" things after greenflag (order kind of matters, check my other cases for some utility blocks)

• plan # - number of "pass" or "fail" to expect, error if not given the right number
• pass message
• fail message
• done- after you finished your tests

[SAODTHEKING]

The effects are magnified as you increase the sprite size by change size block! so i guess there are 2 issues here? @BryceLTaylor

[BryceLTaylor]

I've made another project for testing this using say blocks so it can fit into the scratch-render tests: touching-size-vector-test.sb2 2.zip

The position of the green square sprite is the closest it can be to the red square on each side without triggering a collision using .1 increments. As in I changed the x or y position by .1 until it failed and then backed it up in Scratch 2.0.

I also made it test it twice, first with the sprite at size 100% and then again at 150%. Interestingly, using the same method of using .1 increments to find the edge, MORE tests pass at 150% size in 3.0.

[ktbee]

@gnarf and I took a deeper look at @BryceLTaylor's example #239879101, and it seems like this could be an issue with how the vector sprite is rendered versus the bitmap sprite. In both Scratch 3 and 2, the size of the sprite changes as you switch between bitmap and vector. However, the difference seems to be a little bigger in Scratch 3. I found this by using Mac's Screen Zoom feature to take a look at where the orange sprite and green box sprites meet, and toggling between vector and bitmap versions of the sprites. I've tried to capture this in the screenshots below for Scratch 3:

It looks like the sprites actually are touching in some of the combinations, and so the "touching" block is working correctly in that regard.

Another weird thing I'm finding in Scratch 2 is that when I zoom in a lot using Mac's screen zoom and switch to both vector sprites, they are also found to be touching. This is still true even when I zoom back out again.

I'm going to dig around more in how vectors and bitmaps are rendering Scratch 3 vs. 2, but let me know if anyone has thoughts on this!

[thisandagain]

Thanks for the update @ktbee and @gnarf!

/cc @cwillisf @fsih @kchadha

[fsih]

@ktbee In 3.0 we convert vectors to bitmap by drawing the SVG element with the shape-rendering property set to crispEdges (which isn't supported in all browsers, so sometimes it comes out blurry anyway) to an ImageElement, then draw that onto a canvas with the x and y rounded to the nearest pixel (so that the pixels are drawn crisp instead of blurred when drawn to canvas). So this is a process we don't have a ton of control over.

[fsih]

I think in the renderer, the result from the paint editor is then downsized to 1/2 width and 1/2 height, and we set some additional setting in webGL to make the pixels look sharp after doing that, which could change the look more. I think cwillisf or Z would know more about that.

[ktbee]

Just wanted to update with some of the weirdness/inconsistent behavior we've been seeing:

As of yesterday, I noticed that @BryceLTaylor's example blocks project (#239879101) was fixed on https://llk.github.io/scratch-gui/develop! For some reason! He took a look and tried to find the cause of the fix using git bisect, but seemed like it was "never" broken. Perhaps some browser updates improved Scratch 3 compatibility accidentally?

Bryce has since adjusted (fixed?) the test project to be broken in way we expect again, with some caveats. There is some inconsistent scenarios for when a box is found to be touching or not:

https://scratch.mit.edu/projects/239879101/

Scratch 2	Hidpi screen	Regular screen
All vector boxes	not touching	touching
Green bitmap, orange vector	touching	touching
All bitmap	touching	not touching
Green vector, orange bitmap	not touching	not touching

https://llk.github.io/scratch-gui/develop/#239879101

Scratch 3	Hidpi screen	Regular screen
All vector boxes	touching	touching
Green bitmap, orange vector	touching	touching
All bitmap	not touching	not touching
Green vector, orange bitmap	not touching	not touching

So I'm digging into the difference in how hipdi vs regular sprites are scaled, but thoughts on this welcome! cc @kchadha

[ktbee]

Actually taking a look at this in chart form now, it looks like Scratch 3 is consistent with itself across screen types and Scratch 2 is not ... so I'm going to dig into how the flash code is working for handling these sprites. I don't think we intentionally handle scaling images for hidpi screens in Scratch 2, but perhaps Flash has some funky handling going on...

[thisandagain]

Thanks @ktbee. Given this investigation and results I'm going to remove the "critical" label from this issue and remove this as a launch blocker.

[BryceLTaylor]

A member of the community made a great repro project for this: https://scratch.mit.edu/projects/276669573/