this post was submitted on 18 Sep 2023
83 points (97.7% liked)
Godot
5888 readers
52 users here now
Welcome to the programming.dev Godot community!
This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.
Make sure to follow the Godot CoC while chatting
We have a matrix room that can be used for chatting with other members of the community here
Links
Other Communities
- !inat@programming.dev
- !play_my_game@programming.dev
- !destroy_my_game@programming.dev
- !voxel_dev@programming.dev
- !roguelikedev@programming.dev
- !game_design@programming.dev
- !gamedev@programming.dev
Rules
- Posts need to be in english
- Posts with explicit content must be tagged with nsfw
- We do not condone harassment inside the community as well as trolling or equivalent behaviour
- Do not post illegal materials or post things encouraging actions such as pirating games
We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent
Wormhole
Credits
- The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
- The banner is from Godot Design
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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".....
@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 ✨
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.
@Octorine i dont think its a question that's relevant, pragmatically.
it doesn't fundamentally matter if there is selection bias, because its not relevant for the design problem that the language integration solves
Can you rephrase that? I don't follow.