Create a complete and concise documentation for GDExtension

[nonunknown]

Describe the project you are working on

A G.O.A.P Implementation for Godotengine via GDExtension

Describe the problem or limitation you are having in your project

Me and a lot of users has little to none knowledge about GDNative and C++, now that GDNative is "deprecated" in 4.x we have even less knowledge about such powerful tool, some of them:

• Classes we have access to
• Classes which are not exposed to API but we can use in C++ side

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

The documentation will have a "Zero to Hero" subject, where a user with basic knowledge of C++ will learn:

• Getting the necessary files to work on
• What is each file in there does
• Generate the bindings (for each platform, and cross-platform)
• Creating the First Extension
• Differences between GDNative and GDExtension
  • Seems after recent changes to GDExtension, you dont need to use generate_bindings anymore, because everytime you recompile example project it compile Godot classes too, but this need to be confirmed!
  • What you couldnt do before and what you can do now.
  • API differences
• Ref<> and * how and when to use them
• Similarities with the core source code
  • How it works in core, and how to reproduce in GDExtension
  • How to deal with virtuals (overriding a C++ function via GDScript, like _ready())
• About Classes from GodotEngine core we can use in C++ but are not exposed in the API
• Creating a simple game
• Creating a simple multiplayer (server/client) and (P2P)
• Creating an editor plugin
• Overriding/Extending Engine features (if possible)
• Compiling your extensions
  • Windows
  • Linux
  • Mac
  • Android (show how to compile in each platform above)
  • Web (show how to compile in each platform above)
• Using GDExtension compiled stuff in C#
• Advanced Stuff
  • Optimization
  • Debugging
  • File Structure
  • Add new stuff to GDScript? (like a new var type, or add a struct system via GDExtension, if possible)
  • Many More
  • Using external graphical/audio APIs (e.g IMGUI), physics libraries....
• C Language
  • Example usage of GDExtension in the C language
  • How Binding GDExtension to another language works (Go,rust,....)

I may have forgot some stuff, so if you're reading this, please comment below suggestions

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

A Complete documentation in the docs page

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

Nope, its a documentation.

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

this cant be addon, since is GDExtension.

[Gnumaru]

Shouldn't this belong to the other project, godot docs?

https://github.com/godotengine/godot-docs/

[nonunknown]

not sure, there is for bugs and enhacements related to existing documentation, @Calinou can confirm?

[Xrayez]

GDExtension appears to be still work-in-progress. But GDExtension without even preliminary documentation/specification is going to be quite useless, by useless I mean this may prevent adoption by potential developers that would like to improve and build upon GDExtension (like me), and those people who could literally speed up the development. I think GDExtension should get more love and support, so I'd leave this proposal here... 😛

I see no technical specification for how GDExtension should work or supposed to work, not even talking about user documentation. So it's more about lack of specification as I see it.

This could potentially be moved to https://github.com/godotengine/godot-proposals/discussions.

See also proposal of mine:

• Promote development of extensions for Godot godot-proposals#3864

[nonunknown]

Yep GDExtension is WIP, which means the best time for thinking about how to present the documentation for end-users is now! Also I dont think GDExtension is "useless" it makes life easier when you need to deal with more advanced stuff, having the benefits of the front-end (godot editor) and back-end (core source code).

[Xrayez]

I dont think GDExtension is "useless" it makes life easier when you need to deal with more advanced stuff, having the benefits of the front-end (godot editor) and back-end (core source code).

See my definition of "useless". If the feature is not documented - nobody knows about it, therefore it cannot be used by most users who are not original developers, hence useless, I should've put "useless" in quotes I guess.

[nonunknown]

yep I got it, but your arfimation "feature is not documented - nobody knows about it" is not true, I know little about C++, also I had little knowledge about GDNative, and even with that I was able to get more or less how GDExtension works, I cant even understand its source code, neither from godot engine. Its all about dedication in the end of the day!

PS: the "example" folder which comes with godot-cpp explain very well how to do basic and advanced stuff.

[azur-wolve]

Who is the developer/contributor responsible of GDExtension?

For now idk what GDExtension will be a part from the GDNative substitution. Its an absolute stranger.

@Xrayez mentioned that GDExtensions could throw some issues for addon/plugin developers (recompilation or something iirc).

So its true that its better discuss GDExtension now before its completion, or we could regret it later..

PS: the "example" folder which comes with godot-cpp explain very well how to do basic and advanced stuff.

Do you mean the "test" folder?

[Xrayez]

@Xrayez mentioned that GDExtensions could throw some issues for addon/plugin developers (recompilation or something iirc).

The difference between GDNative and GDExtension is not substantial in principle. But if GDExtension aims to replicate and/or replace C++ modules development as completely as possible, might as well replicate everything that makes C++ modules development a breeze currently.

Who is the developer/contributor responsible of GDExtension?

I think this is mostly a work by @reduz and @vnen as of now.

[azur-wolve]

Then I understood incorrectly (it was from your discussion to being able to write plugins integrated with the editor on GDScript).

Not sure what was more problematic, if GDNative or Modules. Hopefully GDExtension will solve most of that.

[Xrayez]

Not sure what was more problematic, if GDNative or Modules. Hopefully GDExtension will solve most of that.

Both are equally problematic to be honest, depending on who you ask (user vs developer). Those are actually two different technologies I'd say. See discussion in godotengine/godot-proposals#565 if you really want to delve into this topic more. Ultimately, I think this boils down what kind of approach will be supported the most.

[azur-wolve]

Now I get it:

GDNative → share without re-compile engine, ideal for addons/plugins.

• Can support any language with bindings.
• The bindings can throw problems.

Modules → need re-compile engine, so better if have a high-tier Threadripper, but has not the vulnerabilities of GDNative.

• only support C++
• can be compiled as dynamic library and loaded against the project binary (also can against the Editor?)
• can be compiled as static library within the project binary (release)

Excuse me for asking too much, don't want to bother;
There are additional problems with Godot Modules?

[Xrayez]

• can be compiled as dynamic library and loaded against the project binary (also can against the Editor?)

There's some distinction between dynamic/shared libraries with modules, which are in theory doable but those have issues as well (Godot in particular):

• Godot build with summator shared library failed. godot#56887