Like many people, I’ve spent the last few days looking for the new Unity. Godot has some potential, especially if it can take advantage of an influx of dev talent to drive rapid improvement. Open source is cool like that. However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch.
  • @CaptDust@sh.itjust.works
    37•1 year ago

    Juan Linietsky’s (reduzio) response:

    This article is very interesting. Just want to note that this is something we are aware of and the intention is to work it on in two fronts:

    • From the binder API, adding a struct type, to pass these results more efficiently.
    • The GDExtension side can already expose these structs to the binder API with a proper layout description, but the C# in support has not been moved to it yet (its one of the missing steps to merge both the C# and default editor).

    So basically, this area of the engine is a work in progress. To do this also we had to finalize the system to provide compatibility functions to older builds of Godot libraries and extensions as a prerequisite and this was completed in 4.1. Fortunately there is not a lot of the API exposed this way, the majority uses more efficient interfaces. This is more part of the legacy code that is being modernized. None of this is particularly complex to do, but the demand has not been high enough so other things are prioritized. I am hoping your article motivates some contributors to do it :)

    Give us a bit of time. Everything is kind of a mess because of the suddendly increased interest of several users and companies on the C# side. This work has to be properly organized but the general idea is that funding will be used to make sure all works as smooth as possible.

    From https://old.reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k16982q/

    • @YurkshireLad@lemmy.caEnglish
      13•1 year ago

      Hopefully the sudden interest in Godot will bring experienced/knowledgeable people who want to address performance issues and want to improve the engine, rather than only use it to create games/apps.

    • Ferk
      2•1 year ago

      I wonder: are these inefficiencies only relevant when using C# as your code base?

      I mean, does all this talk about the “binding layer” being "structurally built to be slow " apply to those using GDscript?

      Because I remember that years ago, back when it was decided to go with a custom designed language (GDScript), the justification put forward was that it would actually be more efficient to do it that way. So it would be kind of ironic if now the API from GDExtensions allows for more efficient bindings than GDScript.

      But if it’s only talking about the C# bindings… then the complaints are kind of missing the point. If you truly want to move from Unity to Godot properly, I would expect learning GDScript would be the more advisable direction. Specially at the moment. Godot’s C# API and the new native interfaces are not really very mature, they were not the intended main way to use the engine… they are more of an extra convenient feature on the side that you can experiment with. In fact I believe they were recently heavily reworked in v4.0

      Of course I understand that those coming from Unity would be more comfortable with a C# API, and I agree that it would be a nice thing if the C# API was just as efficient as the GDScript API, but that’s not the same thing as implying that moving to Godot doesn’t work because it’s “built to be slow”…

      • bram dingelstad :nb_flag:
        5•1 year ago

        @Ferk hey, professional Godot developer here

        i’ve ran a lot of projects over the years: you rarely make code that runs in a way that these inefficiencies become a problem.

        in order for this to be the bottleneck, you need to run really efficient code already, which is what 99% of problems dont require

        its more of a non-issue unless you’re doing highly specific work :)

        yes, technically you can reduce overhead by compiling a GDExtension, but for most people this is overkill ✨

        • @Octorine@midwest.socialEnglish
          4•1 year ago

          Are you sure this isn’t selection bias?

          Is it really that the the Godot approach is fast enough most of the time, or is it that everyone who needs perf has just decided to use something else.

        • Ferk
          1•1 year ago

          Thanks for the insight!
          I assume you are talking about compiling a GDExtension using C or some lower level language, right? not C#
          What I’m wondering is if it’d actually be more efficient to use C# than GDScript in Godot. Because I would have expected the opposite.

          • bram dingelstad :nb_flag:
            2•1 year ago

            @Ferk we’re using Rust with GDNative

            the reason not being performance, but language features (Rust makes it easy to have good safety guarantees)

            C# is overall more performant than GDScript, but it is rare that you get to use that performance in a way that it makes a measurable difference

            i always just tell people to work with what they know well and what makes them feel comfortable, thats the most important

            great part about godot: you can run these languages side by side ✨

            • Ferk
              1•1 year ago

              Thank you! that was very informative.

      • @Toasteh@lemmy.world
        3•1 year ago

        Python syntax makes me really have no interest in gdscript. I don’t understand why people like python/similar languages. Its painful to use.

  • I Cast FistEnglish
    29•1 year ago

    TLDR - Godot’s raycasting is considerably more memory intensive than Unity’s. Using the Godot API to call its raycast in any language is much slower than simply using the builtin Node. Most of the performance woes are due to how GDScript is implemented: a slow, interpreted language (Python)

    It’s a fair complaint, Godot is far from perfect in many areas and may not be ideal for certain projects. This is fine, really. If it’s possible to make the engine better, I hope the pull requests that do so get accepted

    He did a small complaint that GDScript should be ditched. If you care entirely about performance, that is true. The problem, obviously, is that a lot of people, me included, rely on it instead of C#. For all intents and purposes, this is something that could be done, but it’d end up as a wholly separate branch of Godot that would end up with several incompatibilities, eventually becoming a different engine. In that case, it might be better to just check an alternative like Stride3D or Torque3D

    • @CaptDust@sh.itjust.works
      23•1 year ago

      I understand where the C# devs are coming from, but many of these unity devs experimenting need to understand C# was hardly a consideration before microsoft earmarked funds to push and develop support for the language in the engine.

      I’d be heartbroken if gdscript was ever dropped for improved C# support, games are much more fun to write in gdscript. I hope both languages can become more integrated and performent without the sacrificing of the other.

      • @anlumo@feddit.de
        1•1 year ago

        Unity also started out that way, but they dropped their Python-like and JavaScript-like languages after they realized that nobody used them. There wasn’t so much as a blip after that announcement, indicating that they were totally right on that.

      • @captain_oni@lemmy.worldEnglish
        1•1 year ago

        Yeah, I don’t want GDscript to end up like Unityscript or boo-lang on unity.

        After programming in gdscript for a couple of years I don’t want to have to go back to C# ever again.

  • circuitfarmer
    21•1 year ago

    Necessity is the mother of invention. My hope is that Godot sees more devs wanting to contribute to the project since we’ve now seen firsthand what being under a corporate umbrella can do to your product when it’s not your own umbrella.

  • @abbotsbury@lemmy.world
    12•1 year ago

    UPDATE: This article has started an ongoing conversation with the Godot devs. They care about the issues raised, and would like to improve things. Significant improvements will almost certainly be made, although it’s still early days and it’s unclear what will change and by how much. I am encouraged by the response. I believe Godot’s future could be very bright indeed.

    Well that’s nice to see so quick