Support Cloud Variables

[gradylink]

For our project we wrote a library (https://github.com/ScratchEverywhere/mistpp) for handling communication with the cloud variable server if you want to use that, it currently requires a version of libcurl with WebSockets enabled (which to my knowledge are only enabled for Wii and Arch Linux) so you'll likely need to build curl with FetchContent or CPM.

[adazem009]

Hi, thanks for your suggestion. I might add support for cloud variables later. However, I'm worried about connecting to the Scratch cloud server which would mean that I'd also have to implement authentication. This is probably why TurboWarp uses a custom server and so should I.

By the way, I'd like to hear more about your project since it has similar goals to mine. Maybe we could merge them in the future or something as mine is mostly focusing on performance (LLVM-based compiler, optimizations, etc.) and it already supports most Scratch blocks.

[gradylink]

@adazem009 you can actually just use tw's cloud variable server which is what we do, we generate a project id by hashing all the md5 asset hashes. Also I don't think the projects could reasonably merge as LLVM isn't very portable and we support like 6 different an architectures.

[adazem009]

@gradylink The codebase is designed for basically any kind of script compiler. The LLVM-based compiler can be swapped with something else, so maybe a more portable compiler could be used on those specific platforms and architectures. But this is just an idea...

Anyway, how does your project compile scripts? Is it a bytecode VM like in the current version of ScratchCPP?

[gradylink]

@adazem009 our runtime is completely interpreter based, we've just optimized it too the point where is faster than TW without the compiler, one of our community members is also refactoring the runtime to actually use a proper thread-based model which has an additional 20% fps boost.

[adazem009]

@gradylink Interesting. You mean user level threads, right? I cannot imagine proper multithreading with Scratch because that would break many things (execution order, thread safety, etc.)

[gradylink]

I mean "threads" as in the oop based structure the official scratch vm uses. Our current block executor is technically incorrectly implemented as can be seen in ScratchEverywhere/ScratchEverywhere#500, it just happens to work with like 99.9% of projects.

[adazem009]

@gradylink Those are user level threads and it's what my VM uses too. Kernel level threads would be those managed by the OS kernel and you'd get real parallelization on multiple CPU cores. But I don't think it's even possible with Scratch due to thread safety and synchronization issues.