[WIP] Crossplatform runtime

[Jklawreszuk]

PR Details

As far as I know, it is impossible to create all of Stride's assets outside of the Windows platform. For this reason, developers are still forced to create assets using a program (called AssetCompiler) on Windows just to be able to run the game on other desktop platforms, such as macOS or Linux.

If you currently want to run your game on Linux/Mac, I highly recommend Manio's tutorial: https://youtube.com/watch?v=BoHEASoQvu8

My work primarly focus on bring AssetCompiler on those OS's by refactoring and replacing references strictly tied to Win platform. In my PR, CompilerApp itself can now run on Linux since its a console application, but there is a lot code to port.

I believe that it's quite a difficult and very long task to work smoothly on all desktop platforms, so this PR is also intended to encourage other contributors (both old and new) to get involved in the process. As always, I will be happy to receive any feedback from you, and if you want to help me out, please write a comment or you can send a PR to my fork on this branch.

Current issues / Todo

• [x] - Load asset fonts using SixLabors.Fonts (partialy)
• [x] - getting VHACD to work outside Windows
• [x] - getting DxtLibTex to work on Linux or find replacement (works!)
• [x] - Failing to compile SkyBox asset, because of incorrectly generated GLSL shader
• [ ] - testing, commits and code cleanup

Related Issue

https://github.com/stride3d/stride/issues/360

Edit : Please, treat this branch as unstable, use it as you like if you want Linux support as soon as possible without building anything on Windows. When I consider that the goal is very close to being achieved, I will try to carefully pick changes into other, smaller PR's (see linux-build branch)

Status 17.03.2024: You can compile following assets : 3D Models except FBX, Sprites, Audio, Fonts (Vulkan only)

[jazzay]

Thanks for kicking this off! Perhaps we can collaborate on this in a proper Stride branch at some point.

Couple points of initial feedback:

• We should avoid hardcoding TargetFramework in all the csproj as those changes will conflict with the net8 migration occurring now. That is meant to be configured centrally via the StrideVariables
• While it's nice to clean up code as you go, maybe avoid that for now as it adds a lot of noise to the PR, and could lead to merge conflicts down the road. Not sure the Stride team philosophy here.

[Jklawreszuk]

@jazzay Extra pair of hands is always welcome ! 🙏 Regarding your feedback:

• Good point, we should avoid hard-coding the net version, but I did so since I believe it requires another PR - which'd automate the upgrading process with, for example, one variable.
• As for the second suggestion regarding merge conflicts, this is also a good point, I'll try to leave it for last :)

[froce]

I think it would be better to split up this PR, to keep the individual items more manageable and discussions focused, as it touches multiple unrelated areas. I already have 2 immediate concerns:

• Is there a good .NET replacement for VHACD? Computational Geometry is always hard to get right. Is VHACD not crossplatform or are our bindings the issue?
• Introducing new dependencies. I think we're fine with this license (we, and all our users, would be licensed under Apache 2.0, if I read it correctly), but need to confirm. We already have a dependency on SharpFont, do we need both? Should we switch to SixLabors.Fonts and why?

[JeromyWalsh]

This should be tracked in #1922.

[xen2]

Concerning VHACD (and other C/C++ library we use), unless there's a good alternative in C# that ticks all the box, I wouldn't try to restrict our search only to C# libraries (since demand for such library in C# is smaller, I suspect on average those library are more likely to have less active developers, possibly lower performance and more bugs due to not enough people working on it, and a higher chance to be discontinued resulting in us having to maintain it, etc.).

However, I agree we don't want to keep it how it is right now, with old binaries and hard to replicate build.

The replacement (VHACD or something else) should be something easy for us to build & keep up to date with upstream (possibly with the new nativepath support @jazzay was working on in #1810).

[Jklawreszuk]

~@xen2 Yes, I agree, the idea is to have easy to maintain dependencies, so finding similar projects in C# would be best, but not mandatory. Btw I still considered building the missing VHACD.so binary file for Linux as a temp solution, but I failed to do so myself. If anyone would like to try it themselves, here is the VHACD repo https://github.com/stride3d/BulletSharpPInvoke~ I've managed to build VHACD using gcc --shared ... on Fedora and it loads it perfectly :)