Skip to content

Compatibility

Andrew Sliwinski edited this page Jun 5, 2017 · 31 revisions

Consistent type coercion when modifying variables

In Scratch 2.0 if you set [var] to [var + 1] and the variable contains a string, you get 1. If you change [var] by [1] when the variable contains a string, you get NaN. In 3.0 both now have the same behavior and return 1.

Consistent rounding method for list indexes

In Scratch 2.0 if you delete [1.5] of [list] it will delete the item at index 2 as the index is rounded. However if you replace item [1.5] of [list] with ["thing"] it will replace the item at index 1 as floor is applied to the index. In 3.0 floor is now applied consistently for all index arguments on list blocks.

Reference: https://github.com/LLK/scratch-vm/issues/202

Keyboard input capturing

All keys are captured by Scratch 2.0 when it has focus, so if you use browser keyboard shortcuts e.g. Cmd-Opt-J, the browser does not respond to them. In 3.0, special keys are allowed to propagate so the browser keyboard shortcuts work while Scratch has focus. Scratch 3.0 will continue to register these keys, so when any key pressed blocks will trigger at the same time as the browser shortcut activates.

Touching sprite works with self

Unlike Scratch 2.0, the "touching []" boolean reporter will no longer return true at all times if the reporter argument is set to itself. Instead it will return false unless the rendered target is touching another instance of itself.

Reference: https://github.com/LLK/scratch-vm/issues/377

Consistent direction for "whirl" graphic effect

Scratch 2.0 has two stage modes: 2D and 3D. The "whirl" graphic effect is applied inconsistently between these two modes (clockwise in 2D and counter-clockwise in 3D). Because most users see the 3D stage when using Scratch 2.0 and Scratch 3.0 always uses WebGL for rendering, we have decided to normalize to counter-clockwise application of the "whirl" effect.

Reference: https://github.com/LLK/scratch-render/issues/22

Variable monitors always on top

Scratch 2.0 allows for sprites to occlude monitors as they are treated as part of stage rendering. In Scratch 3.0 monitors are rendered as part of the overall user interface and are independent of the stage. Because of this, sprites can no longer be rendered on top of monitors.

Clone this wiki locally