[Scratch API] Virtual Turtle out of sync with Scratch Turtle, at physical limits

[oskay]

When the turtle goes off screen and comes back (in Scratch/Snap), the API's virtual turtle position is no longer in sync with the turtle position that Scratch expects.

To reproduce: Begin with turtle at origin Move turtle forward 1000 steps Point turtle towards origin Move turtle forward 1000 steps.

Expected behavior: Virtual turtle ends up at origin Actual behavior: Virtual turtle ends up at (-248.25, 0)

There are additional unintended consequences that relate back to the API's virtual turtle no longer matching the position of the on-screen turtle; this is apparently the root cause.

[techninja]

Yeaaa.. this is one of those things. DO values outside the range get thrown out, or kept to ensure position calculations remain but values outside the range get ignored? You've got a good test here so I'll see what I can do to make it match expected.

[oskay]

If the virtual turtle x-position exceeds the maximum extents of the paper, I can see two valid possibilities:

1) The WCB draws a given (x,y) position as (x_Max,y), when x > x_Max, or 2) The WCB lifts the brush when the position commanded to is "off screen."

In no case can we throw out the position information-- that causes everything subsequent in the plot to be ruined.

A good test case is as follows:

In Scratch/Snap (or any conventional computer graphics) a pen line drawn outside of the viewport is not visible on the screen, but does not cause the turtle to forget where it is. If we draw a "circle" (well, a decagon) that goes outside the boundaries of the screen, Snap (here) properly draws a partial circle, that returns to the same place that it started. If you try this with the current API, it does not draw a closed shape, because position information is lost once the screen (paper) size is exceeded.

[oskay]

I should note that with RoboPaint RT and wcb-ink, we have made the call to go with option (1), which is a little easier, but does not match what Scratch/Snap actually draw-- a pen lift at the edge of the paper would perhaps be a little more appropriate.

[techninja]

A lift for "off screen" is totally appropriate, will visualize the "cutoff" as if it were a screen representation. Though it should only be a discrete lift if the pen was down, or rather, no movements offscreen can allow for the pen to be down (though the state will be saved), then if the state is meant to be down by the time it comes back "on screen", it will go down as a "back on screen" event of some kind. Will submit a fix for this and suggest you test via CNCServer to ensure it works according to your specs :)

[oskay]

Sounds great. Perhaps we should make that change for the other two interfaces as well.

[techninja]

Huh. Never thought about it. But yea, that seems like a good idea. Ok then.

[techninja]

SOooo... I'm working on adding extra the ability for any interface to request a position off the canvas.

• The actual movement will be all the way up to the edge, but the position attempted will be stored.
• As soon as an "off canvas" move is complete (to the edge), if the pen was down, it's lifted up
• You can move around off cnavas, but only non-offcanvas coordinates will actually do anything
• As soon as you submit a position back in the bounds, the pen will go back to drawing (if it was).
• The latter does not work though if you send a position outside the canvas on the bottom, then to the top again (doesn't draw any on canvas positions in between). This is unlikely to be that common though.

Turns out this is damn tricky and turns a number of assumptions throughout the program on their head. I'll try to get it out tonight, but testing reveals some sticky wickets remain.

[oskay]

If it turns out to be more effort than justified, the simpler method above (draw a given (x,y) position as (x_Max,y), when x > x_Max) would also be acceptable.

[techninja]

An hour after my post last night, I got it working! Yay! But before committing anything, I wanted to try it in RP. Turns out there's an open question about what it means to re-ink while off canvas. Other than that, it performed quite well. I'm going to look into simply blocking manual pen down action while allowing others. Should have it in tonight.

[oskay]

Yes, re-inking should be with respect to actual distance painted, not total distance that the virtual turtle traveled. Interesting.

[techninja]

I've tested the above with your two tests (thank you SO much for those, incredibly helpful), AND with off screen reinking (in RP), and it now works great. It feels very.. natural, and I suspect it's something that's been properly missing for some time. If you look, you'll see it's a bit more code than expected.. but it's been through more than the usual battery of tests, so I feel pretty confident. Hopefully you'll have time to test and we can get RP 0.9.3 rolled and out the door ASAP.