turbowarp / scratch-vm Goto Github PK

Expected Behavior

Extension worker should work

Actual Behavior

No idea if it works, probably not. I'm guessing that it shouldn't be hard because we already have the compatibility layer?

Expected Behavior

All script compiling should happen when the project first starts to avoid stutters later

Actual Behavior

Script compiling can cause stutters because it happens lazily

Move type analysis over. This is necessary for #36

Expected Behavior

The compiler should be able to reason about the types of variables.

Actual Behavior

The compiler is unable to reason about variable types -- everything is TYPE_UNKNOWN

It may be possible to compile a subset of Scratch blocks to GLSL shaders to run on GPU.

Affects:

• or & and short-circuiting
• completely removing calls to empty procedures (so the arguments are never evaluated)

I don't think any vanilla Scratch blocks have any side-effects other than delays and network requests.

Stuck checking is slow so it can't be enabled by default, but scripts may want to explicitly enable it.

Hi GarboMuffin. I've made a favicon for TurboWarp (here) [ignore the thumbnail, and read the instructions.]

See if it's possible to make clones opt into some form of Worker-based multithreading

• only mutate local variables
• no interacting with rendering
• need some special API to postMessage to the main thread

Instead of maintaining a list of opcodes to run in compat, we should just assume that everything will work just fine

• left
• right
• middle

Need to see if we also need to create the var in all other existing clones, not just any new ones going forward

In run w/o screen refresh block

(busy loop for 100ms)
reset timer
say timer

will output ~0.1 instead of 0

It's been like this because the compiler couldn't handle compiling reporters, but now it can.

Calling directly into the IO devices may remove some very slight overhead

Expected Behavior

These should not be hotspots

Actual Behavior

These are hotspots and take up more than half of the compiler's time on some projects

There are a bunch of Turbowarp repos so I wasn't sure where to go.

Scratch has released Scratch Lab with two new features. These will probably be improved and eventually added to normal Scratch. Should Turbowarp include these?

Probably? Haven't checked, but there's nothing to stop that from happening.

It may be possible to compile a subset of Scratch blocks to webassembly for performance.

Consider increasing the framebudget target while turbo mode is active. Might improve raw throughput a bit.

• invalid hex colors
• maybe more

Expected Behavior

This block should return false, as it does in scratch.

Actual Behavior

This block returns true.

Steps to Reproduce

See https://scratch.mit.edu/projects/494142821/
and http://turbowarp.org/494142821

Operating System and Browser

Ubuntu 20.04.2 Google Chrome

Expected Behavior

Sound should work and this should run well

Actual Behavior

Seems to run at full framerate, but the sound is absolutely horrible.

Steps to Reproduce

1. Open Scratch project 53005142 in Turbowarp
2. Play project
3. Listen

Operating System and Browser

Windows 10, Edge 86.0.622.38

Expected Behavior

Performance should be consistent over time

Actual Behavior

Performance tends to get worse over time

Steps to Reproduce

https://turbowarp.org/#310372816

right it twice, second benchmark and beyond will be slower than first

Operating System and Browser

seems to be chrome specific

Right now only the entrypoint script can get highlighted.

This should be changed so that (non-warp?) procedures can also get highlighted. This should be more possible now because topBlockId is in IntermediateScript

A question. Will using cloud allow users to bypass the usual restrictions on editing a project while still updating cloud variables? It feels like this has the potential to make it too easy for users to hack and break our cloud high scores, etc? Or does it work a different way? With great power comes great responsibility!

We need to start writing regression tests to make sure that

63f9da7
50bb8c3
01c8ecd
1db0328
eb28f8b
87cd56d

etc. don't regress

Expected Behavior

Foreign language chars (e.g. Italian accented chars à è é ì ò ù ) are recognized by the KEY PRESSED? and WHEN KEY PRESSED blocks

Actual Behavior

Foreign language chars (e.g. Italian accented chars à è é ì ò ù ) are not recognized by the KEY PRESSED? and WHEN KEY PRESSED blocks

Steps to Reproduce

Operating System and Browser

e.g. Mac OS 10.15.7 Chrome 88

Upstream does this:

        // Store the current shadow value if there is a shadow value.
        const fieldKeys = Object.keys(fields);
        this._isShadowBlock = (
            !this._definedBlockFunction &&
            fieldKeys.length === 1 &&
            Object.keys(inputs).length === 0
        );
        this._shadowValue = this._isShadowBlock && fields[fieldKeys[0]].value;

Expected Behavior

https://turbowarp.org/453148564/editor works with compiler enabled

Actual Behavior

Scripts do not glow if the compiler is enabled

Steps to Reproduce

Go to https://turbowarp.org/453148564/editor, enable turbo mode, zoom out all the way (necessary due to an upstream performance issue), run. Note that the pixels do not glow. Disable compiler, note that pixels do glow. Shudder in horror at the abomination.

Operating System and Browser

Linux, Chromium

Notes

I'd be happy to write the necessary patch, though I'm not quite sure why this is happening - if you can give me some pointers to whereish you think the patch should be, I'll take a stab at this.

It's probably a good idea to make glow optional, it has some performance issues.

AST generation currently creates a large amount of objects. A lot of these objects, such as motion.x. don't need to be new nodes, but could just be pointers to a single global instance of that node.

Expected Behavior

A script that starts with "touching color red" or "is compiled?" should be compiled.

Actual Behavior

Any script that doesn't start with a non-stacked block cannot be compiled.

This presents an awkward situation where the "is compiled?" block will return 0 when users click on it on its own, but true when they use it in their scripts.

Moved from #30, see comments there for arguments for and against

Expected Behavior

The wait _ seconds block should behave as it does in the official Scratch player.

Actual Behavior

The wait _ seconds block does not wait as long as it should.

Steps to Reproduce

Run this project in both Scratch and TurboWarp: https://scratch.mit.edu/projects/416669082/

Operating System and Browser

Windows 10 2004 Edge 84.0.522.52

Sorry, this is not an issue. I would really like to know how TurboWarp can be installed and run locally or on a web server. Every configuration you used, even specific to your installation, would be good enough for me. Thanks in advance.

• backspace
• delete
• tab
• shift
• escape
• function keys?
• control?
• alt?
• meta/windows/command?

Expected Behavior

https://scratch.mit.edu/projects/116680081/ should work

Actual Behavior

It errors with Uncaught RangeError: Maximum call stack size exceeded

This seems to be caused by the project using recursion as an alternative to repeat something 40,000 times.

We are limited by the call stack size of the browser because we use actual JS recursion, whereas Scratch's interpreter uses a list that allows essentially infinite recursion.

Steps to Reproduce

https://turbowarp.org/116680081

Operating System and Browser

Happens in all browsers.

Expected Behavior

Given this script:

The compiler should be able to conclude that first, second, nth, i will always be numbers and optimize accordingly:

b1.value = 0;
b2.value = 1;
b3.value = 1;
b4.value = 2;
while (b4.value > p0) {
    b3.value = b1.value + b2.value;
    b1.value = b2.value;
    b2.value = b3.value;
    b4.value = b4.value + 1;
}
b0.value = b3.value;

Actual Behavior

It's not very smart. The script is compiled as:

b1.value = 0;
b2.value = 1;
b3.value = 1;
b4.value = 2;
while (!compareGreaterThan(b4.value, p0)) {
    b3.value = ((+b1.value || 0) + (+b2.value || 0));
    b1.value = b2.value;
    b2.value = b3.value;
    b4.value = ((+b4.value || 0) + 1);
}

https://share.firefox.dev/2V2lI9z

Move it from being hardcoded into the definition to being set when going from a non-warp -> warp procedure.

This might be a a couple % improvement

Expected Behavior

Blocks run from the flyout should be compiled

Actual Behavior

Blocks run from the flyout are not compiled

This can improve performance by a few % by removing unnecessary yield checks.