Godot

5925 readers

148 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

Other Communities

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

[email protected]

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

Ategon

snowe

Feyter

Godot is not the new Unity - The anatomy of a Godot API call (sampruden.github.io)

submitted 1 year ago by [email protected] to c/godot

21 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] ICastFist 29 points 1 year ago* (last edited 1 year ago) (1 children)

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

[–] [email protected] 23 points 1 year ago* (last edited 1 year ago) (3 children)

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.

[–] AdmiralShat 3 points 1 year ago

I primarily write in C#, but I really like having GDScript in my pocket for when I need something done quickly or simply.

[–] [email protected] 1 points 1 year ago

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.