Roadmap for the C++ API?

[xahon]

I know that we can create components in c++, but it's so complex way to create a single component. Every time you need to recompile a bunch of code every single fix. In fact it means that you improving editor every time for your specific project and recompile it again and again of cource. The reasons of implementing c++ as general purpose language in godot is obvious:

1. It's already written in c++ so implementing wouldn't gonna be too hard
2. It's language that is proven self as one of the best for programming languages for games (Static typing, generics, manual memory management)
3. Community will become more. Many of new programmers are afraid of learning new language (Even it looks like python but it's not python). They just will not able to use this language for other activities except godot
4. Many of programmers don't want to use built-in editor. They want to use their favorite IDE/TextEditor but they need a plugin for GDScript (Refactoring, debugging, git parsing support) for it (If it exists at all)

I know that it has c# support but many of programmers hate it (I'm among them). I'm using ubuntu and tried to use unity3d to create a game but my c# code behaved weird and so unpredictably on linux. I like UE4 approach. It has both c++ and blueprints for creating game logic and a button to recompile code in the top-right corner of editor but in godot we need to create it separately and it gives some inconvenience.

Godot one of 3 best crossplatform game engines and I want to contribute but I can't just start to develop a single game because of that problem :)

Sorry for possible mistakes, thanks for reading

[KellyThomas]

Have you looked at gdnative?

[xahon]

@KellyThomas Yes, I'm reading now https://godotengine.org/article/dlscript-here and cannot understand what I should do. I has no built-in editor support

[xahon]

@KellyThomas I've made everything that pages say and scons generated libtest.so. Assigning library in editor to libtest.so crash editor with big stacktrace

[BastiaanOlij]

xahon, this is exactly what GDScript was created for. A simpler language embedded within the game engine that you can use to write the logic of your game. For many games, many many games, it is all you need.

C# support was added for similar goals because there are many game developers out there with existing C# experience who could make the jump to Godot easier if they could use a familiar language.

C++ is a compiled language, that is not a choice Godot made, that is what C++ has been for decades and always will be. You will always need to compile source code, either the core of Godot, or dynamic libraries (GDnative), that is not something we can change. The question I have is why are you starting with C++? Unless you have a specific need to optimize something time critical you're just making your life hard.

If C++ really is the right choice for you, you are starting with an article from 2017, that was before even an alpha of Godot 3 was made available and only people who compile Godot from source could use this. GDNative has changed alot, more then just a change of name, since then.

Follow these instructions will be more fruitful: http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-c-example.html though I should probably polish them up a bit because even since I wrote those instructions, things have been moving forward and I've never had the time to update them to include C++ examples. Things are about to change in 3.1 so that might turn out to be a good thing as Karroffel has been hard at work simplifying the C++ bindings.

Also have a look at this repository: https://github.com/GodotNativeTools/GDNative-demos There are several examples, not all of them have been kept up with the latest changes but there are still some good examples to be found.

Or have a look at the build instructions on some of my modules: https://github.com/BastiaanOlij/gdvnc https://github.com/BastiaanOlij/gdleapmotion For inspiration and ideas.

But I do stress, unless you've got a lot of C++ experience under your belt and writing C++ is second nature, there are easier to use languages out there to write game logic in. Writing that logic in C++ just takes twice as long with often very little benefit if any at all, unless you are writing core logic.

[xahon]

@BastiaanOlij I need a lot of performance critical code like big graphs with many connections and voxel system and other ideas and c++ is the language I know better than c#. I just can't live without iterators and pointers. May be i'm sick but I can't change myself, sorry.

[BastiaanOlij]

@xahon, I'm a C++ buff myself, I love it, but I think it has its purpose and I think there are places where it's less suitable. So I write my game logic happily in GDScript, and then help out writing stuff in the core where needed.

GDNative is probably your best bet, the problem you are simply facing today is that there are still few of us working on that and documentation does suffer, that is something that will improve over time. But its also something that only appeals to a small group of developers.

It depends on what you're graphing but my immediate thought would be to start looking at rethinking your strategy and see how you can use shaders. The GPU is far more powerful then the CPU in processing large amounts of data.

Voxels is a similar story but here Godots cross platform nature works against it as doing voxels on the GPU requires access to compute shaders, geometry shaders and tesselation shaders, most of which are OpenGL 4 territory not available on most deployment targets. So yeah today you would definitely need to go down the GDNative road.

Again, follow some of the links I gave you, and if you get stuck, join us on IRC on #godotengine-gdnative, there are always some of us around offering a helping hand. It would be nice to have some of that build into the IDE but it's far from something that will ever get to the top of the list of priorities unless someone wants it badly and has the time and skill to implement it off course.

[vnen]

While I agree that GDNative (or more precisely NativeScript) should be made as easy as possible to use, in particular the C++ bindings, editing code directly in Godot is probably a bad idea. No way we can compete with existing IDEs (people already complain about GDScript) and there's no reason we should try to compete.

The only thing Godot should add is the functionality to call a build command that you define, so you can compile before playing the project automatically. But it would be up to you to set up a build system and edit your code elsewhere.

The major problem now is the absence of documentation on how to use GDNative and the language bindings.

[raymoo]

@BastiaanOlij I interpreted "graph" to be the data structure, not graph as in graphing a function. It doesn't make sense to talk about a graph of a function having connections.

[BastiaanOlij]

@raymoo, ah, as in ERDs and stuff like that? that wouldn't be very performance intensive though

@vnen documentation will come as there is more and more experience and as the solution solidifies. There is more out there then people know but its not in the right place, distributed among the projects those making GDNative plugins. Fully agree on the IDE.

[vnen]

@BastiaanOlij

documentation will come as there is more and more experience and as the solution solidifies.

Well, that's a double-edged sword. If there's no official documentation, less people will use it (some won't even know it exists), less chance of a proven solution to surface as well. At least a starting point should be given.

[BastiaanOlij]

Well, that's a double-edged sword. If there's no official documentation, less people will use it (some won't even know it exists), less chance of a proven solution to surface as well. At least a starting point should be given.

Yup, it's the old chicken or egg, who came first? Reality is, you need people with experience to write documentation, documentation is nice to have to gain experience but you can do without. It takes people willing to find their way, talking to people like Karroffel and myself, going the hard route, and then willing to share their experience.

I do plan to do a C++ part to the tutorial I wrote for the docs, but I first need to spend the time to learn the newer approach Karroffel has been adding to 3.1 or I'll just end up pointing people in the wrong direction. So far I've mainly just needed the plain C libraries for the work I've been doing, hence being able to write that part of the docs. And truth be told, that is the starting point you're talking about.

[raymoo]

@BastiaanOlij Not sure what the graphs were originally intended for, but I could imagine wanting to do some kind of fluid or electrical simulation for game mechanics, where the graph vertices are machines or junctions and the edges connect then

[BastiaanOlij]

@raymoo that does sound like an interesting thing to see working. Not something I've previously had much experience with so...

[romeojulietthotel]

The title of this is funny. Maybe it could be changed and be made more specific. e.g.

Is their a roadmap for the C++ API?

And then the roadmap could be updated and that starts the ball rolling. And then people become excited as they see a tiny flame of progress is lit. Then they contribute what they can and more people see it and the fire starts. .... ok, getting carried away

https://github.com/godotengine/godot-roadmap/blob/master/ROADMAP.md

[tagcup]

I also agree a tighter integration with compiled languages would be very useful. The current workflow outsources the manual labour most of which could be integrated into Godot, similar to the case with Mono.

[Calinou]

Duplicate of #11080 and #28968.