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

31–40 of 195 posts

Re: The anatomy of a Godot API call

#31

Post by Hamcha »

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?

Dunno if it was your case but yes, Unity has had AOT compilation since forever with both ILCPP and (more recently) Burst.

Re: The anatomy of a Godot API call

#32

Post by fluxem »

CodeCompost wrote: post #16
karaterobot wrote: post #6

This matches up with what I've heard from people with experience in both Unity and Godot. As convenient as it would be if Godot was ready to swap in for Unity, it's got some significant issues that would make that difficult to unfeasible for many people.

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

I use linux and love it, but there are users who need Windows or Unity.

Re: The anatomy of a Godot API call

#33

Post by rhtgrg »

karaterobot wrote: post #26
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.

I've seen comments here on HN that make me believe some people think Godot is on par with Unity, or that it will be soon. The title of the linked article also acknowledges that some people in the world at least have a misapprehension to that effect.

All you have to do is look at games made with Unity and compare with games made with Godot.

The proof, as they say, is in the pudding.

Re: The anatomy of a Godot API call

#34

Post by Narishma »

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.

Re: The anatomy of a Godot API call

#35

Post by rsstack »

xmonkee wrote: post #22
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'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#.

You have to make sure you opt into the type-safe GDScript. It's not easy. There's an IDE feature that highlights lines that are not type-safe but the default color is a hard-to-see grey. I changed it to be red ("Line Number Color" is the one for untyped lines), and then fixed all typing issues. Then, autocomplete works as does cmd+click to go to definition.

Re: The anatomy of a Godot API call

#36

Post by MrLeap »

I didn't read anything that indicated a hard block to creating new methods that bypass the binding layer? All the layers are open source.

Unity has their fair share of bolted on methods with a "NonAlloc" suffix. Seems obvious to prioritize raycasts / intersection / collision code to receive this treatment.

I've noticed a few lower lift things I'd like to submit PR's for, just to see how/if I can help.

Re: The anatomy of a Godot API call

#37

Post by rsstack »

janosdebugs wrote: post #21
zerr wrote: post #2

How usable is Godot's native/C++ API for actual game programming, akin to Unreal? (never mind the hot reloading).

It's a lot clunkier than Unreal. You'll have to build a .so/.dll using scons or cmake (good luck finding a CMakeLists.txt that actually works) and you have to register all types manually. You will also not be able to work around the issues with the APIs mentioned in the article around dictionaries AFAIK. There is no header tool and no autogenerated code for your classes. Oh, and reloading the DLL on Windows requires…

Are you using call_deferred from your signal handlers?

Re: The anatomy of a Godot API call

#38

Post by amitmathew »

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

Re: The anatomy of a Godot API call

#39

Post by lainga »

janosdebugs wrote: post #21
zerr wrote: post #2

How usable is Godot's native/C++ API for actual game programming, akin to Unreal? (never mind the hot reloading).

It's a lot clunkier than Unreal. You'll have to build a .so/.dll using scons or cmake (good luck finding a CMakeLists.txt that actually works) and you have to register all types manually. You will also not be able to work around the issues with the APIs mentioned in the article around dictionaries AFAIK. There is no header tool and no autogenerated code for your classes. Oh, and reloading the DLL on Windows requires…

I used GDExtension extensively on a previous project, and I ended up just installing the .so, launching Godot headless, and immediately exiting, as part of my build script. To catch anything that might break extension loading.

Re: The anatomy of a Godot API call

#40

Post by shmerl »

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?
Post reply on HN