Add a build-time option to compile Godot as a shared library (for use in other languages)

[Faolan-Rad]

Describe the project you are working on

I am developing an opensource networked VR game engine in C# called on RhubarbVR
which uses Godot more as a rendering system because I have my own physics, networking, and ECS system which allows me to run rhubarb completely separate from Godot

Describe the problem or limitation you are having in your project

As a C# devloper, I would like to have more control over the DotNet runtime which will fix a lot of bugs using Nuget libraries that have native requirements, and also would like android support with C#

I also think a lot of game engines put too much effort into trying to run .net or mono themselves and start getting performance and platform support problems and other strange problems. When you can let it be used by the systems made by the DotNet community and Microsoft

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Make Godot compile as a shared library which allows you to use pinvoke in C# and allows you to run in any C# runtime which allows you to use DotNet Aot for faster speeds and also allows you to use DotNet 6 android or even can use C# wasm implementation with Godot

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

you run scons library_type=shared_library which will give you a library that you can use with any language that runs C libraries how you bind into Godot is you call libgodot_bind to give the function pointer to your GDExstintion entry point and also optional scene tree load function pointer which can load in the nodes without having a project file. Then for the LibGodot to work is having a GDExstintion implementation and just give it the entry point function after you have loaded the library

Work in progress Implementation

If this enhancement will not be used often, can it be worked around with a few lines of script?

It might not be used that often if people have to compile themselves but if the LibGodotSharp binding was set up on NuGet I can see a lot of C# developers of software using Godot as a UI library

Is there a reason why this should be core and not an add-on in the asset library?

It adds another compiled option to Godot which makes Godot compile as a library

[LinuxUserGD]

See similar proposal #4773

[kisg]

We at Migeran have implemented a similar solution that we used with our new Python binding to embed Godot into the Unreal Editor to allow the export of native Unreal assets including shader graphs into native Godot assets. Check out our blog post here: https://migeran.com/blog/ultimate-asset-pipeline-for-godot-engine

Our implementation has a bit more granular API, than the one shown in the current in-progress PR:

#ifdef __cplusplus

#define GODOT_OK 0
#define GODOT_ERROR -1
#define GODOT_EXIT 1

extern "C" {
#endif

#ifdef GODOT_EXTERNAL
#include <godot/gdnative_interface.h>
#else
#include "core/extension/gdnative_interface.h"
#endif

typedef void(*godot_register_extension_library_func)(const char*, GDNativeInitializationFunction);
typedef int(*godot_load_engine_func)(int, char**);
typedef int(*godot_start_engine_func)();
typedef int(*godot_iterate_engine_func)();
typedef int(*godot_shutdown_engine_func)();

typedef struct {
    godot_register_extension_library_func godot_register_extension_library;
    godot_load_engine_func godot_load_engine;
    godot_start_engine_func godot_start_engine;
    godot_iterate_engine_func godot_iterate_engine;
    godot_shutdown_engine_func godot_shutdown_engine;
} GodotRuntimeAPI;

typedef GodotRuntimeAPI*(*godot_load_library_func)();

GodotRuntimeAPI* godot_load_library();

#ifdef __cplusplus
}
#endif

It is admittedly a raw first draft, but it shows the proposed direction: if the API is more granular, then the host process has more control over how the engine behaves. For example for some use cases, one would not even want to start the main loop of the engine.

Another thing that we planned (but have not yet got around to implementing it) is the integration with the GUI of the host process, e.g. it could be possible to create an abstract interface for the windowing system integration.

This way the regular builds could use the same API inside the main Godot binary and provide a simple platform-specific implementation for opening windows, providing drawing surfaces ... etc.

But this would also open the gate for much larger possibilities, e.g.:

• it would make it possible to embed Godot inside Blender, so Godot could be used as a Viewport implementation. An artist working with Blender could instantly inspect how their creation looks in Godot, without ever leaving Blender.
• we could embed Godot inside the Godot Editor and provide a similar experience to what Unity and Unreal Engine provide in their editors.

We would be happy to contribute patches to the current PR if there is interest.