Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot) • Hacker News Board

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#81

Post by db48x » Fri, Sep 22, 2023, 8:28 PM UTC

Rapzid wrote: post #74

db48x wrote: post #72

Earlier quoted context omitted.

Raycasts are a very useful tool, and you shouldn’t avoid using them if they’re the only thing that will work. But a _fully general_ raycast is always the most expensive option. For example, an axis–aligned raycast will always be cheaper and might do the job just as well. The previously mentioned case of doing hundreds of raycasts all starting in the same location but each in a different direction could be done with r…

I mean it's game dev, there's always work arounds and efficiency hacks. But what does any of this has to do with improving the ABI?

The original complaint was that Godot’s C# bindings have a raycast method that returns a dictionary. The reply article point out that this is a legacy of an earlier, less performant, C# implementation and that the work to clean it up was already under way. My point is only that raycasts are already something that you want to avoid; the extra work of allocating a dictionary each time you call it is unfortunate but not fatal.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#82

Post by badsectoracula » Sat, Sep 30, 2023, 11:32 AM UTC

jayd16 wrote: post #43

badsectoracula wrote: post #28

Earlier quoted context omitted.

> The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me. As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive…

This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints. But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.

What i wrote isn't that you can't write C++ in Unity, what i wrote was that you do not have the C++ source for Unity that would help you address performance issues. Since you mentioned UE blueprints, i have worked with UE and faced the need for better performance: being able to have (and modify) the C++ source (including the blueprint VM and codegen) code was something that helped and at the same time being able to turn blueprints to C++ wasn't a panacea nor the performance was anything close to what you'd get with writing the code in proper C++ in the first place (which is what we ended up doing for some parts).

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#83

Post by badsectoracula » Sat, Sep 30, 2023, 11:44 AM UTC

johnnyanmac wrote: post #61

jayd16 wrote: post #43

Earlier quoted context omitted.

This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints. But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.

It's such a bizarro world after a bunch of UE discussions to suddenly see people dismiss scripting concerns with "well just write that code in C++. Blueprints is slow". I'm usually the one saying that, but that's as a professional developer who needs to optimize all that stuff (and TBH the blueprint code tends to have some bad performance choices even before discussing the BP perf loss). Hearing people dismiss the pe…

What i wrote wasn't making your whole game an engine module (i.e. writing everything in C++) but writing your intensive code in C++ and using scripting (be it blueprints, GDScript or whatever) to drive that intensive code.

There is nothing counterintutive in that, it is right in the name of scripting languages: they're meant to script behavior.

And the dismissal isn't about having a raycast being slow, but about using too many raycast queries in script to do something reusable that should be in native code in the first place. If your scripting language ends up in your performance profile chances are you are using it wrong.

The occasional raycast query in scripts to make a decision is fine, doing thousands of individual raycast queries from scripts is not - if nothing else, make an API that accepts multiple raycast queries at once, performs it in C++ in a single call (so you only get the scripting overhead for that single call) and gives the result back.

But IMO if, as mentioned in the article, you are going to make a controller that is to be used by multiple entities in the game, then you should make it in C++ - potentially with script hooks to customize the behavior, if needed.