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

161–170 of 195 posts

Re: The anatomy of a Godot API call

#161

Post by johnnyanmac »

timmytokyo wrote: post #59

>Unity has spent the last five years working on speeding up their scripting with crazy projects such as building two custom compilers, SIMD maths libraries, custom collections and allocators, and of course the giant (and very much unfinished) ECS project. It’s been their CTO’s primary focus since 2018. That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forum…

He wasn't just active on forums, he was actively developing on Unity itself, in the weeds with all the other engineers. He arguably got a bit too involved at times, but it was very admirable for a "executive" who could retire on the interest of his shares in Unity to still take so much care in the product. I can't say that about many 10+ year old company founders, let alone ones that went public.

And of course the moment he silently stepped out, Unity rolls all this BS out in less than 6 months. Joe wasn't just champion of the tech, he was likely one of the last of the old guard up top keeping things focused on the actual product instead of how to extract infinite monies.

Re: The anatomy of a Godot API call

#162

Post by johnnyanmac »

pests wrote: post #63
timmytokyo wrote: post #59

>Unity has spent the last five years working on speeding up their scripting with crazy projects such as building two custom compilers, SIMD maths libraries, custom collections and allocators, and of course the giant (and very much unfinished) ECS project. It’s been their CTO’s primary focus since 2018. That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forum…

> the entire leadership of the ECS/DOTS team has resigned Recently because of the drama or unrelated? That’s sad to hear as I was very excited on that effort.

Not recently, but there was a steady drain of talent. The two heads of the DOTS initiative were gone by May of this year and the CTO, and the last original Founder of Unity, and arguably largest champion of DOTS, silently stepped down in April when introducing the new CTO. Johacim's official status is apparently "sabbatical" (I'm sure he owns way too much stock and other sway to be hoisted out the traditional way).

Re: The anatomy of a Godot API call

#163

Post by pjmlp »

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

Except that is the whole point of languages like C#, being able to be productive in high level code, and not needing to write C++ when performance is called for by providing all the features for low level code, unless in very niche caches where those features still aren't enough.

Re: The anatomy of a Godot API call

#164

Post by johnnyanmac »

MrLeap wrote: post #36

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.

I hear the recommended approach is to write your own module in the engine level code. But that means you need to compile the engine everytime you change your module. Possible, but you are losing a lot of iteration unless you are experienced in rolling in your own physics.

Nothing stop you from modifying the engine code, but the problem lies in the binding layer, not the engine perormance (as you see in the blog, the raw engine performance for a raycast is about the same as Unity). That's a bit trickier to fix without intimate knowledge of such bindings, and you'll likely break a lot of GDScripting support (so by extension, c# scripting) in the process.

Re: The anatomy of a Godot API call

#165

Post by pjmlp »

jms55 wrote: post #119
Narishma wrote: post #105

Earlier quoted context omitted.

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.

As a Bevy dev - what platforms? We support Vulkan, DirectX12, Metal, WebGPU (with a bit more limited features), and WebGL2 and GLES 3 (with a decent amount more limited features and performance).

Playstation for example.

Re: The anatomy of a Godot API call

#166

Post by pjmlp »

guideamigo_com wrote: post #7
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 still remains slow. Java is fast enough that it doesn't matter. However, no one will use Java to build Linux kernel.

Mostly because Linus won't accept anything other than C on his beloved kernel.

Sun had experimental support for Java drivers on Solaris, Android has support for writing drivers in Java, Android Things only allowed for Java written drivers.

Re: The anatomy of a Godot API call

#167

Post by johnnyanmac »

tacotacotaco wrote: post #142

I am so glad that Juan et al are leading Godot and not me because frankly I would be offended by all of this. It hasn’t been a week since the Unity fiasco and all I see is post after post from people complaining that Godot isn’t c# enough. This is like showing up for dinner and insulting cooking before you’ve even tasted the meal. There are definitely opportunities to improve Godot but there are more constructive way…

>Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.

This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum, simply due to how the c++ and C#/GDSctipt/GDExtension layers talk.

Take this as a warning, not a dismissal. Unity went down this exact path and we see how viable it became for large scale game development. I sympathize with you for those who are outright trashing the GDScript for being a scipting language, and I do wish those arguments would die down (it's simply language wars). But there are definitely fixes here that would improve all diferent bindings, even if they never diverged (which IMO, they should).

>This is like showing up for dinner and insulting cooking before you’ve even tasted the meal

cooking is subjective (mostly), performance is not. This is more like asking why the cook is trying to carefully drain out the water with a loose lid instead of using a strainer. Sure, it may work for the cook and they've done it all this time, but I'd rather give a safer solution that won't burn them long term, or spill out excess food.

Re: The anatomy of a Godot API call

#168

Post by johnnyanmac »

MegaDeKay wrote: post #75
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 came up on /r/rust_gamedev a little while back. The general sentiment seemed fairly negative, with comments that you either do things Bevy's way or the highway. https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...

A lot of the consensus there seems to come down to

1. the engine isn't stable and has breaking updates (why does that sound familiar...)

2. ECS is hard to learn and Bevy is too strict with ECS.

It's hard in the same way OOP is hard, I guess. But it's just that: a paradigm. It's harder to google because ECS is a specific paradigm for applications that want to follow data oriented design. If you don't care about that, then you lose all that benefit and google-ability for not much gain.

I guess that's just the state of FOSS game engines right now. People basically just want Unity/Unreal without the copporate overlords. But while oppressive, they also did fund the engineers to make those solutions so attractive to begin with. You'll inevitably get your hands dirty if you go of those smooth UE/Unity roads. Especially if you're choosing an up and coming language like Rust on top of all things.

Re: The anatomy of a Godot API call

#169

Post by johnnyanmac »

pjmlp wrote: post #165
jms55 wrote: post #119

Earlier quoted context omitted.

As a Bevy dev - what platforms? We support Vulkan, DirectX12, Metal, WebGPU (with a bit more limited features), and WebGL2 and GLES 3 (with a decent amount more limited features and performance).

Playstation for example.

Bevy is open-source, so there will not be any public GNM (or whatever they call the PS5 graphics API) bindings for playstation support.

Besides, for the scale of games currently coming out of Bevy, you should be able to use Vulkan to pipe your game into a PS port.

Re: The anatomy of a Godot API call

#170

Post by johnnyanmac »

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…

Javascript was also once upon a time just some randomly strung together mess of code (with urban legends saying it was made in 10 days) by a not-big company. Gotta start somewhere.

There's no point comparing year 30+ of Javascript to year ~10 of Godot. Remember that year 10 of JS was the time when Flash reigned supreme.

>They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.

I agree and am glad that we're finally putting a halt to bandaging up the leaky pipes known as JS and releasing stuff like WebASM. Fortuantely, Godot is nowhere near as heavily bandaged and has easier access to change.

Post reply on HN