The anatomy of a Godot API call • Hacker News Board

Re: The anatomy of a Godot API call

#181

Post by Fraterkes » Tue, Sep 19, 2023, 4:06 PM UTC

fidotron wrote: post #113

Fraterkes wrote: post #106

Earlier quoted context omitted.

What advantage do you think defold has over godot for 2d (apart from currently seemingly being more polished)? Theres lots of people complaining in this thread that GDscript is not serious enough as an engine language, but Godot at least has a decent c++ api. Defold only seems to support Lua (although you can extend the engine with other languages afaik).

Bluntly, getting too hung up on languages is procrastination. Lua is more than fine. (GDScript isn't actually that bad, just completely esoteric). Similarly I wouldn't get hung up on Blueprints or C++ when worrying about Unreal, partly because their C++ is so particular it's extreme. Defold is basically a pile of interesting simple subsystems, especially around game logic, that in combination become surprisingly powe…

I actually agree with you about the language-stuff. I thought your parent-command was essentially making some kind of performance-based comparison between defold and godot, which is why I mentioned Lua. Defold seems interesting, but unlike Heaps and Godot it hasn't yet been used for any game I've heard of. (additionaly I don't really agree that Gdscript is particullary esoteric. It's basically python, with a bunch of very obvious engine-api stuff added on top. Language-wise theres very little to learn there, which is great)

Re: The anatomy of a Godot API call

#182

Post by tacotacotaco » Tue, Sep 19, 2023, 5:29 PM UTC

johnnyanmac wrote: post #167

tacotacotaco wrote: post #142

I am so glad that Juan et al are leading Godot and not me because frankly I would be offended by all of this. It hasn’t been a week since the Unity fiasco and all I see is post after post from people complaining that Godot isn’t c# enough. This is like showing up for dinner and insulting cooking before you’ve even tasted the meal. There are definitely opportunities to improve Godot but there are more constructive way…

>Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#. This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum , simply due to how t…

> This dismissal of honest performance benchmarks…

No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting.

If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Better memory utilization, better processor performance[1], and no more garbage collection stutters. Oh right, it’s not your preferred language.

I’d rather we all just make games instead of fighting language wars, but seeing so many of these posts in the last week makes the community feel hostile.

[1] https://programming-language-benchmarks.vercel.app/rust-vs-c...

Re: The anatomy of a Godot API call

#183

Post by Rapzid » Tue, Sep 19, 2023, 6:25 PM UTC

tacotacotaco wrote: post #182

johnnyanmac wrote: post #167

Earlier quoted context omitted.

>Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#. This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum , simply due to how t…

> This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why n…

> I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’

Is this in response to the article in question? Because they are spot on with their assessments and those API issues need to get sorted. They impact bindings and all extensions including C++. The core devs seem to concur on this, it's just a matter of how it happens.

Re: The anatomy of a Godot API call

#184

Post by johnnyanmac » Tue, Sep 19, 2023, 7:45 PM UTC

tacotacotaco wrote: post #182

johnnyanmac wrote: post #167

Earlier quoted context omitted.

>Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#. This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum , simply due to how t…

> This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why n…

>I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting.

The author has already crossed the part out suggesting to remove GDScript. Which was overblown as it was one of 3 different suggestions.

Either way, even for the rude provocateurs, two wrongs don't make a right. I've follow Godot with a loose ear and it's not a surprise that there are significant performance issues in the engine. I'm glad someone is digging deeper rather than just saying "Godot isn't ready for 3D" and dismissing opportunites to grow.

>If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively?

Because you didn't get to the part of the article where it is mentioned that GDExensions uses the same api bindings as GDScript. So they are all affected by this, no matter what binding you make. Your only recourse is diving into the guts of Godot and rearranging how it works. Which is first of all, already in flight by the core team (redundancy) and secondly, not a kind of change you can easily PR in if you want to contribute (which is more hostile to the engine than any random post on social media).

And yes, this is the dismissal I'm talking about. "well just use another engine" is a pretty bad approach for a growing community when receiving honest feedback with benchmarks to back it up. The author makes a long post detailing the inner guts of the engine and people cherry pick one conclusion they don't like and want to push the author out of the community.

Re: The anatomy of a Godot API call

#185

Post by tacotacotaco » Tue, Sep 19, 2023, 10:03 PM UTC

johnnyanmac wrote: post #184

tacotacotaco wrote: post #182

Earlier quoted context omitted.

> This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why n…

>I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. The author has already crossed the part out suggesting to remove GDScript. Which was overblown as it was one of 3 different suggestions. Either way, even for the rude provocateurs, two wrongs don't make a right. I've follo…

I appreciate that the author crossed out his suggestion to remove gdscript vs removing it. I will give him credit for transparency. That doesn’t negate the original intent.

I am aware of the part about how this affects bindings for all languages. My point still stands that this is premature optimization. The author even admits, “In some projects 95% of the CPU load is in an algorithm which never touches the engine APIs. In that case, none of this matters.”

So again, if this is about performance then why not remove c# as well? If we’re to “tear it all down and start again” we might as well do it in rust. Oh? If I want a rust game engine I should look at Bevy. Is saying that really a second “wrong”?

I don’t have anything against this author specifically. I respect that they did more than simply look at the showcase screenshots to make their assessment. My initial comment was more a general expression of frustration with the prevailing attitude on various forums. I like reading r/godot to see individuals creating games, not creating grief. (Frankly, I found the Unity memes to be a bit mean spirited as well.) I acknowledge my initial comment did nothing to remedy the situation but I was tired of hearing it. I have since stopped reading that subreddit. Enjoy your c# crusade.

Re: The anatomy of a Godot API call

#186

Post by spookie » Tue, Sep 19, 2023, 10:31 PM UTC

johnnyanmac wrote: post #173

spookie wrote: post #71

Earlier quoted context omitted.

I'm also concerned with the approach the dev is taking on their game. That's a lot of raycasts.

They described it as so: >I'm making a top down 2D game and Godot's too slow to handle my character controllers at 120fps without a lot of hacks. In Unity they run in 2ms. It's not just The Last of Us that this matters to. >The controller gets used for NPCs too, so I can have quite a few of them on screen at once. It's got quite a complicated substepped movement and collision response system which does lots of ray an…

Oh yeah, for sure. I've developed some VR demos in Godot and it seemed quite capable. But, I was never calling this many raycasts from the CPU side of things. Never had an excuse to do so. I'm just saying this because I really think Godot is able to produce good 3D experiences as of now. I appreciate the criticism, and of course would like it to get better. But, I don't know, something tells me the dev could take another approach in the meantime. It seems the post started some ongoing conversations with the devs to solve this issue, so that's nice.

Re: The anatomy of a Godot API call

#187

Post by dandellion » Tue, Sep 19, 2023, 10:34 PM UTC

mardifoufs wrote: post #104

dandellion wrote: post #78

Earlier quoted context omitted.

They're commited to GDScript because it's a great scripting language. I started with Godot expecting to switch to C# pretty fast because I'm already familiar with C#, but I was pleasantly surprised with GDSCript. And I'm a programmer with more than 10 years of experience. For people who are still learning it must feel like the difference between trying to learn to ride a bycicle vs learning to fly a boeing 777.

Not being rhetorical or snarky, but what do you like about gdscript?

If you know how to code it's very easy to learn, it doesn't matter if you come from C#, C++, JavaScript, Python or something else.

There's almost no nasty surprises. Nothing like learning JavaScript and then discovering the weird behaviour of this, or using Python and discovering for the first time that the weird bug you had was because you set a dictionary as a default value for an argument.

It's got some of the syntax sugar you might expect from modern languages. Not as much as Python, but that might be for the best if they're trying to keep things simple.

Some of the syntax sugar (@onready, $, %) is specifically there to integrate with the engine and it is very very nice.

Documentation is good, integrated with the editor and the inspector.

The debugger works well (98% of the time, hopefully it'll keep improving).

It's one of the nicest languages I've learned in a long while. I think it's because it's only trying to do one job and it does it fairly well.

When I started learning it I noticed many things that were done better in other languages I've used (it's specially tempting to make comparisons with Python since it looks similar). After a few months using it almost daily to make a somewhat simple game I realised most of those things don't matter and for the purpose of making games in the engine it's pretty solid.

Re: The anatomy of a Godot API call

#188

Post by tacotacotaco » Tue, Sep 19, 2023, 10:41 PM UTC

Rapzid wrote: post #183

tacotacotaco wrote: post #182

Earlier quoted context omitted.

> This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why n…

> I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Is this in response to the article in question? Because they are spot on with their assessments and those API issues need to get sorted. They impact bindings and all extensions including C++. The core devs seem to concur on this, it's just a matter of how it happens.

I was generally frustrated with the parade of posts about how bad Godot is from former Unity devs. This happened to be the article that I commented on.

Re: The anatomy of a Godot API call

#189

Post by johnnyanmac » Wed, Sep 20, 2023, 12:32 AM UTC

tacotacotaco wrote: post #185

johnnyanmac wrote: post #184

Earlier quoted context omitted.

>I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. The author has already crossed the part out suggesting to remove GDScript. Which was overblown as it was one of 3 different suggestions. Either way, even for the rude provocateurs, two wrongs don't make a right. I've follo…

I appreciate that the author crossed out his suggestion to remove gdscript vs removing it. I will give him credit for transparency. That doesn’t negate the original intent. I am aware of the part about how this affects bindings for all languages. My point still stands that this is premature optimization. The author even admits, “In some projects 95% of the CPU load is in an algorithm which never touches the engine AP…

>My point still stands that this is premature optimization.

Given that the author knows they will make hundreds of raycasts a second, and that the perf suggested that they can at most make 700 for an entire 16hz frame, I can't agree in this case. This is the exact kind of "we'll fix it later" kind of unoptimization that makes gamers wonder why games still hit 30fps on modern hardware (I've worked on such a tile, in UE4. the engine doesn't save bad practices and useage).

>My initial comment was more a general expression of frustration with the prevailing attitude on various forums.

don't generalize your rants when you see a good example of criticism. That just lumps in the good with the bad and makes you look like you're lashing out at any criticism.

>Enjoy your c# crusade.

Enjoy prowling r/godot, I suppose. If that's the conclusion you gleam out of my comments, you fit right into Reddit. Making unrelated rants and being confused on the disagreement and seeing everyone as out to make your life specifically, miserable. Glad I left that behind months before it became fashionable to leave.

Re: The anatomy of a Godot API call

#190

Post by johnnyanmac » Wed, Sep 20, 2023, 12:35 AM UTC

spookie wrote: post #186

johnnyanmac wrote: post #173

Earlier quoted context omitted.

They described it as so: >I'm making a top down 2D game and Godot's too slow to handle my character controllers at 120fps without a lot of hacks. In Unity they run in 2ms. It's not just The Last of Us that this matters to. >The controller gets used for NPCs too, so I can have quite a few of them on screen at once. It's got quite a complicated substepped movement and collision response system which does lots of ray an…

Oh yeah, for sure. I've developed some VR demos in Godot and it seemed quite capable. But, I was never calling this many raycasts from the CPU side of things. Never had an excuse to do so. I'm just saying this because I really think Godot is able to produce good 3D experiences as of now. I appreciate the criticism, and of course would like it to get better. But, I don't know, something tells me the dev could take ano…

> I'm just saying this because I really think Godot is able to produce good 3D experiences as of now

I guess I'll see for myself next year as I work on a 3D title. But my current research doesn't make me optimistic. I am very much ready to help contribute to address these sorts of issues if/when I run into them. But I want to actually contribute, not just take my ball, fork, and redesign the engine. If I get this much friction introducing optimizations, and/or am unable to find out who/where is working on such things, I don't know what to say.