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.
  • Ferk@kbin.social
    2·
    9 months 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:@gamedev.lgbt
      61·
      9 months 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·
        9 months 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@kbin.social
        1·
        9 months 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:@gamedev.lgbt
          2·
          9 months 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 ✨

    • Toasteh@lemmy.world
      3·
      9 months 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.