I needed a way to embed Godot in .NET applications, and ended up facilitating HTML5 export for C# games, too, which really reinvigorated my passion for Godot in game jams. And for boring work, I needed parallel unit testing (across multiple ALCs).
But what is it...? I call it a C# front-end for the Godot engine, but really...
2dog is still Godot
All the Godot goodness still works, including programming with GodotSharp (their official C# SDK) and the 4.7 official editor, which was important to me for stability and trust (also, easier to swap out or extend).
The nuget packages are free and libre open source under the MIT license. 2dog uses libgodot and creates a choice of small .NET "host" applications that you can tailor to your needs - HTML5 browser export, embedding in WinForms, xUnit testing, etc.
Still hot off the press, always happy about visitors to the ⤜outfox⤏ discord or issues on our GitHub.
12 Comments
ZeroGravitas@lemmy.dbzer0.com · 9 pts · 38d
Mad props for the name & logo!
jupiter@programming.dev · 5 pts · 38d
Thank you ^^
domi@lemmy.secnd.me · 4 pts · 37d
I tried exporting our GMTK game jam project but there's an error when running it in browser:
Want me to create an issue for it or is this a known issue?
::: spoiler Full error
:::
jupiter@programming.dev · 4 pts · 37d
Oof, looks like a Godot crash, do you have a public repo with the game jam entry somewhere? I probably have to dig a little deeper, my suspicion is something related to some kind of native function/trampoline being completely missing. (weird)
You could also try to create a source map:
dotnet publish -c Release -p:WasmEmitSymbolMap=true -p:WasmNativeStrip=falsedomi@lemmy.secnd.me · 3 pts · 37d
We started in Forward+ rendering so it is definitely possible that something went wrong when switching to Compatibility renderer. I did a blank test project and everything went fine so it must be something related to the project.
Yes! It's open source and I made a branch with the renderer switched to Compatibility and our water shader removed (incompatible with Compatibility renderer). Should be able to just add 2dog right away and run it. (The regular desktop build runs fine)
You can find it here: https://gitlab.com/gmtk26zbandco/gmtk26-godot-game/-/tree/web-build
I added the source map and the stack trace looks more usable now:
::: spoiler Full error
:::
Thanks for taking the time!
jupiter@programming.dev · 5 pts · 37d
Awesome, thanks for the detailed report and prepared repository to reproduce in.
The failure is a bit different on my end - first I get a bunch of issues trying to serve the blender files (which it shouldn't, on the web, very likely my bug! bad dog, bad dog... - should already be imported), and then I get your crash. Is this what you get, too?Game seems to run okay in the editor. I'm working on making the blender import happen correctly or raise an error during the 2dog import step,
I think this is where it goes wrong. (also, fantastic test case for future tests... I built 2dog because of resource import issues, now resource import bites me in the belly yet again, ha.)Edit: No, the problem is not the missing blender import, after correctly setting it to my blender path I get your behaviour. Which is great, only need to find the missing native trampoline now...
jupiter@programming.dev · 3 pts · 37d
Getting closer, it's GD.PushError and some other functions with 7 parameters under the hood. (a little confused why these aren't generated, or how the native equivalent to GD.PushError("Blah") has 7 params, maybe it tries to look up all candidates) ... I need to do something else for the next hour or so, and then can get back to this. My automated and manual tests always fail on errors so ironically that led to GD.PushError never being tested.
In related news, who ever in the .NET/mono team thought it was a good idea to call native signature strings "cookies" in the context of WASM specifically deserves a villain award... I navigated away from the documentation page three times thinking it was about web cookies.
domi@lemmy.secnd.me · 3 pts · 37d
Awesome! Let me know if you need anything else and feel free to keep the project around as test case.
I think Godot converts the Blender files internally so good to hear that it works now with the path set.
jupiter@programming.dev · 3 pts · 37d
Yay! Your game works! *asterisk...
I released a new release (v4.7.1.59) of 2dog that hardwires all the native WASM trampoline functions. It's one of those bugs that has me scratching my head, as in "how did this ever work?", but it did, including for samples from the Godot foundation, three friends' games, and two of my own. So... mega big thanks for this bug report, this was a big one!
You may need to run
dotnet nuget locals all --clearanddotnet restore --forceor similar to get the fresh packages.Anyway. The asterisk: the loading performance of certain scenes and textures isn't great at all 😓, and I'm working on ways to make that nicer in the web html harness; and I also need to figure out where the majority of that time is spent; sometimes it's WASM compile time, sometimes it's scene load.
PS: Super adorable game idea. That angry beach ball can get bent, though... sheesh. Ey, I'm
walkin'crawlin' here!domi@lemmy.secnd.me · 3 pts · 37d
Yay, that's awesome!
I needed to do a
dotnet dnx 2dogagain after your commands to regenerate the build assets but after that the build worked fine, thanks!To cheer you up: The performance of the regular Godot web version is not all that great either for 3D stuff. It loaded quite quickly on my PC. Throws an error on level load but still works, might just be the shady level loading we did under time pressure.
Glad you liked it! We put a lot of work into this one. :)
Shame I didn't see 2dog during the jam but for next time we are equipped to finally ship a web version. Thanks!
jupiter@programming.dev · 3 pts · 37d
Just try it, in the worst case you have to
git reset --hardandgit clean -dxn/-dxfanddnx 2dog addagain, but I think thedotnet restore --forceshould do it! There's only changes to the native library and the glue code.I plan to use 2dog a lot in future jams... it wasn't quite stable enough for GMTK jam, though, so... something to look forward to in upcoming jams.
jupiter@programming.dev · 1 pts · 35d
v4. 7.1.64 or later should drastically improve loading performance. I find it acceptable with it, if not outstanding of course.
Turns out among other things, I was loading the PCK and the WASM blob twice depending on web server behaviour. 🤪