Open kisg opened 3 years ago
Does this imply that WASM also works outside of web browsers? If so, this could be great for GDScript because I think that Godot should try to turn GDScript into bytecodes instead of interpreting them for performance reasons.
Does this imply that WASM also works outside of web browsers?
Yes, the aforementioned WebAssembly runtimes can be embedded into any application. We'll most likely want to pick a runtime written in C or C++ (as opposed to Rust) to avoid making Godot's build process too complex.
Would be poggers if Godot pre-compile GDScripts into bytecode when building projects. God, just imagine the performance boost.
Would be poggers if Godot pre-compile GDScripts into bytecode when building projects. God, just imagine the performance boost.
GDScript is already compiled to bytecode in exported projects (.gdc
files), in a way similar to Python. This only speeds up script loading, not script execution. To speed up script execution, you need to perform AOT or JIT compilation.
you need to perform AOT or JIT compilation
I think AOT compilation is a good tradeoff between performance and size here.
you need to perform AOT or JIT compilation
I think AOT compilation is a good tradeoff between performance and size here.
There are different use cases:
The good news is that every WASM runtime worth considering supports interpreted, JIT and AOT modes. For example the WASM Micro Runtime is such a candidate: https://github.com/bytecodealliance/wasm-micro-runtime
That said, it makes sense to implement the integration in such a way that the runtime can be replaced easily in a custom engine build (or if possible, through a GDExtension class).
Has there been any news regarding this? It sounds very interesting
Has there been any news regarding this?
No, this is not something that is planned for Godot 4. Any possible work will start after that.
this is not something that is planned for Godot 4.
Why not? This could be a great performance improvement.
Why not?
Because we want to release it at some point 🙃 Godot 4 is not the last version of Godot either, and doesn't have to include everything that is possibly good.
Another benefit of supporting WASM inside of the engine is that it could enable "scripting" the engine with programming languages that can target WASM. This would allow users to use many compiled programming language in a portable way, as they would need to only compile their code once to WASM, instead of having to compile their code for each target separately, while retaining some of the performance benefits of compiled languages.
This could be also great for extensions.
Written in C++, only to call from GDScript: https://github.com/ashtonmeuser/godot-wasm
Written in Rust, for all languages: https://github.com/Dheatly23/godot-wasm
As a runtime, I suggest this: https://lunatic.solutions/ and this https://github.com/wasm3/wasm3
Totally forgot this exists. Now that 4.0 is released, could this be included in a 4.x release?
They are not far enough developed on their own. I assume there are good chances to include the GDScript and C++ based one and wasm3.
Describe the project you are working on
Godot for a commercial AR project where we plan to contribute our enhancements.
Describe the problem or limitation you are having in your project
GDScript is using a custom interpreter that is too slow for computationaly demanding tasks. At the same time the developer UX is best with GDScript.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
A new compiler should be added that generates WASM bytecode from the GDScript AST. The WASM bytecode could be executed in different ways:
Check out #147 for the generic WASM support proposal.
The generated WASM code would implement a script instance, or if #3369 is accepted a GDExtension class.
If the proposal is accepted we are willing to contribute the implementation.
The advantages of this implementation are:
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
See above
If this enhancement will not be used often, can it be worked around with a few lines of script?
No
Is there a reason why this should be core and not an add-on in the asset library?
This is a core change / addition to the GDScript functionality.