Response to the article from godot dev: https://reddit.com/r/godot/comments/16lti15/godot_is_not_the...
TL;DR is that they know this & working on it
The anatomy of a Godot API call
61–70 of 195 posts
Re: The anatomy of a Godot API call
#62The thesis of the article appears to be > 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. If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly qu…
It's for this reason that I appreciate this article, even though it has a (playful, well-intentioned) negative tone toward Godot which is a project I donate to.
This is wonderful criticism! It's thoughtful and well-researched. Hell, even I'm inspired to finally dive into Godot's internals, which I've yet to do despite following the project for several years. I hope this inspires even more contribution and constructive criticism.
Re: The anatomy of a Godot API call
#63>Unity has spent the last five years working on speeding up their scripting with crazy projects such as building two custom compilers, SIMD maths libraries, custom collections and allocators, and of course the giant (and very much unfinished) ECS project. It’s been their CTO’s primary focus since 2018. That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forum…
> the entire leadership of the ECS/DOTS team has resigned
Recently because of the drama or unrelated? That’s sad to hear as I was very excited on that effort.
Re: The anatomy of a Godot API call
#64The thesis of the article appears to be > 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. If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly qu…
JavaScript is fast because it is used by every person every day, so lots of smart people from big companies put lots of thought how to make it fast, and I still get a feeling of overwhelming anger when browsing the new web Reddit on a 4-years old phone. Godot is a game engine supported by a community (not big companies). They are not really comparable. And sometimes, there are still performance ceilings imposed by a…
> JavaScript is fast because it is used by every person every day, so lots of smart people from big companies put lots of thought how to make it fast, and I still get a feeling of overwhelming anger when browsing the new web Reddit on a 4-years old phone. Godot is a game engine supported by a community (not big companies).
I'm glad to see that tools can exist in only one of 2 states, massive world wide adoption and support by big corporate, or a couple of devs screwing around. I wonder if it is possible for a tool to transcend this limitation?
If only there was a way for multiple people to use a tool, push for it, enhance it and for it's adoption to grow and spread to large pieces of the community eventually gaining corporate support. But nah, things like that don't happen. After all if there is one thing I've learned a scripting/game/animation engine that is easy enough to use and is flexible is something no one really needs anyone, a product like that would probably disappear in a FLASH, after all.
Re: The anatomy of a Godot API call
#65Never underestimate the power of open source game developers. If we could do it with XNA, we’ll do it with Unity. If we have to tear the place down and rebuild it on a rust il-compliant vm instead of mono, we damn sure will [0]
[0] https://crates.io/crates/netcorehost
*edit* everything in the article is on point. Function pointers as binding glue sucks. There’s tons of optimizations to be done in the engine for sure. However, having a robust C# api is on top of list since it was introduced. I do think Godot 5 should make a hard choice and just support C# instead of GDScript.
Re: The anatomy of a Godot API call
#66So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for G…
I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.
There is optional static typing. If you write type declarations, the editor will not only give better code completion, but it will use type inference to find errors statically where possible, and the runtime will check for the remaining type errors. In this way it's more sophisticated than almost all other dynamically typed languages!
Re: The anatomy of a Godot API call
#67If Godot has a first-class C# support then why `Godot.Collections.Dictionary` exists when there is already `System.Collections.Generic.Dictionary`? https://learn.unity.com/tutorial/lists-and-dictionaries
https://docs.godotengine.org/en/stable/tutorials/scripting/c...
> The main difference between the .NET collections and the Godot collections is that the .NET collections are implemented in C# while the Godot collections are implemented in C++ and the Godot C# API is a wrapper over it, this is an important distinction since it means every operation on a Godot collection requires marshaling which can be expensive especially inside a loop.
> Due to the performance implications, using Godot collections is only recommended when absolutely necessary (such as interacting with the Godot API). Godot only understands its own collection types, so it's required to use them when talking to the engine.
Re: The anatomy of a Godot API call
#68Curious if anyone here has tried Bevy (Rust game engine). Godot has a beautiful editor and great tooling for a free engine ... but I worry about the choice of C# and GDScript as the expected way for devs to interact with the project (what if performance is a concern or you need to develop some low-level features). Another post in this thread said the C++/native interface was not great and difficult to work with. And…
I looked into this, but it seems most gamedev communities I asked, say Bevy isnt great, and everyone seems to be recommending Fyrox instead. No clue if it actually is, just parroting what I have been told.
Either way, I don't think either is ready for prime time as its still early development.
Re: The anatomy of a Godot API call
#69So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for G…
I went into Godot thinking I'd hate GDScript and switch to C# pretty fast because I already knew it. Now I love GDScript, if I ever need performance I'll probably just go straight for C++.
Re: The anatomy of a Godot API call
#70So, what I'm gathering is if you're bothered by the Unity (either a developer, publisher, gamer) developments, and wish Godot was a better alternative than it is, contributing to the project (by donating either time or money) is probably necessary to get there.