4 ms·

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 a

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 ways to contribute than drawing a new floor plan for the house on the table cloth while the first course is being served. 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#.

johnnyanmac 3y ago
>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.
- tacotacotaco 3y ago
  > This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Better memory utilization, better processor performance[1], and no more garbage collection stutters. Oh right, it’s not your preferred language. I’d rather we all just make games instead of fighting language wars, but seeing so many of these posts in the last week makes the community feel hostile. [1] https://programming-language-benchmarks.vercel.app/rust-vs-csharp https://programming-language-benchmarks.vercel.app/rust-vs-c...
  - Rapzid 3y ago
    > I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Is this in response to the article in question? Because they are spot on with their assessments and those API issues need to get sorted. They impact bindings and all extensions including C++. The core devs seem to concur on this, it's just a matter of how it happens.
    - tacotacotaco 3y ago
      I was generally frustrated with the parade of posts about how bad Godot is from former Unity devs. This happened to be the article that I commented on.
  - johnnyanmac 3y ago
    >I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. The author has already crossed the part out suggesting to remove GDScript. Which was overblown as it was one of 3 different suggestions. Either way, even for the rude provocateurs, two wrongs don't make a right. I've follow Godot with a loose ear and it's not a surprise that there are significant performance issues in the engine. I'm glad someone is digging deeper rather than just saying "Godot isn't ready for 3D" and dismissing opportunites to grow. >If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Because you didn't get to the part of the article where it is mentioned that GDExensions uses the same api bindings as GDScript. So they are all affected by this, no matter what binding you make. Your only recourse is diving into the guts of Godot and rearranging how it works. Which is first of all, already in flight by the core team (redundancy) and secondly, not a kind of change you can easily PR in if you want to contribute (which is more hostile to the engine than any random post on social media). And yes, this is the dismissal I'm talking about. "well just use another engine" is a pretty bad approach for a growing community when receiving honest feedback with benchmarks to back it up. The author makes a long post detailing the inner guts of the engine and people cherry pick one conclusion they don't like and want to push the author out of the community.

johnnyanmac 3y ago

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

tacotacotaco 3y ago
> This dismissal of honest performance benchmarks… No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Better memory utilization, better processor performance[1], and no more garbage collection stutters. Oh right, it’s not your preferred language. I’d rather we all just make games instead of fighting language wars, but seeing so many of these posts in the last week makes the community feel hostile. [1] https://programming-language-benchmarks.vercel.app/rust-vs-csharp https://programming-language-benchmarks.vercel.app/rust-vs-c...
- Rapzid 3y ago
  > I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Is this in response to the article in question? Because they are spot on with their assessments and those API issues need to get sorted. They impact bindings and all extensions including C++. The core devs seem to concur on this, it's just a matter of how it happens.
  - tacotacotaco 3y ago
    I was generally frustrated with the parade of posts about how bad Godot is from former Unity devs. This happened to be the article that I commented on.
- johnnyanmac 3y ago
  >I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting. The author has already crossed the part out suggesting to remove GDScript. Which was overblown as it was one of 3 different suggestions. Either way, even for the rude provocateurs, two wrongs don't make a right. I've follow Godot with a loose ear and it's not a surprise that there are significant performance issues in the engine. I'm glad someone is digging deeper rather than just saying "Godot isn't ready for 3D" and dismissing opportunites to grow. >If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Because you didn't get to the part of the article where it is mentioned that GDExensions uses the same api bindings as GDScript. So they are all affected by this, no matter what binding you make. Your only recourse is diving into the guts of Godot and rearranging how it works. Which is first of all, already in flight by the core team (redundancy) and secondly, not a kind of change you can easily PR in if you want to contribute (which is more hostile to the engine than any random post on social media). And yes, this is the dismissal I'm talking about. "well just use another engine" is a pretty bad approach for a growing community when receiving honest feedback with benchmarks to back it up. The author makes a long post detailing the inner guts of the engine and people cherry pick one conclusion they don't like and want to push the author out of the community.