>Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense.
I believe the issue was less with the sizes of items being passed in and more with the API conforming to work with GDScript first and formost. Returning a dictionary for an operation that has a few float64's feels overkill and doesn't make sense even with an explanation of the available datatypes.
>Only a pathological use case is shown, the rest of the API is fine.
I wouldn't call raycasting in a full blown engine "pathological". Especially one that touts 3D
Secondly, that doesn't inspire confidence. "Don't mind the room on fire, the rest of the house is fine!". The onus is on the engine to prove that, and numbers prevail over words. So far only one part of the conversation has shown that.
Even in the next sentence it sounds like they focus on a simple API over performance, and that doesn't fill me with confidence. If Godot isn't focusing on 3D, that is fine but there's so much noise trying to to say otherwise
> Eventually, C# will be moved to the universal extension system and this will allow the unifying of the default and .net editors, it is just not the case yet, but its top in the list of priorities
I hope so, but there seems to be a trend of various "top priorities" from Godot that have trouble crossing the finish line. That's a reocurring issue even in this response alone: I'm not convinced that performance is a top priority for Godot. And that confidence means everything if the "BDFL" controls what gets into the project proper.
>The problem is that, at the C++ level, this function takes a struct pointer for performance. But at the language binding API this is difficult to expose properly. This is very old code (dating to the opensourcing of Godot) and a Dictionary was hacked-in to use temporarily until something better is found
Yup... so 10 years later that hack stays in and modern programmers come cross it.
This isn't even a critique, that's simply the nature of legacy code. Unreal has an entire part of a forced namimg scheme (the compiler won't let you run the game without conforming) that can only be explained as "well we wanted to do this in the 90's but we slowly took it out sp it's not relevant today". But if it took 10 years for someone to do more than a few dozen raycasts a frame, it says more about the battletesting than any deep dive. It goes back to my confidence above.
>, you need to create a C# version of a C++ instance as an adapter... Why is it troublesome? because C# has a garbage collector and C++ does not.
slight nitpick: while garbage collection is annoying, you technically do have a built in way to disable it in certain regions, as well as the option in later versions to have unmanaged blocks of code. I'm not saying this is easy to do, but it is something that developers much smarter than me in c# have gotten around. I know c# bindings was a relatively recent endeavor so I'm not going to give it too much flak
> Godot containers don't work like STL containers. Because they are used mainly to pass data around, they are allocated once and then kept via reference counting.
1) reference counting implies some sort of automated memory free-ing scheme. 2) That doesn't necessarily address potential issues of inefficiently allocating memory and keeping it contiguous. But I won't talk much on that because I'd need to first read more on the engine's memory allocating schemes first.
> Godot uses far more optimized containers that are not directly exposed to the binder API.
Okay, but why? Someone wanting to use C# or c++ or whatever script extension that isn't GDScript wants those optimized containers. Does it go back to the earlier quote of "it's difficult to get right and no one wanted it"?
>As a result, we created a special path for GDScript to call more efficiently.
okay, and the link is... an open issue on Github made 2 months ago, with no additional comments or discussions. Simply a request from a code owner.
I don't know if this conversation is simply happening in IRC/chat, but it's unusual given how much other activity I have seen in other PR's/proposals (recent and from years prior). Was this the best reassurance that they are addressing performance?
---------
I don't mean to sound like a downer, but I feel the article is overall missing the forest for the trees. I've read about several different kinds of devs from years prior talk about how they passed on Godot because they hit hitch after hitch once they were doing something slightly advanced. a dismissal of "this is a pathological use case" sounds fine in a vacuum, but it sounds like this has been a long standing issue, and priorities simply weren't on smoothing out such hitches.
I'm not saying they should have listened to those devs, but I think the most frustrating thing is that I don't know what or who Godot wants to service. So far it sounds like they want to have all the cake, but currently are also low-key fine being a hobbyist 2D engine that can maybe do some simple 3D stuff. Which again, is fine. But that's not what it sounds like Godot is selling. It unfortunately reminds me a lot of Unity, both on the outside (yeah, having 2 unsupported netcode solutions with a 3rd in pre-alpha isn't a good look) and within the company itself. I'll quote some part of a post from the creator of Rimworld, who had similar evaluation and conclusions over 5 years ago:
>There's obviously a tremendous amount of technical talent going into Godot, but from what I can tell there's no strategic thought about market positioning or success pathways or goal pillars at all. It basically comes down to "make a good game engine", with all the lack of boundaries and lack of focus that implies.
>My initial thought: Be best at one valuable thing first, then expand out from there into adjacent domains, using the momentum accrued from the initial success. (e.g. If you want to build a restaurant empire, you start with one restaurant to dominate one neighborhood and then expand from there - you don't try to build 100 restaurants at once).
I believe the issue was less with the sizes of items being passed in and more with the API conforming to work with GDScript first and formost. Returning a dictionary for an operation that has a few float64's feels overkill and doesn't make sense even with an explanation of the available datatypes.
>Only a pathological use case is shown, the rest of the API is fine.
I wouldn't call raycasting in a full blown engine "pathological". Especially one that touts 3D
Secondly, that doesn't inspire confidence. "Don't mind the room on fire, the rest of the house is fine!". The onus is on the engine to prove that, and numbers prevail over words. So far only one part of the conversation has shown that.
Even in the next sentence it sounds like they focus on a simple API over performance, and that doesn't fill me with confidence. If Godot isn't focusing on 3D, that is fine but there's so much noise trying to to say otherwise
> Eventually, C# will be moved to the universal extension system and this will allow the unifying of the default and .net editors, it is just not the case yet, but its top in the list of priorities
I hope so, but there seems to be a trend of various "top priorities" from Godot that have trouble crossing the finish line. That's a reocurring issue even in this response alone: I'm not convinced that performance is a top priority for Godot. And that confidence means everything if the "BDFL" controls what gets into the project proper.
>The problem is that, at the C++ level, this function takes a struct pointer for performance. But at the language binding API this is difficult to expose properly. This is very old code (dating to the opensourcing of Godot) and a Dictionary was hacked-in to use temporarily until something better is found
Yup... so 10 years later that hack stays in and modern programmers come cross it.
This isn't even a critique, that's simply the nature of legacy code. Unreal has an entire part of a forced namimg scheme (the compiler won't let you run the game without conforming) that can only be explained as "well we wanted to do this in the 90's but we slowly took it out sp it's not relevant today". But if it took 10 years for someone to do more than a few dozen raycasts a frame, it says more about the battletesting than any deep dive. It goes back to my confidence above.
>, you need to create a C# version of a C++ instance as an adapter... Why is it troublesome? because C# has a garbage collector and C++ does not.
slight nitpick: while garbage collection is annoying, you technically do have a built in way to disable it in certain regions, as well as the option in later versions to have unmanaged blocks of code. I'm not saying this is easy to do, but it is something that developers much smarter than me in c# have gotten around. I know c# bindings was a relatively recent endeavor so I'm not going to give it too much flak
> Godot containers don't work like STL containers. Because they are used mainly to pass data around, they are allocated once and then kept via reference counting.
1) reference counting implies some sort of automated memory free-ing scheme. 2) That doesn't necessarily address potential issues of inefficiently allocating memory and keeping it contiguous. But I won't talk much on that because I'd need to first read more on the engine's memory allocating schemes first.
> Godot uses far more optimized containers that are not directly exposed to the binder API.
Okay, but why? Someone wanting to use C# or c++ or whatever script extension that isn't GDScript wants those optimized containers. Does it go back to the earlier quote of "it's difficult to get right and no one wanted it"?
>As a result, we created a special path for GDScript to call more efficiently.
okay, and the link is... an open issue on Github made 2 months ago, with no additional comments or discussions. Simply a request from a code owner.
I don't know if this conversation is simply happening in IRC/chat, but it's unusual given how much other activity I have seen in other PR's/proposals (recent and from years prior). Was this the best reassurance that they are addressing performance?
---------
I don't mean to sound like a downer, but I feel the article is overall missing the forest for the trees. I've read about several different kinds of devs from years prior talk about how they passed on Godot because they hit hitch after hitch once they were doing something slightly advanced. a dismissal of "this is a pathological use case" sounds fine in a vacuum, but it sounds like this has been a long standing issue, and priorities simply weren't on smoothing out such hitches.
I'm not saying they should have listened to those devs, but I think the most frustrating thing is that I don't know what or who Godot wants to service. So far it sounds like they want to have all the cake, but currently are also low-key fine being a hobbyist 2D engine that can maybe do some simple 3D stuff. Which again, is fine. But that's not what it sounds like Godot is selling. It unfortunately reminds me a lot of Unity, both on the outside (yeah, having 2 unsupported netcode solutions with a 3rd in pre-alpha isn't a good look) and within the company itself. I'll quote some part of a post from the creator of Rimworld, who had similar evaluation and conclusions over 5 years ago:
>There's obviously a tremendous amount of technical talent going into Godot, but from what I can tell there's no strategic thought about market positioning or success pathways or goal pillars at all. It basically comes down to "make a good game engine", with all the lack of boundaries and lack of focus that implies.
>My initial thought: Be best at one valuable thing first, then expand out from there into adjacent domains, using the momentum accrued from the initial success. (e.g. If you want to build a restaurant empire, you start with one restaurant to dominate one neighborhood and then expand from there - you don't try to build 100 restaurants at once).