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 notifications@github.com 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/compilingfor 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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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" notifications@github.com 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 < notifications@github.com> 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 .

— 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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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.