Getting the stride dependencies under control

Building stride is somewhat a pain in itself. A lot of dependencies are pre-compiled. Others are build-in and hugely outdated. And again others have proper replacements. Sometimes you need to find obscure old natives, and find out how to build those for the particular platform and cpu architecture. It would be nice to get this a bit under control, by moving to nuget based dependencies where possible and ensuring stride itself comes without any native (besides the ones the nuget packages provide).

Benefits i see here:

• Getting dependencies under control
• No need to struggle with any msbuild / make / gcc / whatever stuff to get the engine build
• Allow to build the engine (without gui ofcourse) on non-windows systems
• Allow to build the whole stack without having visual studio installed
• Easier upgrading of dependencies and implementation of features
• Making stride itself pure c#

Stride core natives

libCore (Stride.Core)

This natives basicaly contains two things:

• A thread sleep command. Can be replaced with .NET its own Thread.Sleep
• An LZ4 implementation. Can be replaced with https://www.nuget.org/packages/K4os.Compression.LZ4/ (if stide needs lz4 after all! c# has some buildin compression algorythms)

In my eyes this whole native can be replaced by c# stuff?

libStrideAudio (Stride.Audio)

This native basicaly wraps 4 different audio systems:

• Celt. Can be replaced with https://www.nuget.org/packages/Concentus/
• OpenAL. Can be replaced with https://www.nuget.org/packages/Silk.NET.OpenAL/
• OpenSLES
• XAudio2. Can be replaced with https://www.nuget.org/packages/Silk.NET.XAudio/

Technically OpenAL should be one-to-rule-them-all?
Alternatively having XAudio for the Windows world is a nice addition, but this means maintaining two audio systems.
Are Celt and OpenSL ES realy required and do they provide any benefit on supporting even more audio libraries?

libStride (Stride.Native)

This native wraps the following components:

• XInput. Can be replaced with https://www.nuget.org/packages/Silk.NET.XInput/
• FastTextRenderer. This one could be ported to c#
• Lightprobes. This one is complex. Leaving out for the moment, need to check what parts are used.
• SpriteBatchNative. This one could be ported to c#
• StrideNative. This one can be replaced with the c# buildin intrinsics

Stride module natives

libStrideNavigation (Stride.Navigation)

This one is basicaly the navmesh builder and pathfinder.
While being dead, someone already started a managed version: https://www.nuget.org/packages/SharpNav/1.0.0-alpha2
But as this is quite complex, ill not go into detail here.

libStrideVR (Stride.VirtualReality)

This native basicaly wrapps VR systems. This is quite specific, but there is also https://www.nuget.org/packages/Silk.NET.OpenXR/
Silks OpenXR namespace contains several bindings to different (and more then stride current has) vr systems.

Dependencies

Basically stuff from the deps/ folder

• AssemblyProcessor
• AssImp - https://www.nuget.org/packages/Silk.NET.Assimp/
• ATITC - I think this should be removeable.
• BulletPhysics - I would suggest replacing this with https://www.nuget.org/packages/BepuPhysics/
• CppNet - I would suggest using a managed networking library like https://www.nuget.org/packages/LiteNetLib/
• ExpressionBlendSDK - Is this realy in use?
• FBX SDK - This should be part of AssImp. However i would suggest replacing FBX with GLTF. https://www.nuget.org/packages/SharpGLTF.Core/
• FFmpeg - https://www.nuget.org/packages/Xabe.FFmpeg/
• FreeImage - I would suggest replacing this by https://www.nuget.org/packages/SixLabors.ImageSharp/
• Freetype - I would suggest replacing this by https://www.nuget.org/packages/SixLabors.Fonts/
• HtmlRenderer - Where is this used? Do we realy need this? If its gui only, we now have stuff like https://www.nuget.org/packages/Microsoft.Web.WebView2
• Irony
• LibGit2 - Where is this used? Do we realy need this? If, we can use a package like for that https://www.nuget.org/packages/LibGit2Sharp/
• LLVM - This is just used for cross-compiling the natives. When no more natives are used, the whole LLVM stack can be removed.
• MoltenVK - This should be bundled with the vulkan wrappers.
• MonoLinker - Why is this used? Wont the building c# reflections be enough?
• MSDFGEN - This one could be ported to c# if we need it at runtime.
• NuGet - There is no need to include a nuget.exe as its buildin in modern .NET
• SSH.NET - Where do we need ssh bindings for? Anyway, there is https://www.nuget.org/packages/SSH.NET/
• TextureWrappers - Do we realy need this?
• VHACD - I guess its for efficient collision model generation? Need to do some research on this one...
• WindowsAPICodePack - What do we need this for? Video playback? Need to do some research on a proper video package...

Other stuff

I would suggest aiming for vulkan-first with Direct3D and OpenGL as fallback backends.
https://www.nuget.org/packages/Silk.NET.Vulkan/
https://www.nuget.org/packages/Silk.NET.Direct3D12/
https://www.nuget.org/packages/Silk.NET.Direct3D11/
https://www.nuget.org/packages/Silk.NET.Direct3D9/
https://www.nuget.org/packages/Silk.NET.OpenGL/

For windowing, currently SDL is used. We could keep that or add in GLFW as alternative:
https://www.nuget.org/packages/Silk.NET.SDL/
https://www.nuget.org/packages/Silk.NET.GLFW/

Start by inventorying the deps/ folder and the native modules listed in the issue, including Stride.Core, Stride.Audio, Stride.Native, Stride.Navigation, and Stride.VirtualReality. Trace where each dependency is used before selecting a narrowly scoped migration. Done would require an agreed dependency plan and verified builds across the supported targets.