Hi all,
I found Flax while researching the various C/C++ -based 3D engines/libs of the “Linux-able, source-avail-or-open, maintained, has more than just basic draw-call wrappers” kind (ie. some terrain story, some physics story, some PBR & post-FX story etc.)
I almost dropped Flax from my list of candidates due to .NET here. But then the many rave-reviewy comments on Flax in the GamesFromScratch YT channel’s Flax vids made me reconsider.
So here I am to ask how deeply this “infests” the system as a whole (at runtime! never mind edit time), assuming one wishes to program all gameplay logics in C++.
The known: I understand I can “script” / code a game purely in C++ from VSCode with presumably F5-running, never needing to see or read or write or call C#. So far so good. (I don’t care for editor/GUI here for the things I want to explore/experiment, where code-first/code-only is anyway the sole story.)
Question 1: does .NET Framework then constitute a client-system dependency? Shipping a Linux release build to a buddy to beta-test, do they need to pacman -S dotnet
or sth. For that matter: do hypothetical future “end users”? (Ie. actual players. Hi mom! ) — ie. I don’t know whether nowadays “.NET AOT” means native-binary compile outputs.
Question 2: runtime garbage collections possible from the “managed” side, when not C#-scripting? — ie., does the engine’s core runtime codebase (ignoring both editor and build system, but meaning the release-shipped game-running code paths), depend on or call into .NET APIs or its own (if any) C# code-base parts?
These aren’t deal-breakers necessarily, rather I just want to intuit this better as I start to work things out with Flax from C++ & VSCode.