Readd support for web platform exports when using the C# (.NET) version of the engine #70796
Comments
|
There are no C# export templates for HTML5 yet due to missing upstream support in .NET 6 (.NET 7 didn't address this). That said, there are significant issues with the HTML5 export in 4.0, such as #68647 and #70691. I would recommend using 3.x if targeting HTML5 for now, regardless of whether you're using C# or not. |
Calinou
changed the title
|
What is the missing upstream support from .NET we're waiting on to get HTML5 support? Can we link that item here and then in whatever documentation gets created? Not having HTML5 support for Godot 4 is preventing me from using Godot 4 when participating in game jams as I prefer uploading web builds. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Since several people now independently wrote this same bug report, and the situation is as it is with Godot 4 stable, maybe it might make sense to mention Web export for Godot 4/Mono as "unsupported for now" somewhere central in the Godot mono docs. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I propose we make a Tracker ticket to collect things: why C# Support is missing, what can be done about it (split in: what can we do about it. What can dotnet devs do about it) and what can be done to make it verbose to the user. I also recently stumbled upon it just missing and I also consider it an important feature. I saw here, on other tickets and on the release notes of 4.0 that there was supposedly a communication between core godot-devs about it, but there isn't really a transparent Ticket for us. |
What upstream support is missing, exactly? Is it something that we could expect in, say, the next year? |
We can't give an ETA as we don't know when contributors will be available to do the required work on both the .NET and Godot side. I wouldn't expect it to be ready for this year though, especially if you want to use a stable version and not a pre-release. If you need to use C# to target the Web platform right now, stick to Godot 3.x. |
Is there a group of participants I could connect to? I'd like to help working on that. |
|
@Sythelux Try Godot contributors chat at https://chat.godotengine.org/channel/navigation |
|
@raulsntos I want to ask you a larger set questions regarding the future dev cycle of Godot and Godot 5.x dev plans. This is for the wider creative dev community and make it easier to convince people (mainly commercial / senior devs) in the industry to start using Godot more in the near future. I want to be able to give these senior talented people proper up to date answers / quotes from 2025 by talented Godot engine devs like yourself. So I figured it best to just go to the source to ask directly about Godot's future fate. I am sorry to bug you too but I figured it best to go to the source and get various creative community future Godot dev direction concerns sort of done and taken care of with. So I and others can share it with the rest of the creative community in regards to where Godot dev staff are doing for 2025-2027/2028-2030's+ / into the next console gen come 2027/2028+. (I keep getting bugged and I wish to be able to give proper answers to the creative community devs to properly advocate for Godot's macro leadership. So I figured to just get a proper answer to handout / give / share to the wider creative community devs going forward given the lack of discoverable info on the direction of Godot in the next ~2-5+ years). Is this C# web export problem a reason to make Godot 5.0 start more development? As in with this case if Godot 4.x cannot realistically add proper C# web support in the future / operate with C# web in a way that is native / without large difficulty / poor ergonomics to the majority of Godot devs? Would this make a Godot 5.x seem closer to a 2027-2028 kind of target window for the general public release? As in if there are too many deep rooted issues to use Godot 4.x for major future proofing for the 2030's? As in would this require a rebuild for better future proofing to start in the current dev cycle (to better solve issues such as C# web in the future)? If Godot 5.x is on the march sooner or later would a dev cycle sort of follow the same pattern as Godot 3 to Godot 4 public release? Also why is there no Godot 5.0 in the Godot issues milestones https://github.com/godotengine/godot/milestones if it is in the proposals https://github.com/godotengine/godot-proposals/milestones ? I wish I could give people proper answers or add it myself but I'm more a creative community dev / old guard to mmo devs and less of a tool dev / Godot engine dev but I think this Godot 5.0 issues milestone would help people make plans moving forward. I heard rumors of a C# Godot core rewrite for Godot 5.x to better handle C# / web / massively multiplayer / proper servers networking templates / proper multiplayer documentation / proper industry standard multiplayer support and major future proofing for late 2020's / early to mid 2030's and a better focus on large scale projects / proper steam support / better support for industrial scale projects. Specifically with help / more project donations from big movers of the industry in regards to get Godot more in line to support industrial scale game dev staff already trained with C# from Unity and Unreal etc. This has several reasons such as big studios with already trained senior staff to avoid future royalties / fees and so Godot can better compete in the near future with the big older closed source game engines from the creative community. As over the past year or so talking to the creative community with and without Godot discord, forums, reddit, twitter, youtube, twitch, GitHub, email / talking and other places where large scale creative community / dev community places are I heard of a large demand from commercial / professional / not-indy / senior old guard game devs to mainly use C# instead of GDscript. As in many creative community dev conversations had shared common points as it would be common to hear from senior game devs talking like in a chat where they go ~Yeah Godot is great but they wouldn't use it due to the dependency on the limited range GDscript and it has onboarding issues so they stick to Unreal / in house engines for serious large scale projects. Yet if Godot had better not-GDscript parity / full C# and C# web support they would think of serious applications to use Godot for making industrial scale game dev to help their large studios / better fund / donate to Godot's dev cycle. What is the status / current line of thinking regarding these issues with Future Godot dev / Godot 5.x? |
|
@iistarion I think you have a point, this could merit it's own issue and the complex nature of the questions could merit their own space for discussion. I should free up this space for this issue and find a more appropriate space for these questions. I think that a separate issue would probably be wise to host these issues and allow for more dialogue too. I took the issue rules advice and found https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md and it has a part about communicating with developers. I think I should pursue this, thank you for the feedback, I would not have known of this / where the proper channels were until given the advice. |
Sorry for the pinning; is there any publicly shareable progress or information on the dotnet wasm side about the issue Godot is currently facing? Being able to export to the web is important to many developers, thank you. |
|
It may be a really stupid idea/question... if Godot wasm can 2-way communicate with JS via interop, and .net wasm can do the same, isn't it technically possible to build up a communication layer between the 2 via JS bridge (something like the file-based IPC, or with chained callbacks)? Edit (I don't want to make another post with another probably stupid question): |
|
@raulsntos I have been reading about the limitations you mention above that arise when linking godot and dotnet assemblies. Would you say this issue godotengine/godot-proposals#7895 will change alot in how web support is implemented? That is just incase we decide to have web support before actually migrating it into a plugin? I will appreciate if you have any other newer source where i can read more on transforming godot csharp into a plugin. I have only seen it mentioned in the priorities here: https://godotengine.org/priorities/#dotnet |
No, We'll have the same issue as GodotSharp since hosting the .NET runtime works the same way. In other words, if we cannot get GodotSharp to work in WASM, we cannot make the new bindings work in WASM either. |
|
Hello everyone, I have a quick update regarding web support for C# projects. As mentioned in my last update, the option of statically linking Mono seemed the most promising so we went ahead with that. I have opened a draft PR with the latest changes, but keep in mind it's still a work in progress: As a reminder, this approach still seems very brittle to me and has some limitations. The C# project must match the WASM features supported by the Godot template (this includes things like the threading model, exception handling, SIMD support, etc.). The TargetFramework version of the C# project must also match the one that was used to build the template. Additionally, since we currently don't load any globalization data, we only support invariant mode. This is not a big problem because most users will likely rely on Godot's localization features, so it's not a blocker. On the last update the issue we run into was retrieving function pointers. We were able to workaround that by declaring stub C# methods on the project we use to retrieve the Mono runtime. When building the Godot templates, this ensures these methods are included in the generated table which seems to be enough to let us retrieve the function pointer at runtime. In a regular C# application built for the web platform you'd use The Mono runtime exports some JavaScript functions but at the time of building the templates these are stubs. The This means some .NET APIs that rely on these exported JavaScript functions will not work, resulting in unexpected behavior. This includes things that must be implemented using browser APIs such as cryptography. Nonetheless, I think this is significant progress and has allowed us to build a demo running on the browser: Thank you all again for your patience with us. We're excited to provide web support for C# projects even at an experimental state and we'll keep working to fix the remaining issues. |
|
I hope this isn't an ignorant question but regarding the requirement of the TargetFramework of the C# project needing to match the one that was used to build the Godot template: does this come with additional restrictions about other included projects or libraries which may be from older .NET versions? (example: I tend to include a lot of .NET Standard 2.0 libraries and having access to those is one of the reasons C# is a benefit) |
|
So let's say the templates were built with It's common for users to target a newer version of .NET, we see it all the time with users targeting .NET 9.0 today even though the default is 8.0. This is already a problem in Android where users must also match the version we're targeting in the template (which in this case is In Android projects you can workaround this by using Gradle builds, because it allows us to use the Java libraries directly from your C# project instead of the hardcoded one we use in the template and the Mono runtime is dynamically linked. You should be able to build a custom template targeting a different version of .NET if you need it. But it doesn't seem like you'd need to do that in your case. That said, whether the library you are using is supported on the web platform or not is a different question. That depends on the specific library, not every C# library is "cross-platform" (for example if it consumes some native Windows library). |
|
I'm really excited to hear that C# support for the web is on the horizon! I was actually about to give up on Godot, but this news has given me new hope. Do you have an estimated timeline for when this feature might be integrated into a stable release, such as Godot 4.5? |
|
While it's awesome to have working C# web exports again, I think this approach is going entirely into the wrong direction. Let's ignore the current prototype problems for a second and assume that things like the stub functions, globalization and other incompatibilities can be worked out soon with more manual hacks or adjustments. Is the base of this approach really viable? As far as I can see, this is a huge step backwards, as you are loading the entire Mono runtime to JIT compile the managed DLLs inside the browser, very similar to Godot 3. Here are a few problems coming to my mind:
Now I just tested the demo you provided. And unsurprisingly, it is over 114mb in size already without containing any actual game assets. ~42mb of it are Godot (the entire engine itself), ~60mb of it are just the C# and Mono part. I've also checked the IL code in the DLLs, noticing that nothing was stripped out/trimmed and the full source code left readable. To put this into perspective: the C# part of a full Godot standalone game export is ~15mb in size when using .NET 9 and NativeAOT with high trimming settings. No runtime needed, no dependencies - just a small, AOT compiled binary blob, nicely embeddable into the final exe file. And I think this should be the goal for the web version too, minus the embedding part maybe. (For fairness I've also compiled a small OpenGL standalone game to WebGL using the browser-wasm target (dotnet.js), which resulted in ~30kb for renderer and gameplay code and ~9mb for the .NET runtime + dependencies, indicating that dotnet.js and/or NativeAOT-LLVM might be the better way to go in the future) Another sidenote why all of this is important: optimizing for download size is absolutely mandatory for web games nowadays, especially the initial download size. Unity for example is well optimized for it already, and even they constantly struggle with this problem, as more and more game sites start enforcing lower size limits. Are there any ways to further optimize the Mono part for now? Is there a way to get AOT compilation/trimming working with it? Edit: |
|
I do agree that a look into size optimization is necessary, however
Can you elaborate on the "clearly visible C# source code"? Are you suggesting that the plain text C# source code is required for the current solution? If I recall correctly, the mono interprets IL (managed DLL content) instead of C# source code. |
Yes, the current approach uses IL code, but that's easily converted back into C# source code files with one click. But that's more of a not so nice side effect which doesn't need that much attention anyways. I just brought it up because NativeAOT solved it completely already by removing all debug symbols and stack trace informations if desired, and with the Mono approach we are back 5 years again to this point. In short: anyone can download your index.pck in the browser, import it into the Godot editor, reverse the IL code back to C# and has the full source code of your game with all assets right in their editor. NativeAOT prevents that for the source code part at least, but as I already said: it's not its actual purpose and more of a nice side effect. The Mono runtime size is much more concerning to me, and I really hope that there are ways to optimize that. |
Sounds like you have expertise in web development via C#, have you ever achieved calling to an AOT compiled dotnet library via a wasm application? as that's the main blocker that's preventing Godot from supporting NAOT/wasm. |
Emscripten version match could be also required.
It seems godot is MT, but you are linking ST dotnet?
Yes, POC of dotnet runtime (mono) running as emscripten side module would be welcome. I'm interested to learn how
In Net10 we made good progress in making dotnet.js more friendly to JS bundlers. There is also a way how you can provide pre-downloaded files for dotnet.js That's not really stable/public API, but you are deep in the weeds already. @raulsntos please feel free to open questions and ping me there.
There are many things you can do to make the mono/wasm runtime smaller. We keep cheat-sheet here If you are willing to do hacks beyond what's supported product, you can make it much smaller. We did demo/hack recently for simple form validation There is We got to 2.5MB uncompressed which is about 810 KB brotli compressed.
Typically the application code is much larger than the runtime and so trying harder on runtime has diminishing returns.
There is Mono AOT for WASM. It tends to produce larger downloads and faster execution than mono interpreter. Mono runtime has full reflection etc, while NAOT doesn't. Requirements of C# codebase/libraries which you want to use matter. |
|
@pavelsavara Thanks for reaching out.
Godot supports both MT and ST. Right now the PR uses ST because, as far as I know, MT dotnet is experimental. However, I tested both MT and ST and they both seem to work fine, as long as the Godot build matches the dotnet runtime:
I'll have to look into that, I've only been using .NET 9. I have tried replicating In an exported Godot project we end up with an Is there a chance you could expose an API on @Armynator Like others have expressed, I also agree that size is important on web. We're looking at getting something functional first, then we can look into optimization. That said, @adamscott has been working on compressing exported projects which can help a lot.
A runtime is always needed to run C# code. NativeAOT also includes the runtime (it's by definition always As mentioned in #70796 (comment), there are a number of ways to reduce the size of the Mono runtime and we could explore them in the future, but we can't make any assumptions about what the user project needs. The best way to reduce the size as much as possible will always be to compile the template yourself, so you can configure the linked Mono runtime to your specific needs and exclude unused modules.
Mono does support trimming. However, Godot doesn't fully support it because we have some reflection usage that is incompatible, so we are currently rooting the assemblies to prevent trimming APIs that may be needed in the exported project. We want to improve trimming support, but this is orthogonal to web support.
I'm not sure what you mean by this. As mentioned in #70796 (comment), the template must match the C# project so there shouldn't be different runtime versions. While it's true that the GetRuntimePack approach may seem hacky, I don't think there's another way to link Mono statically without it. In #70796 (comment) we explored dynamically linking but it didn't work (in summary, the WASM flags didn't match). |
It's still experimental because it has been put on the backburner by Microsoft. The last time I looked at it in the UNO project on .NET 8, it was working okay, but Microsoft disabled it in .NET 9 due to stability issues, as it relies on SharedArrayBuffer, which not all browsers support completely (and in the same way). https://platform.uno/docs/articles/external/uno.wasm.bootstrap/doc/features-threading.html I think from memory that you can turn it on, but you will only get one extra thread by default, which is still better than nothing but not ideal when most PCs could use eight threads simultaneously (or more). I haven't looked at multithreading in .NET 10, but I will once I see some indication that Microsoft has fixed the issues with it. You can increase the number of P-threads when you compile the code with Emscripten, but the main issue was that if you have too many threads running concurrently, the browser would just randomly freeze and not recover, so you would have to reload the page and lose your entire application state. That is pretty much why almost everyone invloved with .NET WASM has decided to just disable multithreading in WASM by default. For developers who want to target C# in godot on WASM.The good news is that you can still write your code using Tasks (async/await) and it will work fine on a single thread, then when multithreading becomes available, the code will scale automatically without having to be modified due to how the TaskScheduler works in .NET. So the lack of true multithreading on day one need not be a show stopper. (The only thing needed is a recompile). |
|
I'm also not sure this is the right way to go, but it is ONE way to go, at long last, so I am happy this is being explored. Where I disagree with @Armynator is that theres zero concern about disassembly of the game, as this will be done one way or another. Yes, it's easier with IL, but added obfuscation wouldn't deter determined attackers from stealing or manipulating client binaries. It's also important that an open source project should not actively invest its time and resources to cater to closed source desires (which are not even valid needs). It's fine that closed source is allowed, of course. My concerns with the Mono approach are:
I believe the .NET AoT approach failed because the Godot Engine was being stubborn about entry points. The libgodot project was rather close to a promising solution, that would use .NET's AoT binary as the entry point in WASM. I still think this is the correct way to do it. That said, I'll give the method presented in here a spin to see if I can make my .NET libraries work with it. |
|
It recently got a mention here: https://godotengine.org/article/live-from-godotcon-boston-web-dotnet-prototype/ Not really adding any information that isn't already in this thread, but at least it seem relevant to link the two together here. |
Probably not. Interfaces between our js modules are internal implementation detail. The public JS API is in dotnet.d.ts If you need specific extension point in the startup process we are happy to collaborate.
Not okay to our level of expectations for shipped product.
The known MT issues Dear FOSS community, help appreciated ❤ please ping me if you are willing to troubleshoot some of it. Emulation of pthreads on the WebWorker is very expensive and complex abstraction. Especially if you want DOM/Canvas interaction and synchronous calls from JavaScript at the same time. Here is a design doc I did 2 years ago. Most of demand for MT is from users which want to port legacy MT codebases to Blazor without "what color is your function" rewrite. There is no investment into MT in .NET 10 so far.
I agree with that. There is plenty you can do with async/await. |
|
Actually, the main focus at this stage should be on being able to use web export in GodotC#! Other optimizations, improvements, or breaks can be done gradually. The current proposal by raulsntos feels very worthwhile to try. |
Based on this comment, to dynamically link 2 modules, one must be the And from this comment:
It seems that compiling the .NET runtime as a side module is not feasible. However, is it possible to compile the .NET runtime as a main module, which could then be linked to Godot as the side module? (Ideally this would be a change to the official wasm .NET runtime, so we wouldn't need to compile a custom build ourselves) Has this already been tried? I would guess that Godot as the side module is probably related to LibGodot also. |
When I said it was ok in .net 8 I meant the multithreading was working to a point. but it was only stable on one extra thread. That being said, doing UI updates through jsinterop and the DOM the way UNO Platform does it is still 10 times slower than android and 100 times slower than native windows but for a web app it wasnt too bad compared to other fairly complex web apps. People need to keep their expectations in check, a browser with multithreading is still a browser, so its still has to go through layers or abstraciton and security to get anything done which means its always going to be much slower and worse user experience than native. Even when I look at the bevy engine's wasm demos, they are technically very impressive but still way below the performance of a native 3D app, especially on mobile devices (if the demo even runs)
I think the main reason not many people are helping is because it's fundamentally a .NET runtime and browser problem (aka a problem for microsoft and google to fix). As much as I love the idea of C# multithreading working in the browser, if I can't actually change the code that is broken because it is inside the .net runtime or inside the browser source code then meh. i'll wait. |
|
That last comment on multi-threading confused me. I haven't been actively using Godot in several years now. My recollection of working on a C#-based VR project in Godot 3 a few years ago was that there was no way I could consistently send frames to the headset while a level was having physics objects added because of Godot 3 being single threaded, which made Godot 3's physics effectively unusable for anything that could ever even potentially be accepted in the Quest Store. That was a real roadblock for me. Are you saying Godot 4 is multithreaded now? P.S. About making Godot the side module instead: this has been proposed and tried many times. I think the biggest effort towards it was called libgodot. The basic idea is to turn Godot into a .NET library instead of having Godot accept a .NET library. But as I understand it, the actual Godot dev team decided this was emphatically not a direction they wanted the official project to go in. |
Godot has multithreading, not the whole engine is thread safe but there has been big efforts to make most of the engine thread safe from both internal use and scripting APIs
Libgodot is listed as a priority from the dev team https://godotengine.org/priorities/#allow-compiling-godot-as-a-library however there is still a lot of work to do before it can be merged, also I don't know if it will resolve the issue with C# web. |
|
@Pineappletooth Great information. Much appreciated. |
|
cant we reverse engineer unity's way of handling the webassembly? |
|
@theBSH |
and others
Uh oh!
There was an error while loading. Please reload this page.
Godot version
v4.0.beta10.mono.official [d0398f6]
System information
macOS Monterey 12.5.1 (21G83)
Issue description
In a fresh project created with v4.0beta10 and export templates downloaded and installed, the web export templates files are missing at the expected path. This makes it impossible to create web builds afaik.
Steps to reproduce
Minimal reproduction project
N/A
The text was updated successfully, but these errors were encountered: