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

21–30 of 195 posts

Re: The anatomy of a Godot API call

#21

Post by janosdebugs »

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 an editor restart. Plus I haven't found a good way to debug load failures either apart from starting the editor from a console window.

I ended up sticking to GDScript in the end, but the typing system is very basic and the code can get very messy quickly. Plus, as far as I could tell, there is a race condition between signals and the process function, but I need to debug that more thoroughly to be sure.

Re: The anatomy of a Godot API call

#22

Post by xmonkee »

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

Re: The anatomy of a Godot API call

#23

Post by janosdebugs »

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

In GDScript you kind of get code completion. Kind of. 50% of the time it doesn't give anything useful.

Re: The anatomy of a Godot API call

#24

Post by bakugo »

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

Re: The anatomy of a Godot API call

#25

Post by jackmott42 »

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

If you use C# then you can use Visual Studio or Rider or VSCode and get that

Re: The anatomy of a Godot API call

#26

Post by karaterobot »

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.

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.

Re: The anatomy of a Godot API call

#27

Post by Waterluvian »

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?

Re: The anatomy of a Godot API call

#28

Post by fidotron »

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 investment, along with improvements in the wider ecosystem, before performance became much less of a concern for normal developers. A lot of the work they did around C# usage to achieve this is really surprisingly intense.

In the near future I seriously think 2D (and some subset of simple 3D) game devs would be better off looking at Defold, and if you want to make immersive 3D just bite the bullet and move to Unreal. These days cost of preparing assets drastically exceeds coding time anyway.

Re: The anatomy of a Godot API call

#29

Post by kevingadd »

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…

Solving some of those performance problems can also require a massive amount of engineering resources and investment, though. For example the way browsers (generally) overcame interop overhead was by self-hosting almost everything in JavaScript or making things into JIT intrinsics. That's a tall order for something like Godot with two languages.

Re: The anatomy of a Godot API call

#30

Post by jay_kyburz »

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?

There are red flags everywhere.

I think Godot has this really nice looking editor, and the nodes look nice, but the engineering foundations are just not there.

I think a lot of people start Godot projects but not many finish them because they run into these WTF issues.

Post reply on HN