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

41–50 of 195 posts

Re: The anatomy of a Godot API call

#41

Post by zamalek »

This dictionary stuff is truly bizarre. I have been playing around with GDExtension and Rust - specifically the meshing interface. This dictionary stuff shows up there. Not only couldn't I figure out why (the GDScript angle makes sense in hindsight), but it also makes the API virtually impossible to discover: you have to resort to reading things up in the documentation.

As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.

Re: The anatomy of a Godot API call

#42

Post by sockaddr »

fluxem wrote: post #32
CodeCompost wrote: post #16

Earlier quoted context omitted.

Nobody suggested that Godot was on par with Unity. The hope is that resources get diverted away from Unity towards Godot so that it can develop into a top-notch game engine. It's time to stop waiting and start working on Godot.

You clearly weren't on reddit. Everyone there will urge you to switch to Godot even though your game is almost finished and Godot doesn't have feature parity. It reminds me of the linux debate: - A: I hate Windows telemetry - B: Then switch to linux. It's as good - A: But it doesn't have a good video editor. - B: You should develop your own video editor and share it with the community - A: Ughh... I just want to edit…

> You should develop your own video editor and share it with the community

Seems like a fun weekend project

Re: The anatomy of a Godot API call

#43

Post by [deleted] »

amitmathew wrote: post #38
Waterluvian wrote: post #27

I tried using Godot for Web game toy projects and unfortunately the base file size is like 12MB and closer to 40MB if you use C#. I think Unity was like 3MB with C# Not a big deal for a lot of cases. Don’t let it deter you. But for my specific target it was a problem. To be honest I’m not sure how Unity can be so small. Does it compile the C# or something avoiding the need for a beefy runtime?

There's a good post on Reddit of a dev creating small web exports using custom builds: https://old.reddit.com/r/godot/comments/16lti15/godot_is_not... .

[deleted]

Re: The anatomy of a Godot API call

#44

Post by droptablemain »

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.

Re: The anatomy of a Godot API call

#45

Post by Waterluvian »

amitmathew wrote: post #38
Waterluvian wrote: post #27

I tried using Godot for Web game toy projects and unfortunately the base file size is like 12MB and closer to 40MB if you use C#. I think Unity was like 3MB with C# Not a big deal for a lot of cases. Don’t let it deter you. But for my specific target it was a problem. To be honest I’m not sure how Unity can be so small. Does it compile the C# or something avoiding the need for a beefy runtime?

There's a good post on Reddit of a dev creating small web exports using custom builds: https://old.reddit.com/r/godot/comments/16lti15/godot_is_not... .

Thanks. I first misread the C++ part but it sounds like they have some way of paring down the runtime when using GDScript. I’ll have to seek that out.

Re: The anatomy of a Godot API call

#47

Post by TheMagicHorsey »

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 C++ even in the best of times is not my favorite thing to work in.

Re: The anatomy of a Godot API call

#48

Post by mschuster91 »

AndriyKunitsyn wrote: post #17
gustavus wrote: post #5

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

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

That's more the problem of Reddit's code being a pile of bull dung. Someone high-level in there decided to ditch the "old" API for the "redesign" in favor of GraphQL and as everyone who has ever worked with GraphQL is likely to have discovered, GraphQL is a hell in itself.

And because whoever was moronic enough to call that decision doesn't want to admit they have fucked up and Reddit can't/doesn't want to afford maintaining two distinct APIs, they decided to rather shut down the old, working and performant API.

Reddit is being killed by corporate bullshit.

Re: The anatomy of a Godot API call

#49

Post by meepmorp »

shmerl wrote: post #40
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…

What about other bindings, like with Rust?

Apparently (per the article) the C++ bindings use the same API as c# and GDScript. Presumably rust would have the same limitations, unless you wrote a whole new API just for it.

Re: The anatomy of a Godot API call

#50

Post by hutzlibu »

fluxem wrote: post #32
CodeCompost wrote: post #16

Earlier quoted context omitted.

Nobody suggested that Godot was on par with Unity. The hope is that resources get diverted away from Unity towards Godot so that it can develop into a top-notch game engine. It's time to stop waiting and start working on Godot.

You clearly weren't on reddit. Everyone there will urge you to switch to Godot even though your game is almost finished and Godot doesn't have feature parity. It reminds me of the linux debate: - A: I hate Windows telemetry - B: Then switch to linux. It's as good - A: But it doesn't have a good video editor. - B: You should develop your own video editor and share it with the community - A: Ughh... I just want to edit…

It is probably not on par with the professional video editors and it is not very intuitive to get started, but blender has a build in video editor, that should cover most basic needs.

Otherwise sure, that misguided evangelicalism is hurting trust in open source software, when people claim it is ready, where it isn't.

Post reply on HN