Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The anatomy of a Godot API call

sampruden.github.io

Post reply on HN
Print view View original

121–130 of 195 posts

Re: The anatomy of a Godot API call

#121

Post by sankhao »

__loam wrote: post #97
badsectoracula wrote: post #81

Earlier quoted context omitted.

> community might dislike a performance-friendly change which will break the parity in favour of C#. The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use. If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. The…

It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

Re: The anatomy of a Godot API call

#122

Post by Rapzid »

trinovantes wrote: post #111
Rapzid wrote: post #101

Earlier quoted context omitted.

Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... . One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying: > As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq…

That poll seems highly biased How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey

Yeah it's def biased towards existing users in many ways.

Not a terrible thing if you want to concentrate on their needs, but not the best questions for filtering ideas for expanding adoption (perhaps).

Re: The anatomy of a Godot API call

#123

Post by Nition »

Rapzid wrote: post #101
neonsunset wrote: post #14

So 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…

Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... . One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying: > As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq…

There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store.

As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.

Re: The anatomy of a Godot API call

#124

Post by plopz »

dandellion wrote: post #69
neonsunset wrote: post #14

So 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++.

The author of the article seems to say that even the c++ api version is a heap allocated dictionary, so you would still take the perf hit

Re: The anatomy of a Godot API call

#125

Post by Rapzid »

syntheweave wrote: post #107
dandellion wrote: post #69

Earlier quoted context omitted.

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++.

This is the Godot way of doing it. It encourages just getting your hands dirty if you need the engine to do something very specific. The architecture is made with the understanding that you eventually want to transition from script implementations to native ones, but that you'll ship with the game being somewhere in between. And the architecture has been set up with generous amounts of glue(which is the overhead enco…

You don't need to spend big though to address the issues author highlighted.

Pretty straightforward API changes. After a design is decided on just some tedious typing work. Heck, it could be dog piled easy enough.

Re: The anatomy of a Godot API call

#126

Post by Rapzid »

Nition wrote: post #123
Rapzid wrote: post #101

Earlier quoted context omitted.

Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... . One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying: > As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq…

There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store. As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.

Easily room for both though.

Maintaining two API binding layers is perfectly feasible with the attention and resources Godot is attracting.

Unlike with Unity interested parties can jump in and lend a hand. You'll have two groups(perhaps overlapping) maintaining the compiled and script bindings.

Maybe GDScript could just get the concept of a struct and the differences minimized over time too.

Re: The anatomy of a Godot API call

#127

Post by tourmalinetaco »

sankhao wrote: post #121
__loam wrote: post #97

Earlier quoted context omitted.

It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.

Re: The anatomy of a Godot API call

#128

Post by cfgyuiikhg »

sankhao wrote: post #121
__loam wrote: post #97

Earlier quoted context omitted.

It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

C++ > C#

Re: The anatomy of a Godot API call

#129

Post by Rapzid »

__loam wrote: post #97
badsectoracula wrote: post #81

Earlier quoted context omitted.

> community might dislike a performance-friendly change which will break the parity in favour of C#. The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use. If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. The…

It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.

"People" will always do shitty stuff. Also, "people" will get overly defensive about challenges to their status quo and world view..

That said, how prevalent is the former vs the later really?

Re: The anatomy of a Godot API call

#130

Post by cfgyuiikhg »

eddythompson80 wrote: post #92
dandellion wrote: post #88

Earlier quoted context omitted.

Not sure Unity is a good role model... Also, having used both Boo back in the day and GDScript in Godot more recently, I'd say that one big difference between the two is that Boo was really bad, and GDScript is actually pretty good.

What's wrong with Unity from a technical prospective not marketing/business prospective?

It was fat and glitchy from the get go.
Post reply on HN