this post was submitted on 18 Sep 2023
83 points (97.7% liked)
Godot
5855 readers
31 users here now
Welcome to the programming.dev Godot community!
This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.
Make sure to follow the Godot CoC while chatting
We have a matrix room that can be used for chatting with other members of the community here
Links
Other Communities
- !inat@programming.dev
- !play_my_game@programming.dev
- !destroy_my_game@programming.dev
- !voxel_dev@programming.dev
- !roguelikedev@programming.dev
- !game_design@programming.dev
- !gamedev@programming.dev
Rules
- Posts need to be in english
- Posts with explicit content must be tagged with nsfw
- We do not condone harassment inside the community as well as trolling or equivalent behaviour
- Do not post illegal materials or post things encouraging actions such as pirating games
We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent
Wormhole
Credits
- The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
- The banner is from Godot Design
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
TLDR - Godot's raycasting is considerably more memory intensive than Unity's. Using the Godot API to call its raycast in any language is much slower than simply using the builtin Node. Most of the performance woes are due to how GDScript is implemented: a slow, interpreted language (Python)
It's a fair complaint, Godot is far from perfect in many areas and may not be ideal for certain projects. This is fine, really. If it's possible to make the engine better, I hope the pull requests that do so get accepted
He did a small complaint that GDScript should be ditched. If you care entirely about performance, that is true. The problem, obviously, is that a lot of people, me included, rely on it instead of C#. For all intents and purposes, this is something that could be done, but it'd end up as a wholly separate branch of Godot that would end up with several incompatibilities, eventually becoming a different engine. In that case, it might be better to just check an alternative like Stride3D or Torque3D
I understand where the C# devs are coming from, but many of these unity devs experimenting need to understand C# was hardly a consideration before microsoft earmarked funds to push and develop support for the language in the engine.
I'd be heartbroken if gdscript was ever dropped for improved C# support, games are much more fun to write in gdscript. I hope both languages can become more integrated and performent without the sacrificing of the other.
I primarily write in C#, but I really like having GDScript in my pocket for when I need something done quickly or simply.
Yeah, I don't want GDscript to end up like Unityscript or boo-lang on unity.
After programming in gdscript for a couple of years I don't want to have to go back to C# ever again.
Unity also started out that way, but they dropped their Python-like and JavaScript-like languages after they realized that nobody used them. There wasn’t so much as a blip after that announcement, indicating that they were totally right on that.