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. 🤪
Just try it, in the worst case you have to git reset --hard and git clean -dxn / -dxf and dnx 2dog add again, but I think the dotnet restore --force should 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.
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 --clear and dotnet restore --force or 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!
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.
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...
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=false
This is actually a piece of beauty. I'm not entirely sure about the case when RND(R) is zero, but it's an astronomically small chance.
Thank you ^^
I, for one, welcome our new robot overlord!
I made another oopsie, I mean, Open Sourcie. :3
Remember Haskell's newtype? Or F# type abbreviations?
Well, newtype is a package that lets you use similar semantics in #CSharp for a large number of types, including the ability to add semantics and extension-like methods to your own derived types.
MIT-Licensed, go wild!
(this is my first post on lemmy, I hope this works like I expect it does. critique and advice are very welcome and appreciated)
fennecs 🔗
Hello, I'm tiger (aka jupiter), and since earlier this year I've been working on a free, libre, and open source Entity-Component System in pure C# that aims to minimize boilerplate and dependencies, works without code generators, and give decent flexibility and performance.
Who is it for?
ECS are an architecture to apply game or other logic to large numbers (ballpark: tens and hundreds of thousands) of objects or actors in an interactive game or simulation, and ECS libraries usually enable expressive composition that go beyond the the intrinsic optimizations of keeping data close together in memory.
fennecs is lightweight and works well with Godot 4.x, The NuGet package is going into its 0.6.0 release soon (about 20 releases so far - see the roadmap)
fennecs is made to operate in just about any sufficiently advanced .NET environment (.NET 8 or later), sadly this precludes using it with Unity for about another two years - but it was created after I spent around five years working with DOTS and coming to the conclusion that it is just too heavy on boilerplate for small teams or solo developers.
There are two simple demos for Godot, a demo for the Stride engine, and when I or one of the other contributors get around to it, demos for raylib_cs, Flax, MonoGame, and others are coming, as well as more demos for Godot.
Possibly ShapeEngine and especially Murder Engine are first in line, though.
What would I like?
Easy - I'd love to hear your thoughts or questions about it if you find the time. It means the world to me to hear other viewpoints or discuss features and contributions with the wider public.
Performance?
Funny you should ask. Everywhere I post, somehow with ECS this appears to be the first question.
Even though top performance isn't the focus (minimum boilerplate is!), thanks to its compact memory layout, fennecs is doing quite all right in Doraku's synthetic C# ECS benchmarks; of which you can find an excerpt on fennecs's github. Performance hardliners can rest assured that another optimization pass comes with the 0.7.x release cycle, after the SIMD interfaces are made available.
Unique traits
fennecs is relational, allowing grouping entities by data-backed relations with other entities (bob owes alice) that are automatically cleaned on entity despawn; by link objects (in physics world P); and soon by arbitrary typed secondary keys (version 0.6.x).
Its Stream Views allow code to access the contiguous storage components are stored in in various ways (including just the raw memory to submit to GPUs or game engines),
Batch operations can modify whole groups of entities or components at once, in a fast and intuitive way.
The SIMD operators currently in development are likely to keep fennecs at the forefront for a wide variety of typical tasks, such as integrating positions and accelerations, matrix transforms, increments, etc.
SIMD ops internally use AVX2, SSE2, and AdvSIMD intrinsics to vectorize their operations where possible, and more complex operations can be composed by sequential ops.
This field is where fennecs' "low boilerplate" design goal doesn't clash with actual high performance and systems programming, and it is great for the optimization stages in game development.
Each release has close to 100% unit test coverage, and because it's pure C#, debugging, inspection and refactoring tools work very well with it.
One last, hidden advantage of being pure C# is that fennecs keeps its data in the .NET domain. Potential performance drawbacks of this are compensated very well by having to marshal function calls and component data back and forth much less frequently than many native-code ECS with C# bindings would.