Adam ScottI'm currently working on fixing one of Godot 4.x infamous regressions: web exports.
🧵#GodotEngine
Currently, you need to make your website "cross-origin isolated" using certain headers (COEP/COOP).
This is quite difficult if you don't own the website your game is hosted on.
You cannot monetize your app, too, as you cannot make cross-origin requests.
My (draft) PR makes it possible to compile Godot for it to use the main thread only, which then makes it possible to compile the engine through #emscripten without the need of `SharedArrayBuffer` (which is the reason why we currently need COEP/COOP).
Add THREADS_ENABLED macro in order to compile Godot to run on the main thread by adamscott · Pull Request #85939 · godotengine/godot
Context This PR adds the THREADS_ENABLED macro and the use_threads=yes|no build option. There could be a way to make the THREADS_ENABLED modifications run time instead of build time, but the Web pl...
My PR is still a draft as I must go through it, making sure I didn't break everything. But it's stable enough to be able to run Truck Town.
Here's the demo running on a single thread, without the need of PWA nor having access to headers settings.
If you hear some crackles, this is normal. This is unfortunately one drawback of running the game single threaded.
Without threads, everything must be done in the main thread and performance is impacted.
This is not great, but at least, developers will be able to choose (soon).
Vile Lasagna@adamscott Was about to ask if this was multithreading vs spectre mitigation issues because I ran into that exact problem when first building toyBrot with emscripten.
This also means that, internally, a lot of my admin UI is broken because of those which is a pain whenever I'm upgrading, searching for plugins and whatnot. it was a huge PitA
@VileLasagna Yeah. Spectre and Meltdown really threw a wrench at the idea of a world where the web could achieve native-like performances easily.
@adamscott The performance IS there but, suddenly, some tremendously nasty ways in which that could be exploited were also just out in the open
There's no putting this cat back into the bag, I don't think, and we'll just kind of have to live forever jumping in through hoops to try and prevent the most egregious hijacking from malicious code
The issue of these remote end points being compromised is very real, unfortunately. Didn't a massive pip package get compromised and spread the other day?