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

101–110 of 195 posts

Re: The anatomy of a Godot API call

#101

Post by Rapzid »

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 enthusiasm ).

It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then.

Further down though somebody points out:

> Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects.

This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places:

> C# is faster, but requires some expensive marshalling when talking to Godot.

I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..".

EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.

Re: The anatomy of a Godot API call

#102

Post by dandellion »

krapp wrote: post #91
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.

GDScript not a great scripting language. It's an adequate scripting language whose only benefit is native integration with the client, and guaranteed support in perpetuity. But there is nothing about it that's better than any other scripting language. No one would choose to use GDScript as a general purpose programming language. Other scripting languages are also easy to learn. Vanilla Javascript is much easier than…

I'd argue it's better than Boo and better than Blueprints. Maybe even JavaScript, because JS has made itself very useful as time has passed but as a small scripting language embedded in browsers it sucked.

It's only benefits are native integration with the client, and guaranteed support in perpetuity, and it's easy to write, and easy to learn, and teach, it almost never surprises you in ugly ways (which is awesome), it comes with a good enough debugger, its library pretty much covers what you need to make your average indie game... But what did the romans... I mean, GDScript, ever do for us?

Re: The anatomy of a Godot API call

#103

Post by CobrastanJorji »

robertlagrant wrote: post #4

I'm not sure I understood everything here, but I think the tl;dr is that Godot has a powerful new rendering technique called "foreshadowing".

It's new in Godot 4.1.1. When enabled, if two opaque polygons are between the user and a light source, the shading can reflect their relationship.

Re: The anatomy of a Godot API call

#104

Post by mardifoufs »

dandellion wrote: post #78
droptablemain wrote: post #44

I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project. Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.

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?

Re: The anatomy of a Godot API call

#105

Post by Narishma »

TheMagicHorsey wrote: post #47

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

Bevy is even more immature than Godot. It doesn't even have an editor and its reliance on webGPU leaves a lot of platforms in the dust.

Re: The anatomy of a Godot API call

#106

Post by Fraterkes »

fidotron wrote: post #28

When I first encountered Unity it was because there were performance problems on a Japanese only version of Bejeweled built with it and they needed someone to fix it. It was a classic: creating huge numbers of new objects for particle effects hammering the gc, and the fill rate of the then cutting edge device GPUs not being a match for their screen resolutions. Unity took several years, and a huge amount of investmen…

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

Re: The anatomy of a Godot API call

#107

Post by syntheweave »

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

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 encountered in OP) to make the transition uneventful.

And while it's desirable to optimize the glue and make scripting fast, that's also a much larger engineering project; Unity did it by spending big.

Re: The anatomy of a Godot API call

#108

Post by krapp »

dandellion wrote: post #102
krapp wrote: post #91

Earlier quoted context omitted.

GDScript not a great scripting language. It's an adequate scripting language whose only benefit is native integration with the client, and guaranteed support in perpetuity. But there is nothing about it that's better than any other scripting language. No one would choose to use GDScript as a general purpose programming language. Other scripting languages are also easy to learn. Vanilla Javascript is much easier than…

I'd argue it's better than Boo and better than Blueprints. Maybe even JavaScript, because JS has made itself very useful as time has passed but as a small scripting language embedded in browsers it sucked. It's only benefits are native integration with the client, and guaranteed support in perpetuity, and it's easy to write, and easy to learn, and teach, it almost never surprises you in ugly ways (which is awesome),…

It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)

Re: The anatomy of a Godot API call

#109

Post by krapp »

Narishma wrote: post #34
bakugo wrote: post #24

> That’s right, our raycast is returning an untyped dictionary. This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?

Presumably because GDScript doesn't support structs.

If you want "structs" in GDScript, use Resources.

I know it's not the same thing at all but it's as close as you're going to get.

Post reply on HN