Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merging orchestrator with blazium(fork of godot) #822

Open
itzdect4tor opened this issue Oct 20, 2024 · 4 comments
Open

merging orchestrator with blazium(fork of godot) #822

itzdect4tor opened this issue Oct 20, 2024 · 4 comments
Labels
kind/enhancement New feature or request under discussion Not yet actionable, under discussion.

Comments

@itzdect4tor
Copy link

Description

i asked the developers of blazium if they can add orchestrator as offical visual scripting for blazium and they said they will do it if the developers of orchestrator willing to make it a module , is that is possible ?

Implementation ideas

No response

@itzdect4tor itzdect4tor added the kind/enhancement New feature or request label Oct 20, 2024
@esklarski
Copy link

esklarski commented Oct 21, 2024

It can be done, though I know nothing of the process.

I did recently encounter a person that converted the Terrain3D GDExtension to a module:
DanielSnd/Terrain3D@67a6315

So it is possible. But I certainly wouldn't guarantee it works.

@Naros Naros added the under discussion Not yet actionable, under discussion. label Oct 23, 2024
@Ughuuu
Copy link

Ughuuu commented Nov 2, 2024

Ok, I was obsessed with this (for the godot-sandbox and godot-rapier plugins). I wanted to make it work. I made a bunch of proposals to make it work. I was trying to make building for gdextension to be similar as to building for module. I tried with ifdefs, with python codegen, etc. It is not simple. There are differences between godot-cpp includes and function names and parameters and godot includes, function names and parameters.
While I wanted it to work a lot, it just didn't. So I thought of another way, easier to do.
Here it is:

  1. make the current gdextension that builds dynamic libs build static libs. (pretty simple change, won't destroy the codebase completely like ifdefs do).
  2. make a small module that encapsulates the static lib, and at build time link with it.

Thats it!

Downsides:

  • not as big of a performance gain I guess?
  • probably some size increase that can be removed after final build (I think?)

@tehKaiN
Copy link

tehKaiN commented Nov 8, 2024

There are differences between godot-cpp includes and function names and parameters and godot includes, function names and parameters.

Do you have some extra specifics on where the differences are? I might need to tackle it soon (unrelated to blazium stuff though) and the gdextension approach is sadly a no-go for me.

@Ughuuu
Copy link

Ughuuu commented Nov 8, 2024

Well the solution I am proposing is to not change the code of orchestrator, but instead the build system. I added this repo that serves as documentation on how this can be done: https://github.com/Ughuuu/gdextension-to-module
I also already ported godot-sandbox to module using this technique. If you wanna give it a go, there are some things that will need to be moved/ported before with this technique, or any techinque:

  • There are some icons, in module it needs to be in the icons folder. This can be done at build step to package everything in one module folder.
  • There are 2 files, 1 .tscn and 1 .gd that won't be able to be packaged with module. These need to be rewritten in cpp.

Aside for that, the build system will need to build static libs too (or build them the moment the static lib is done).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request under discussion Not yet actionable, under discussion.
Projects
None yet
Development

No branches or pull requests

5 participants