Godot: Why does Godot have to make it really complicated to set up the ability to use C++?

[Raj2032]

According to this article

Why is it so difficult to just to set up the ability to use C++ In Godot 3.0? Users are able to just create a GDScript with ease but for some reason if a user wants to use C++ they have to do a whole lot just to get it to work, I wish that everything just comes straight out of the box

Please so correct me if I am wrong.

[haxpor]

Godot is designed for devs to make game with scripting language, reduce compile and build time. So you can change things around while you are running the game.

C++ can kick in to help optimize certain part of the game. Part that requires high computation workload, or part that when you tested it's too slow. Thus you do that in C++ by creating a C++ custom module. Creating such custom module is not straight forward as compared to writing code with GDScript. You have to re-compile Godot engine for all your target platforms as well (but you can also do cross-compile either to Linux/Windows from macOS, or to macOS from Linux/Windows, so it's doable enough). Links I referenced are based on v.2.1, so notice at the bottom of the page for those official document whether it's 2.1, or latest (latest means 3.0 onwards).

But to-be-released Godot 3.0 will make this writing in C++ easier, and accessible without re-compilation of the engine itself. It makes use of shared library (through what called GDNative), that the engine can dynamically link to your custom module in run-time. You can see example of creating such a custom GDNative ones here.

So in short, code in general would be coded in GDScript but for certain areas you can do it in C++. If you really want to do C++ fully for your game, see this comment. I agree with his answer in the link, you will still need to hook up entry point i.e. node, scene in Godot editor then hook up to call your C++ module. Anyway, the niffty gritty core part of your game can definitely be coded in C++.

[Raj2032]

So if Godot 3.0 was fully released, it would be much easier to create a C++
script without having to do so much, like GDScript compared to now?

On Wed, Dec 20, 2017 at 2:53 PM, Wasin Thonkaew [e-mail]
wrote:

Godot is designed for devs to make game with scripting language, reduce
compile and build time. So you can change things around while you are
running the game.

C++ can kick in to help optimize certain part of the game. Part that
requires high computation workload, or part that when you tested it's too
slow. Thus you do that in C++ by creating a C++ custom module
http://docs.godotengine.org/en/stable/development/cpp/custom_modules_in_cpp.html.
Creating such custom module is not straight forward as compared to writing
code with GDScript. You have to re-compile Godot engine for all your target
platforms as well (but you can also do cross-compile either [to
Linux/Windows from macOS(http://docs.godotengine.
org/en/stable/development/compiling/compiling_for_
windows.html#cross-compiling-for-windows-from-other-operating-systems),
or to macOS from Linux/Windows
http://docs.godotengine.org/en/stable/development/compiling/compiling_for_osx.html#cross-compiling,
so it's doable enough). Links I referenced are based on v.2.1, so notice at
the bottom of the page for those official document whether it's 2.1, or
latest (latest means 3.0 onwards).

But to-be-released Godot 3.0 will make this writing in C++ easier, and
accessible without re-compilation of the engine itself. It makes use of
shared library (through what called GDNative
https://godotengine.org/article/dlscript-here), that the engine can
dynamically link to your custom module in run-time. You can see example of
creating such a custom GDNative ones here
https://github.com/GodotNativeTools/GDNative-demos.

So in short, code in general would be coded in GDScript but for certain
areas you can do it in C++. If you really want to do C++ fully for your
game, see this comment
https://godotengine.org/qa/8800/can-i-write-a-full-game-with-just-c-or-is-gdscript-necessary.
I agree with his answer in the link, you will still need to hook up entry
point i.e. node, scene in Godot editor then hook up to call your C++
module. Anyway, the niffty gritty core part of your game can definitely be
coded in C++.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-352957845,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79Bir3DtptWaYVfTt0x-uYPkN5fm_Fks5tCITQgaJpZM4RH22t
.

[vnen]

Most of the setup is something you do only once. The bindings should be updated every time you update the engine, which won't be quite often unless you're following the master branch quite closely (which should only be made by users who know what they're doing, so it's not much of a hassle).

It is difficult to set up a C++ build system if you're a beginner, especially so on Windows. This not something Godot can help you with. If you want to use C++ you should know how to use it. It's out of Godot's purpose to provide a full cross-platform C++ build-system inside the editor software. This makes it easier for us and more flexible for users who are already acquainted with their tools.

When Godot 3 is actually released, I assume there'll be an easy-to-get version of the bindings, since it'll have a tag anchor to and won't have to deal with daily changes.

[Raj2032]

So what about NativeScript, is it something I am able to use straight out
of the box?

On Wed, Dec 20, 2017 at 3:10 PM, George Marques [e-mail]
wrote:

Most of the setup is something you do only once. The bindings should be
updated every time you update the engine, which won't be quite often unless
you're following the master branch quite closely (which should only be made
by users who know what they're doing, so it's much of a hassle).

It is difficult to set up a C++ build system if you're a beginner,
especially so on Windows. This not something Godot can help you with. If
you want to use C++ you should know how to use it. It's out of Godot's
purpose to provide a full cross-platform C++ build-system inside the editor
software. This makes it easier for us and more flexible for users who are
already acquainted with their tools.

When Godot 3 is actually released, I assume there'll be an easy-to-get
version of the bindings, since it'll have a tag anchor to and won't have to
deal with daily changes.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-352959834,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79BtXUsXWQv0FORPyBSANms2e1C26-ks5tCIjEgaJpZM4RH22t
.

[DriNeo]

There is a repository for the cpp bindings.

https://github.com/GodotNativeTools/godot-cpp/issues?q=is%3Aopen+is%3Aissue

[blurymind]

I guess a better question would be - is there something that can be done to make the initial setup to use a c++ library or write a c++ script in godot more automatic/faster, while still leaving room to do it manually if needed of course.
A macro that automatically creates the right folders inside the project ,populates them and creates the links perhaps?

It's a better starting point than nothing and having to manually navigate to another repository to copy files from. If the initial setup process doesn't vary too much, it would really help if godot's editor tries to save us some of the steps. It has built in methods to that could be used to automate it - the asset manager/assetlib can already do a lot of the functionality

Also should the editor download the header files from a repository (assetlib/github?) or should it have them included in the list of optional things people download- such as the export templates?
It could be treated like an optional module to the editor- the way the export templates are

Anything to remove the need for people to manually download it every single time they start a new project with c++ scripts

[Raj2032]

Sounds better to me, why not have an automatic process that deals with this
shit?

On Fri, Dec 22, 2017 at 1:37 AM, Todor Imreorov [e-mail]
wrote:

I guess a better question would be - is there something that can be done
to make the initial setup to use a c++ library in godot more automatic.
A macro that automatically creates the right folders and creates the links
perhaps?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-353366348,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79Bi_cB6c-zRA_SbYSWvmsU-iWw93yks5tCm1BgaJpZM4RH22t
.

[akien-mga]

Sounds better to me, why not have an automatic process that deals with this shit?

Please stay polite and constructive.

[Raj2032]

May I know what do you mean I was agreeing with the other user's 'what
better question I should have asked' and then asked why not have an
automatic process that deals with automatically setting up using a C++
library.

On Fri, Dec 22, 2017 at 10:30 AM, Rémi Verschelde [e-mail]
wrote:

Sounds better to me, why not have an automatic process that deals with
this shit?

Please stay polite and constructive.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-353483684,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79BnZUWDOBx2yc0aptZv-6pOQmL2zgks5tCuoSgaJpZM4RH22t
.

[blurymind]

Dont use words like "shit" to describe the process

On 21 Dec 2017 23:39, "Raj2032" [e-mail] wrote:

May I know what do you mean I was agreeing with the other user's 'what
better question I should have asked' and then asked why not have an
automatic process that deals with automatically setting up using a C++
library.

On Fri, Dec 22, 2017 at 10:30 AM, Rémi Verschelde <
[email protected]>
wrote:

Sounds better to me, why not have an automatic process that deals with
this shit?

Please stay polite and constructive.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
14856#issuecomment-353483684>,
or mute the thread
auth/Ab79BnZUWDOBx2yc0aptZv-6pOQmL2zgks5tCuoSgaJpZM4RH22t>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-353485022,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMbVe5OSmI5GBhgHtfRkDZcK8LMawnsks5tCuwsgaJpZM4RH22t
.

[LinuxUserGD]

Linux: bash
Windows: batch
--> add a shortcut to the batch / .sh
--> automatic process

[willnationsdev]

I created a pull request to help address this: #15489
It should make it easier for individuals to create an EditorPlugin that explicitly streamlines a build process for users who need a particular build tool on a particular platform. I might, for example, create a scons-based Visual Studio 2017 build tool for the Windows x64 OS. And then if people want to contribute to such a plugin with their own configurations, that could work too. Whatever the plugin is would let people develop it separately from the core engine without all the dependencies that entails, and it would all be entirely optional. This is the best of both worlds, in terms of accessibility and control.

[Raj2032]

Thanks for creating the pull request, I can wait for it be released :)

On Thu, Jan 11, 2018 at 4:57 AM, Will Nations [e-mail]
wrote:

I created a pull request to help address this: #15489
https://github.com/godotengine/godot/pull/15489
It should make it easier for individuals to create an EditorPlugin that
explicitly streamlines a build process for users who need a particular
build tool on a particular platform. I might, for example, create a
scons-based Visual Studio 2017 build tool for the Windows x64 OS. And then
if people want to contribute to such a plugin with their own
configurations, that could work too. Whatever the plugin is would let
people develop it separately from the core engine without all the
dependencies that entails, and it would all be entirely optional. This is
the best of both worlds, in terms of accessibility and control.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-356683725,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79BoVO26ZRO41oEKe11GPYFtChVOpdks5tJPocgaJpZM4RH22t
.

[dynamite-ready]

Describing my experience, I think the GDNative tools are a great idea (if only for linking dynamic libraries, which I understand you can't do in modules), but the tooling and documentation right now are challenging to use, to put it politely. For example, to build the C++ bindings, I had no reference to work with, which makes the learning experience frustrating, for example:

• I needed to have installed Godot from scratch to compile the project. That was a bit of a surprise. Can't the components that are required from the main project be included in the bindings project? That would be a quick win, because the binding build process is buggy on Windows (I needed to hack the SCons file to make it run on my machine).

• The example in the C++ bindings readme didn't work without a code change (the maintainer made an update, but did not reflect that change in the example project).

• Partly because it's new, documentation is thin on the ground, but there appears to be a fair amount of domain specific stuff to learn once you actually get the libraries to link (i.e. 'variant' objects, and how to expose class methods). This means crashing on test (after managing to compile _something_...), with very little clue as to cause.

If you compare the documentation around GDNative to the documentation around the Godot module system, there's a world of difference. I was able to get started with modules after little more than an hour of reading. What's more, there are some good, clean examples examples out there to learn from.

That said, I also accept that part of my experience might just be RTFM, or 'git gud', so this is just an opinion.

[Raj2032]

I wouldn't really want to use C++ bindings as it would require me to
recompile the engine everytime I wanted to add something. I am probably now
going to use NativeScript D as D is more simpler to use compared to C++.

On Tue, Jan 16, 2018 at 10:01 PM, dynamite-ready [e-mail]
wrote:

Describing my experience, I think the GDNative tools are a great idea, but
the tooling and documentation right now are challenging to use, to put it
politely. For example, to build the C++ bindings, I had no reference to
work with, which makes the learning experience frustrating, for example:

-

I needed to have installed Godot from scratch to compile the project.
That was a bit of a surprise. Can't the components that are required from
the main project be included in the bindings project? That would be a quick
win, because the binding build process is buggy on Windows (I needed to
hack the SCons file to make it run on my machine).
-

The example in the C++ bindings readme didn't work without a code
change (the maintainer made an update, but did not reflect that change in
the example project).
-

Partly because it's new, documentation is thin on the ground, but
there appears to be a fair amount of domain specific stuff to learn once
you actually get the libraries to link (i.e. 'variant' objects, and how to
expose class methods). This means crashing on test, with very little clues
as to cause.

If you compare the documentation around GDNative to the documentation
around the Godot module system, there's a world of difference. I was able
to get started with modules after little more than an hour of reading.
What's more, there are some good, clean examples examples out there to
learn from.

That said, I also accept that part of my experience might just be RTFM, or
'git gud', so this is just an opinion.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-357926030,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79BmQBnnI4bAsNHly1y-sHTB8f32SWks5tLIF-gaJpZM4RH22t
.

[vnen]

@dynamite-ready for the bindings, once there's a stable release to anchor too, I'm sure they'll provide something ready to use. Also, the module system exists since ever, while GDNative is a new addition and still in flux, so there's not much documentation or examples to use.

@Raj2032

I wouldn't really want to use C++ bindings as it would require me to
recompile the engine everytime I wanted to add something.

This is not true. As of now you would need to compile the engine and the bindings once. After that you just need to recompile your own code. C++ and D bindings work in the same way, using the same interface.

[Raj2032]

Is C++ and D bindings meant to be used for game development, just like
NativeScript C++ and NativeScript D?

On Wed, Jan 17, 2018 at 3:12 AM, George Marques [e-mail]
wrote:

@dynamite-ready https://github.com/dynamite-ready for the bindings,
once there's a stable release to anchor too, I'm sure they'll provide
something ready to use. Also, the module system exists since ever, while
GDNative is a new addition and still in flux, so there's not much
documentation or examples to use.

@Raj2032 https://github.com/raj2032

I wouldn't really want to use C++ bindings as it would require me to
recompile the engine everytime I wanted to add something.

This is not true. As of now you would need to compile the engine and the
bindings once. After that you just need to recompile your own code. C++
and D bindings work in the same way, using the same interface.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-358014427,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79BgRNv-BkOaOGSksmffrswhvvJwRiks5tLMp_gaJpZM4RH22t
.

[vnen]

Is C++ and D bindings meant to be used for game development, just like NativeScript C++ and NativeScript D?

There's a bit of confusion with this question. NativeScript is meant to use libraries as scripts, and provides a C API for that. The C++ and D bindings let you use those languages to make NativeScript libraries, instead of C.

So "C++ and D bindings" and "NativeScript C++ and NativeScript D" are the same thing.

[Raj2032]

Oh cool I get it now.

On Wed, Jan 17, 2018 at 10:59 AM, George Marques [e-mail]
wrote:

Is C++ and D bindings meant to be used for game development, just like
NativeScript C++ and NativeScript D?

There's a bit of confusion with this question. NativeScript is meant to
use libraries as scripts, and provides a C API for that. The C++ and D
bindings let you use those languages to make NativeScript libraries,
instead of C.

So "C++ and D bindings" and "NativeScript C++ and NativeScript D" are the
same thing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14856#issuecomment-358148393,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ab79Bi6FNsubXIsuS0T6fnaVWihG1a-Sks5tLTfegaJpZM4RH22t
.

[akien-mga]

I think the question has been vastly answered, so closing.