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

171–180 of 195 posts

Re: The anatomy of a Godot API call

#171

Post by johnnyanmac »

Jensson wrote: post #98
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…

Python is still slow today. I've worked with performance sensitive python at Google, there is no way to make it fast no matter what tool you use except to rewrite it in a lower level language. Javascript is fast since it is such a simple language that is easy to optimize, more complex runtimes wont see nearly the same amount of gain from optimization efforts.

It's possible (Unity did it to C#, a magnitude more complex a language than Python), but at the same time we are not short on choices for other languages to extend upon. Google even made a few of those languages themselves.

There's just been no demand to make Python crazy fast, not to the scale where even Google will throw their engineers at it. Python's use cases aren't in real-time applications so that level of performance concern is simply not needed for many. And those that do will use anything else on the backend, from C to Go, maybe even Javascript.

Re: The anatomy of a Godot API call

#172

Post by johnnyanmac »

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…

Redditors couldn't even switch off Reddit during their own enshittification. I don't exactly trust their judgement in terms of knowing how to find alternatives. What is the term they use these days? Wolves eating my face?

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

Need is a strong word, but I will never judge someone on the tools they use (well, not on a personal level. I will judge you if you choose to make a game in Microsoft Powerpoint, you madman). But if you're going to complain about big business and then wonder why you can't find a good alternative when your complaints fall on deaf ears... well, you see why they are still in business.

I've simply shifted my mindset over the years from trying to tear down the evil, and instead build up the good. It's a much more productive way to live much of life in general.

Re: The anatomy of a Godot API call

#173

Post by johnnyanmac »

spookie wrote: post #71
anothernewdude wrote: post #3

Sounds a lot like Unity to me.

I'm also concerned with the approach the dev is taking on their game. That's a lot of raycasts.

They described it as so:

>I'm making a top down 2D game and Godot's too slow to handle my character controllers at 120fps without a lot of hacks. In Unity they run in 2ms. It's not just The Last of Us that this matters to.

>The controller gets used for NPCs too, so I can have quite a few of them on screen at once. It's got quite a complicated substepped movement and collision response system which does lots of ray and shape casts. A typical frame may end up around 500.

Even if its not efficient for their specific game, a few hundred raycasts should not be taking nearly a millisecond to perform. No wonder there's so much work to do to get Godot to be 3D ready.

Re: The anatomy of a Godot API call

#174

Post by johnnyanmac »

tacotacotaco wrote: post #141
trinovantes wrote: post #111

Earlier quoted context omitted.

That poll seems highly biased How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey

How many users that are happy with gdscript are taking time to read vote in a GitHub polling posted about c# issues?

Doomscrolling is a thing even in gamedev, I suppose.

Re: The anatomy of a Godot API call

#175

Post by johnnyanmac »

Kiuhrly1 wrote: post #152
sankhao wrote: post #121

Earlier quoted context omitted.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

I would bet that it doesn't matter for 99% of scripts. By the numbers, Godot's primary use case so far has effectively just been game jams.

So are we fine keeping it that way and not addressing core performance issues because it's convinent for making simple 2D games?

To be honest, I'm surprised how dismissive parts of the gamedev community can be about improving performance of their game engine. That was a huge complaint from Unity and you'd think people would be interested in not repeating those mistakes with Godot.

Re: The anatomy of a Godot API call

#176

Post by johnnyanmac »

tourmalinetaco wrote: post #127
sankhao wrote: post #121

Earlier quoted context omitted.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.

If C bindings were slow because the underlying code was made to bridge with Python bindings, I would complain too, to be fair. Doesn't mean removing Python support is the perfect solution, but at some point that performance hurts everyone.

(not that that should be an issue due to python being able to directly output C code, but you understand the point).

Re: The anatomy of a Godot API call

#177

Post by meepmorp »

panzagl wrote: post #18
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".

That why it seems slow- if you want the gun to fire in act 2, you have to show it in act 1.

Oh, now I get it - they named the engine after the play, "Waiting for Mr Chekhov."

Re: The anatomy of a Godot API call

#178

Post by Rapzid »

zamalek wrote: post #41

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

Yeah, my take is the API should be made clean of this stuff and a shim layer added on top for GDScript to consume.

Re: The anatomy of a Godot API call

#179

Post by pjmlp »

johnnyanmac wrote: post #169
pjmlp wrote: post #165

Earlier quoted context omitted.

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.

It is still GNM and GNMX, Playstation doesn't no Vulkan, and I am quite sure that just like with MoltenVK and DXVK, not everything can be mapped in a transparent way.

Re: The anatomy of a Godot API call

#180

Post by smoldesu »

pjmlp wrote: post #179
johnnyanmac wrote: post #169

Earlier quoted context omitted.

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.

It is still GNM and GNMX, Playstation doesn't no Vulkan, and I am quite sure that just like with MoltenVK and DXVK, not everything can be mapped in a transparent way.

That's kinda a Sony problem. The best an Open Source project can do is build HLSL/SPIR-V IR and let you do the rest yourself. I don't really know what you're asking for besides that, it's how things have been since the PS4 launched.
Post reply on HN