C++ Scripting Out of the box.

[ywmaa]

Describe the project you are working on

A 3D Hero Shooter game.

Describe the problem or limitation you are having in your project

Currently I am using GD script for all my game logic.

Loving it so far.

Exported on mobile, realized there is a GD script overhead like 5-10 FPS for the scene.

Sounds too little FPS gain ? My scene is somewhat visually heavy/medium. So the game is already running on about 25 FPS

Losing extra 5-10 FPS is not good in my opinion, atleast on that frame count.

Sometimes, some games need to squeeze each possible performance to pour that performance into visuals/Particles, etc.

How I tested this ? Runned my game using a simple camera controller without the player logic and these stuff.

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

C++ is supported in the editor out of the box without needing to resort to GD extension and cloning the godot-cpp library, etc etc.

BTW I think someone may ask why not just use c# ?

Because basically c# platform support depends on Microsoft doing it, like supporting android (which recently happened in Godot 4.2) or supporting IOS, etc, etc.

Also to be fair, I am not a fan of c#, and I have high expectations for c++ plus GD script (just like his GD script calls the underlying functions in the Engine)

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

I am not sure, but I think like c#, include the bindings directly in the engine ?

EDIT Sharing my thoughts on how to implement this idea :

This is the currently known GD Extension structure, I think the best way to achieve what is want in the Editor is

gdextension_cpp_example/
|
+--demo/                  # game example/demo to test the extension
|   |
|   +--main.tscn
|   |
|   +--bin/
|       |
|       +--gdexample.gdextension
|
+--godot-cpp/             # C++ bindings
|
+--src/                   # source code of the extension we are building
|   |
|   +--register_types.cpp
|   +--register_types.h
|   +--gdexample.cpp
|   +--gdexample.h

1- bundle godot-cpp inside the engine source code 2- no src file, the editor looks at the project folder "res://" looks for c++ files, auto register thems by creating register_types automatically 3- a compile button is visible in the editor (like c#), you provide the path to a compiler or setup scons+clang or something just like installing dotnet.

You hit compile, it produces the binaries normally in the bin/ folder in the project files, 4- gdexample.gdextension is generated automatically using the editor

5- you have the ability to enable/disable gdexample.gdextension in the editor (useful for opting-in/out in your c++ code in case it breaks)

So my proposal actually turned into "Simplifying GD Extension a lot"

Quoting Calinou :

The same applies to godot-cpp. It doesn't need to be shipped in every project, and doing so would be detrimental for binary size reasons.

I think it all comes down to if Godot Community wants to sacrifice by increasing Godot Engine size to include c++ by default or not.

Edit 0 : I think this step can be modified

1- bundle godot-cpp inside the engine source code

I don't thing these need to be added to the engine itself maybe added to the editor only, so the final game size will only increase to the bin/ folder which is actually game code.

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

Lol no, it is about adding another scripting language.

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

Scripting Languages core feature of the Engine. And c++ support should be simpler than for example c#, as c# requires dotnet and these stiff.

While the Godot Engine is in itself a c++ engine.

So theoretically if this feature is done in the engine, the user will only need to have scons or clang or something.

[Calinou]

Exported on mobile, realized there is a GD script overhead like 5-10 FPS for the scene.

This sounds like the game logic is written in an inefficient manner, rather than GDScript itself being the bottleneck. Remember that you have a lot less CPU cycles to use on mobile, so all venues for optimization should be explored:

• Run simulation code less often, and less far away.
• Split the CPU load across frames to avoid stuttering.
• Decrease graphics settings, including 3D rendering resolution, camera far clip distance, etc.

Please go through the Optimization tutorials in the documentation.

Sometimes, some games need to squeeze each possible performance to pour that performance into visuals/Particles, etc.

Visuals and particles are handled on the GPU, so there's no competition between the CPU resources used for running GDScript and the GPU. While it is possible to be draw call-bound (and therefore CPU-bound), this is something you should address in the project by reducing draw call count rather than switching scripting languages.

C++ is supported in the editor out of the box without needing to resort to GD extension and cloning the godot-cpp library, etc etc.

There are no plans to have this kind of support, simply because it's not feasible. GDExtension was created to bridge between "native" programming languages and Godot's scripting API. Its predecessor was called GDNative after all.

The way the C# bridge currently works will likely be replaced by GDExtension at some point in the future. This will allow reducing maintenance overhead while also benefiting from future optimizations that GDExtension will feature.

[ywmaa]

This sounds like the game logic is written in an inefficient manner I don't know how non efficient but here is my game code :

https://github.com/ywmaa/Advanced-Movement-System-Godot/blob/master/addons/AMSG/Components/CharacterMovementComponent.gd

This the main Player Movement Script, I extend it and add simple stuff that get executed only when specific thing is pressed like ability_1, ability_2

So is it possible that going through State machine in physics_process is expensive ?

Also the stair_move() function is not used in my project because it is expensive too.

Anyway, I started refactoring my he code to try to move almost every thing to an event based system (use signals) I knew that eventually I will need to do this, but I postponed because I was prototyping most systems.

Now I think it is the time for some optimization for my game since I noticed an overhead.

C# going GD Extension Topic

The way the C# bridge currently works will likely be replaced by GDExtension

But it will be shipped by default in the Editor like now, right ?

If so, why not do the same for c++.

I know requesting c++ feels like game specific, but I think having GD script, c++, c# all out of the box will make the Godot Engine very flexible by default it terms of scripting languages, ex:

You are a team coming from other engines that already utilized c#, your team will probably use Godot's c#.

You are someone who wants to adopt c++ for performance, GD script for prototyping and general usability (this is me) then go for GD script all the way, and only write logic in c++ if GD script shows an overhead.

Also I am someone who likes to develop my game in Godot Engine Dev builds like now I am in Dev 5 of Godot Engine 4.2, because some features show in Dev builds that are somewhat needed for my game.

Now this will probably mean that if I want to use GD Extension I need to always use a stable Godot version.

Why ?

Because there is always a hassle configuring an outside system to match the current state of the engine.

For example for some reason the GD Extension Godot Jolt physics engine, is not working for me in Godot 4.2 Dev 5, I know that Godot jolt latest stuff was for 4.1. But as you see that's an example of why Out Of The Box c++ integration might be needed.

Of course I am not asking to make c++ scripting allow stuff like doing physics engine like this. I mean if write something in GD Extension, an extra Node for example for a Destruction System that extends the RigidBody3D node.

If I update Godot Engine, I will also need to Update my GD extension godot-cpp folder, and recompile, etc, so finally I am able to use the new Godot Engine Version 4.x

Edit : typos

[Calinou]

But it will be shipped by default in the Editor like now, right ?

It won't be shipped by default. You will need to download it separately, as the C# runtime is a large dependency. The editor will likely ask you to do this when it detects a .csproj file in the current project.

The same applies to godot-cpp. It doesn't need to be shipped in every project, and doing so would be detrimental for binary size reasons.

[ywmaa]

Sharing my thoughts on how to implement this idea :

This is the currently known GD Extension structure, I think the best way to achieve what is want in the Editor is

gdextension_cpp_example/
|
+--demo/                  # game example/demo to test the extension
|   |
|   +--main.tscn
|   |
|   +--bin/
|       |
|       +--gdexample.gdextension
|
+--godot-cpp/             # C++ bindings
|
+--src/                   # source code of the extension we are building
|   |
|   +--register_types.cpp
|   +--register_types.h
|   +--gdexample.cpp
|   +--gdexample.h

1- bundle godot-cpp inside the engine source code 2- no src file, the editor looks at the project folder "res://" looks for c++ files, auto register thems by creating register_types automatically 3- a compile button is visible in the editor (like c#), you provide the path to a compiler or setup scons+clang or something just like installing dotnet.

You hit compile, it produces the binaries normally in the bin/ folder in the project files, 4- gdexample.gdextension is generated automatically using the editor

5- you have the ability to enable/disable gdexample.gdextension in the editor (useful for opting-in/out in your c++ code in case it breaks)

So my proposal actually turned into "Simplifying GD Extension a lot"

But maybe as you said

The same applies to godot-cpp. It doesn't need to be shipped in every project, and doing so would be detrimental for binary size reasons.

I think it all comes down to if Godot Community wants to sacrifice by increasing Godot Engine size to include c++ by default or not.

Edit 0 : I think this step can be modified

1- bundle godot-cpp inside the engine source code

I don't thing these need to be added to the engine itself maybe added to the editor only, so the final game size will only increase to the bin/ folder which is actually game code.

[ywmaa]

I will not enter in the merit if proper effort has been made on optimization, as this does not seem the core of the arguments being made.

maybe I didn't clarify, maybe I didn't do the TOP optimizations, but when I write code in GD script, I always think of it as a child that needs care, I can't just through any function and let it handle everything.

for example let's quote the Optimization Page so I can confirm that I take somewhat performance approaches while writing the code :

Hypothesis testing

so I am already doing that, if one Character script needs 5 FPS, what will happen when I add another 5-20 player, still I need to test that by adding random AI that controls the same character script.

Binary search

well :

How I tested this ? Runned my game using a simple camera controller without the player logic and these stuff.

We say that GD script overhead is so little that current CPUs will handle it easily, for casual scripting. but we are talking about my machine Ryzen 7 5800h, an 8 core 16 threads CPU or atleast an i3 which got atleast 4 cores that can handle these stuff.

I can already guess why on mobile I gain 5 FPS when getting rid of the scripts. on my mobile Poco x3 NFC, it uses Snapdragon 732G, a low end mobile ? but I think most people who use mobile phones will probably have specs around this phone. its CPU is no where to compare with my laptop CPU.

it will actually suffer.

yeah Godot Engine 4 should focus on Better Mobile Rendering to gain performance on mobile (I know that there are plans for this, atleast starting with supporting GLES 3).

and maybe I am blaming the wrong system for the performance problems (blaming GD script instead of the current Mobile Renderer)

but in mobile platforms, everything can boost performance, rendering, native scripts like C++, etc. also to not make this topic only specific to mobile platforms, I mean when we go to lower end devices, these optimizations like having C++ support will help.

I can see a case being made for C++ receiving special treatment as the engine itself is written with it

Yes that's a point, and we are here not talking about Rust or Nim, new languages that is rising, nor python to just make python lovers happy (though GD script should make them happy).

We are talking about C++ so these arguments :

X language is popular, so having it in the core editor, will bring more devs Team Y may prefer language Z, so let´s add it. Language K is faster so lets add it.

aren't only valid to C++, but it has advantages too, like almost all platforms Native Support, an Old well tested language for like ~30 years ?

THE NEXT SENTENCE IS JUST AN OPINION AND I DON'T FORCE IT ON ANYONE. I think C++ should have been well supported more than C#, IMO C# is literally a niche language, because Unity Adopted it, it got well known in the Game Dev.

IMO C# is literally a niche language

now I sound like others who want to cut GD script support, but anyway, if this proposal is not going to succeed, I will have to use C#, since I don't want to have to recompile a GD Extension, and I may need that extra performance when I fully port my game to mobile.

[VDev7]

Yeah Why You Can make C# Build On The Download site But Not C++?

[addmix]

There are definitely still some capability gaps with GDExtension, most of which are not present with C#, so I assume as C# shifts towards GDExtension, they will be resolved. Mainly the lack of being able to use C++ code as true scripts, which can be added to nodes, rather than being a new class definition.

If in the future, using C++ in Godot could be as simple as using C#, I think that would be ideal, or at least have out-of-the-box functional templates for godot-cpp and gdextension.