Join us on our own very special Reddit: /r/Linuxers
Favourite Linux IDE?
Page: «10/11»
  Go to:
tuubi 12 Jul, 2019

Quoting: monnefbecause in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).
I'll take your word for GDNative, but didn't Godot get C# support in 3.0?

monnef 12 Jul, 2019

Quoting: tuubi
Quoting: monnefbecause in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).
I'll take your word for GDNative, but didn't Godot get C# support in 3.0?

Yes, docs for C# are better - well, at least some exist and API is more closer to GDScript, so separate docs for everything are not needed. For GDNative (C++) it, all documentation, was literally one page on wiki which described basic setup with example which didn't work (didn't even compile). There are many differences between C++ and GDScript API, e.g. different types, custom memory management which isn't documented (Godot team is ignoring current C++ features which implement mostly same thing), code within C++ API (bindings) is undocumented too. It was a nightmare to use - if you are not familiar with Godot internals, do yourself a favor and avoid GDNative (with C++) at all costs.

When I was briefly testing C# with Godot, there were some significant downsides - for example missing stack traces after crash, broken project file for C# which had to be manually fixed, more boilerplate compared to GDScript, issues with custom C# types (IIRC struct isn't supported at all = performance problem or use a lot less readable solution), undocumented differences in API compared to GDScript (worst were conversion rules between C# types and GDScript ones, it is not a smooth experience). Performance-wise C# isn't bad (much better than GDScript), but marshalling (converting data between C# and GDScript) is very costly and one has to be careful about memory management (GC). I don't like very much how a lot of things in Godot API is "stringy", it really undermines static typing of C# (and C++).

Simply put, Godot supports GDScript well, nothing else, even though they claim C# and GDNative (C++) are officially supported. One of reasons why I am going back to Unity is because I want to write in a language which is properly supported by the engine, its team and community (by supported I don't only mean technical side, but also docs, guides, tutorials, community, marketplace). Unity is just so much more mature.

For my use-case was quite important debug view which Godot misses (viewing real 2D/3D instances in editor when game is running). Another thing I don't really like is that a node can only hold one script (forcing deep branches in a node tree), cumbersome addressing of these inner nodes, difficult refactoring, missing inheritance or any equivalent mechanism. With Godot I picked C++ because of performance, but it might be possible to reach similar performance in Unity with C# using their custom compiler (so I could write in a reasonably nice language - C#, C++ is for me too low level, unnecessarily complex and wordy). Maybe in a few years I'll try Godot again (after 3D supports basic features like occlusion culling and unlimited number of lights).

tuubi 12 Jul, 2019

Quoting: monnefUnity is just so much more mature.
Well that's a given. :) Godot has some catching up to do. And I do wish it does. I really like the idea of free and open source game engines, even if they're used to produce proprietary games.

Thanks for the insight.

monnef 12 Jul, 2019

Quoting: tuubi
Quoting: monnefUnity is just so much more mature.
Well that's a given. :) Godot has some catching up to do. And I do wish it does.
I am looking forward to the Vulcan rewrite (v. 4), real static types in GDScript (e.g. currently there are no types for custom classes or even interfaces for dictionaries) and at least some FP support (currently there are no anonymous functions, no closures and passing a function is a pain).

To not be entirely off-topic, I should say that GDScript editor (the IDE) quite surprised me, because it makes using (at least writing) those "stringy" APIs a lot easier. For example when you are writing a node path (addressing a node in a node tree) it will suggest you all different currently available paths in proper context (current node).

My last rant: I still don't understand why Godot team refuses to implemented int variant of vector2 and 3 (can be used for example for coordiantes in a desk game or a voxel world). Their recommended "solutions" were either difficult to use, or very slow, or both. This is a major issue, because GDScript doesn't allow defining custom "structs", so a GDScript user cannot implement performant primitive type (that's only possible if you modify engine itself, in C++, and then you will have to maintain your fork if you want to get fixes and new features from main repo).

Quoting: tuubiI really like the idea of free and open source game engines, even if they're used to produce proprietary games.

Thanks for the insight.
Godot being FOSS and having really good Linux support were the top reasons I decided to try it. It definitely has a potential and I believe in a few years it will start competing with "big dogs" in small/middle sized 3D games. :D

PS: I am sorry for the offtopic. If any mod is reading this and if you have some free time, it might be worth clean this up a bit, e.g. duplicating my first post to a new thread and move there all subsequent posts from here. (Not sure how this forum works, I am new here, so maybe I am entirely off.)

appetrosyan 27 Jan

Can't go wrong with Emacs. It's a rock solid editor; cross platform (all I need to instantiate my current config on a windows/Mac machine is to copy the init.el); completely reproducible results, and more importantly it plugs into everything you may want, including eclipse.

The only thing it's missing is a kitchen sink.

vv221 12 Apr

Exclusive vim user here, not even adding plugins to it. I got used to the modal edition really fast, and would not trade it for anything else.

The languages I work the most with are Shell, PHP and a bit of Markdown when writing documentation.

Mendy 27 Jul

Quoting: monnef
Quoting: tuubi
Quoting: monnefbecause in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).
I'll take your word for GDNative, but didn't Godot get C# support in 3.0?

Yes, docs for C# are better - well, at least some exist and API is more closer to GDScript, so separate docs for everything are not needed. For GDNative (C++) it, all documentation, was literally one page on wiki which described basic setup with example which didn't work (didn't even compile). There are many differences between C++ and GDScript API, e.g. different types, custom memory management which isn't documented (Godot team is ignoring current C++ features which implement mostly same thing), code within C++ API (bindings) is undocumented too. It was a nightmare to use - if you are not familiar with Godot internals, do yourself a favor and avoid GDNative (with C++) at all costs.

When I was briefly testing C# with Godot, there were some significant downsides - for example missing stack traces after crash, broken project file for C# which had to be manually fixed, more boilerplate compared to GDScript, issues with custom C# types (IIRC struct isn't supported at all = performance problem or use a lot less readable solution), undocumented differences in API compared to GDScript (worst were conversion rules between C# types and GDScript ones, it is not a smooth experience). Performance-wise C# isn't bad (much better than GDScript), but marshalling (converting data between C# and GDScript) is very costly and one has to be careful about memory management (GC). I don't like very much how a lot of things in Godot API is "stringy", it really undermines static typing of C# (and C++).

Simply put, Godot supports GDScript well, nothing else, even though they claim C# and GDNative (C++) are officially supported. https://uk.edubirdie.com/java-assignment-uk One of reasons why I am going back to Unity is because I want to write in a language which is properly supported by the engine, its team and community (by supported I don't only mean technical side, but also docs, guides, tutorials, community, marketplace). Unity is just so much more mature.

For my use-case was quite important debug view which Godot misses (viewing real 2D/3D instances in editor when game is running). Another thing I don't really like is that a node can only hold one script (forcing deep branches in a node tree), cumbersome addressing of these inner nodes, difficult refactoring, missing inheritance or any equivalent mechanism. With Godot I picked C++ because of performance, but it might be possible to reach similar performance in Unity with C# using their custom compiler (so I could write in a reasonably nice language - C#, C++ is for me too low level, unnecessarily complex and wordy). Maybe in a few years I'll try Godot again (after 3D supports basic features like occlusion culling and unlimited number of lights).

I absolutely agree with you.

Last edited by Mendy on 28 July 2020 at 1:21 pm UTC

Jared 27 Jul

Tough pick between neovim and doom emacs.

TimeFreeze 27 Jul

nano.


Jokes aside i pendle between vim and emacs.

Samsai 27 Jul

Doom Emacs has pretty much entrenched itself in my workflows at this point. Not only do I use it for essentially all coding I'm doing, I have also migrated my IRC, file management and RSS reader over to it and I start it as a user-level systemd service on login, so that I can create quick buffers by just connecting to it using emacsclient.

In terms of just coding, I've found Doom Emacs to be often more powerful than my own Neovim config and Evil does such a good job of emulating Vim keys that I have yet to find a key combination that I used in Vim which isn't available to me now, and sometimes Evil even enhances keybindings to be better than what I'm used to. Last autumn I even found Doom Emacs to be powerful enough that I used it for a Java project without a significant loss in coding efficiency despite Java's tendency to be quite IDE-centric.

Last edited by Samsai on 27 July 2020 at 8:15 pm UTC

While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.

Livestreams & Videos
Community Livestreams
Latest Forum Posts