21–30 of 43 posts
* no C/c++ main(), but the sysv ABI entry point (which is basically main() anyway). When the libc will be libdl-ed, the init functions are called with the same arguments stack than the sysv ABI entry point.
* interact with system TLS-ized variable with only the sysv ABI __tls_get_addr(), for instance if there is a need to use errno. I have to admit, I did not get really into this issue yet (but there my be seriously nasty things related to the "TLS offset").
* fork the static gcc/clang libstdc++ in order to libdl-ize it, because even with -static-libstdc++/-static-libgcc options, it won't libdl what it requires from the system libs (gcc devs 100% at fault here, they have been carefully ignoring the availability of games on linux OSes for a decade). rant[on], to avoid this and the dependency on the very few c++ compilers (because c++ syntax is beyond sanity), godot should have been a simple and lean C project, rant[off].
That said, they should od exactly the same on other OSes, which means the code structure would be the same, only different compile-time and runtime function tables.
The godot language server also seems really nice. You just add something like: lspconfig.gdscript.setup({}) to your init.lua (or equivalent in init.vim), then it works with the normal neovim autocomplete. More significantly, it means you can get the really great godot docs in a floaty window bubble without any context-switching.
Earlier quoted context omitted.
How much worse is support for c# than for GDScript? We want to move away from unity and the whole team is already fluent in c#.
Not an expert in Godot and definitely not an expert in C#, but I'd say the only real difference is that the documentation for GDScript is slightly better and there are significantly more tutorials for using GDScript than C# with Godot. All of the functions and concepts that are used in GDScript have an equivalent in C#, and you normally can just use the same function in camelCase. You can use both languages in one pr…
Godot has a lot going for it. Standing in its way was the wide adoption of Unity. I feel that the merger with ironSource maybe removed that hurdle.
Not sure why you have been downvoted as I have seen a lot of that sentiment on twitter and youtube already. I do not believe that this ironSource thing or the comments from the CEO will cause a real downfall of Unity but I do believe that VR is the area where Godot has the chance to sidestep the huge lead of Unity and shine as a real competitor. Because the technology is still changing very rapidly and no one has too…
Godot has a lot going for it. Standing in its way was the wide adoption of Unity. I feel that the merger with ironSource maybe removed that hurdle.
Not sure why you have been downvoted as I have seen a lot of that sentiment on twitter and youtube already. I do not believe that this ironSource thing or the comments from the CEO will cause a real downfall of Unity but I do believe that VR is the area where Godot has the chance to sidestep the huge lead of Unity and shine as a real competitor. Because the technology is still changing very rapidly and no one has too…
Godot has a lot going for it. Standing in its way was the wide adoption of Unity. I feel that the merger with ironSource maybe removed that hurdle.
Earlier quoted context omitted.
It hardly can be considered for a serious commercial project without having a engine team already. But for hobbyist it might become a good choice and the popularity definitly helps.
Might be a nitpick, but there’s also the problem of what exactly we are calling a “serious commercial project”. Right now the most successful game made with Godot Engine is Cruelty Squad ( https://store.steampowered.com/app/1388770/Cruelty_Squad/ ). Regardless of if you would call it “professional” or not, it was one of the most noted indie games of 2021, had great reviews, and probably was much more commercially suc…
Earlier quoted context omitted.
It hardly can be considered for a serious commercial project without having a engine team already. But for hobbyist it might become a good choice and the popularity definitly helps.
Might be a nitpick, but there’s also the problem of what exactly we are calling a “serious commercial project”. Right now the most successful game made with Godot Engine is Cruelty Squad ( https://store.steampowered.com/app/1388770/Cruelty_Squad/ ). Regardless of if you would call it “professional” or not, it was one of the most noted indie games of 2021, had great reviews, and probably was much more commercially suc…
Earlier quoted context omitted.
Not an expert in Godot and definitely not an expert in C#, but I'd say the only real difference is that the documentation for GDScript is slightly better and there are significantly more tutorials for using GDScript than C# with Godot. All of the functions and concepts that are used in GDScript have an equivalent in C#, and you normally can just use the same function in camelCase. You can use both languages in one pr…
What about for C++? Reading the docs, the C++ support seems somewhat of a side-show, and documentation seems patchy on it.
The engine code is great. It's structured logically and navigating it is intuitive. Building the engine is simple, customisable, and documented well. Significant chunks of the engine are integrated as compiled in 'modules'. You can add your own modules and the build system lets you select which modules to include. Adding new node types and working with the scripting/binding system is pretty straight-forward.
I think the documentation for working on the engine[0] and contributing to the project[1] (as well as the code itself) are areas where Godot is doing exceptionally well.
GDNative can be used to integrate external libraries, add support for other languages[2], without compiling the engine. You can use it as a scripting layer, add node types, etc. I haven't used GDNative non-trivially.
* [0] https://docs.godotengine.org/en/stable/development/cpp/index...
* [1] https://docs.godotengine.org/en/stable/community/contributin...