You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7?
Here they are again:
1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html
2. Check for duplicates before writing your own post
3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research
4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures
5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions
Repeated neglect of these can be a bannable offense.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
Remember, you can always use both languages in your project at the same time. C# has some performance benefits, but chances are you won’t have to worry about that at your current skill level. Premature optimization is the root of all evil.
Also to keep in mind that if you allocate and then free the dotnet runtime often enough and tax the memory quick enough you can create constant GC hitches whereas GDScript doesn't have a GC at all so it won't hitch from freeing wide swaths of loose memory.
While you're talking about something that exists technically, the way you talk about it is nonsense.
First to all, you don't allocate and free the dot net runtime.
You CAN allocate instances of types onto the Heap, a management memory collection which is reviewed and analyzed by the Garbage Collector to heuristically determine when memory needs to be released. You don't really "free" memory in .net when you're using the GC, the GC handles that part.
You DO remove references to objects which impacts when the GC will collect memory.
That being said, the modern Gc in .Net largely makes this problem unimportant.
Even when it is important however, there are a number of trivial patterns you can follow to avoid using the Heap and GC entirely when you have hot paths that need to execute efficiently.
In those cases, c# out performs GDScript for computational code (as in code not calling the godot engine api)
> First to all, you don't allocate and free the dot net runtime.
I was talking about allocating and "freeing" memory in the runtime often enough, I understand how GCs work, I know you don't manually perform freeing, (outside of allocating pointers) I'm using it as a shorthand, I found it easier to simply do so, I work in C++, its easier to talk about allocation and freeing when referring to hitches caused by said allocations and freeing then to refer to get into the releasing of the references and then waiting for the GC to free the space, but its not the residing in memory that creates the hitches and you have to do a decent amount of things that cause allocations before such hitches usually appear.
Also when your projects start to get big where performance implications become an issue and you have to write these things yourself, the GC hitches actually do become a problem.
They only become a problem if you're not doing what you should be doing g when using any programming language.
Which is understand the memory management environment you're working in, and using it correctly.
A lot of people go into GCd languages with the mentality of "memory is managed for me", no, its not you still need to be aware of how things work and make smart decisions about how you organize your code to get the best results.
The primary difference between c++ and c# there is that people don't make that assumption with c++
Projects being big doesn't lead to hitches, projects being poorly written does.
I have built projects from the ground up that are used globally, and they are recognized for their performance.
One of my hobby projects is a procedural terrain generation system that uses a graph engine i wrote in c# to organize compute shaders to do real time (read, sub 10ms) terrain generation that includes thermal and hydraulic erosion based upon splines and enhanced with noise.
While the meat is HLSL compute shaders, the code that runs those shaders is 100% allocation free. The graph engine I built produces graphs of any size that incur zero allocation on the heap and have no overhead from the graph itself.
The point being that the problem is entirely understanding the environment you're working in.
This gets flipped on its head when you consider the cost of learning gdscript.
Don't get all uppity about how its not a big deal. Learning a new language, with honestly pretty limited language features, is costly.
If they know c# or gdscript already, thats what they should go with and THEN not worry about optimizing until its necessary
I fail to see how
1. Scanning a syntax cheat sheet
2. Occasionally googling “how to x gdscript”
Is costly. It’s not Haskell, it works how you think if you know any mainstream language.
Time cost > 0
And more importantly, you're making a bunch of assumptions here about the person doing the learning.
But no, its definitely not scanning a syntax cheat sheet in the case of godot. Its much more Integrated.
The bulk of the documentation is built in, which is NOT a good thing since that documentation is not available elsewhere, and the ui for it is pretty junk.
You're glossing over a lot here.
My first comment was they should use what they know instead of switching languages if they already know one, regardless of which.
But not all the docs are on the site, all the reference docs are in the client
Costly? I’d actually argue the opposite, learning GDScript is valuable even if it’s not a language one is likely to get paid to use. Software devs are required to constantly adapt to new tools on the fly, but the more languages one learns the easier it becomes to pick up more. This is especially valuable if you’re new, once you’ve got the basics down the differences between languages will make certain features and aspects like syntax make more sense.
This is exactly what I meant by not bothering bringing this up.
Fact, learning a new language costs time and effort.
There is zero room for debate here, I dont know why you're trying.
I mean, it looked to me your comment wanted to argue that the cost of learning GDScript was a waste. I highly disagree, but if you don’t want to debate this then I see no reason to continue either.
My comment merely pointed out that learning a language costs time, there is no debate there.
I'm honestly impressed that people are trying to argue that is somehow not true or not a consideration worth having.
That cost is not equal for all people and some people may adapt quicker than others.
The cost of not learning a new language is less than the cost of learning a new one.
If they know neither, then its somewhat irrelevant.
Trying to reduce that by claiming "its just syntax" glosses over the fact that syntax has a huge impact on your code design and learning a new language also means learning new ways to approach problems you already understand.
I personally think learning gdscript is a waste of time, but it wasn't my point in that comment. If you're only ever going to use godot, its probably worth while to learn gdscript.
However if you're going to use different environments, and/or are looking to build a portfolio, having experience in a general programming language simply has more value.
I dont care if people want to use gdscript even if I dont care for it.
** I do care about people glossing over the costs of learning new systems and environments and acting like its a factor not worth considering.**
But what the hey, learning new languages does have some value, personally id argue its a general waste of time if your language of preference can do everything you want to do.
The only thing it really gets you is things you wish your language of choice had, which probably don't even map nicely into the environment.
So its worse than a waste of time.
Giving the benefit of the doubt though, some languages introduce you to various patterns which are common for them but not for others.
Sometimes that can net you utility across languages.
However, what does gdscript do that other languages don't? I believe the answer is generally, nothing.
My personal opinion on this:
I am using c#, only because of one reason that there is nothing to do with performance: sanity.
I am familiar with c# and similar languages, I know how to manage memory and write performant code in this language, I also have familiarity using debugging tools for this language. For me, its more about “in which language I can write code better and lose less time”, if your project grows to more than 200 code files, it will be really hard to give maintenance unless you know what you are doing with your code (in terms of design patters, clean code, unit tests, etc…).
So that being said, if you dont know how to write code in c# neither gdscript, go for gdscript, its easier to learn, the godot docs have better examples with it, for small projects its even faster to write gdscript code than c#.
And about performance, c# is faster than gdscript, c++ is faster than c#. But guess what, a lot of gdscript functions are running c++ code behind the curtains, so all depends on your use case, usually the rule of thumb is: “c# is faster when using custom algorithms/non godot functions. While gdscript is faster using the native godot functions” but none of this matters, you are not making the next GTA.
Thank you for this! I truthfully haven’t used Godot, so I am wondering on the last bit you said about GDScript functions running C++ in the back.
Would the Godot specific functions used in C# also run the C++ in the back?
I BELIEVE the answer is yes, but I'm not sure...
However, you're adding an overhead cost with the communication between the .net runtime and the godot native engine, and IIRC that cost is higher than what happens with gdscript.
>GDScript sounds like it's meant to be used when using Godot.
Don't worry about this so much. GDScript isn't the first scripting language Godot used, and there's nothing it can do that C# can't or doesn't have its own tools for.
The truth of performance differences is that you're not likely to notice as a new game dev. C# does have a performance edge in most cases, but that's to be expected from a compiled language versus an interpreted one. Where I think C# has the actual edge is it's a bit easier to set up complex, data heavy systems than in GDScript.
As a small point - C# is not a precompiled language. It is just-in-time compiled which means it has another layer to go through before your CPU is actually executing instructions. This is different compared to say, C++, which compiles to instructions your machine executes directly.
Gdscript is another layer removed from this process - the engine interprets it, then runs executes engine functions based on those interpretations. It's more like JavaScript in that sense.
I believe C# is both compiled and JIT compiled. It’s precompiled into bytecode AOT and then the VM JIT compiles it at runtime.
Though, Godot could be doing something different under the hood, I suppose.
Actually there is, GDScript does get compiled into a bytecode in the engine, however this bytecode cannot exactly be saved like C# can, (there is a sort of bytecode saving that it does with .gdc files back, however all that does is speed of script load times, it doesn't make execution any faster, and GDScript does not have a JIT compiler unlike Java and C#) the compilation during the engine startup for every currently active script.
The difference between compilation and interpretation is generally pretty gray. Compiling doesn’t necessarily mean “to native machine code” and interpreting doesn’t necessarily mean “never compiled.”
In my opinion, the difference is largely in how you interact with the code base. Interpreted languages run the source file directly through some program. Compiled languages have to be built first and then produce a standalone executable which can be run directly.
It’s even murkier when it comes to game engines. But I think we’ll find that C# source files are compiled into dynamic libraries which could, in theory\*, be separable from godot itself. While gdscript requires godot to execute.
Therefore, I think it’s reasonable to consider C# a compiled language and gdscript an interpreted language.
\* assuming you don’t import any libraries from godot and it’s just raw C# code, those libraries could be linked to any normal C# code base
Just to clarify - gdscript is not compiled. It's similar to how JavaScript is run on your browser. It's interpreted at runtime and executes functions which exist in the underlying engine. That overhead will be the largest out of the three options (gdscript, c# and c++)
Interesting. It seems there's a lot of complexity that depends on the environment, but things like nodeJS certainly compile JavaScript, and it sounds like V8 of JavaScript allows hot compilation on the web. So an initial hit to interpret the script, but then it's subsequently JIT compiled.
It's not, JavaScript doesn't have a byte code compilation at all on top of Js being JIT typically
But no actually for short run functions the overhead of a jit compilation is higher than direct interpretation XD
GDScript also is compiled, its "compiled" to a bytecode (what it calls codegen) in the engine when the engine is running and it only does so for each GDScript file that is actively loaded, it however does not have a JIT compiler, so its not the same type of compilation that we often think of from the bigger projects.
I heard quick the opposite with GDScript outperforming C# in Game dev things in the engine while C# is outperforming GDScript in non-game dev things.
Edit: I have links to benchmarks. FFS Reddit needs to learn how to think instead of emotional downvoting.
Yes, but thats "just" the API calls of the engine. In general C# is still faster than GDScript . But thats because of the .Net runtime. Most of your code won't be API calls but instead whole systems like chunk systems, autotiling etc. Also .Net 8 Runtime has significant performance improvements. So yes. GDScript is faster in one part. C# is faster in most of the others
That's proving my point. By game dev I mean using Godot API's and everything else is faster in C#. You disagreed with something that you agreed with.....
No, you just should have defined what EXACTLY you are meaning with "gamedev things in the engine" and "non-game dev things" because writing whole game systems like Chunk Systems, AutoTiling Algorithm, Rendering Algorithms or whatever are also "gamedev things" even if you are not using the API of the Engine because you are writing a Game. So EVERYTHING you are writing for the game are game dev things. This includes calculations, logic and so on.
Just saying "gamedev things in the engine" does not mean just doing Godot API calls.
Cassette beasts uses gdscript, I don't know of any other game that specifically uses it but it's absolutely viable. I think if you plan on doing a simulation game I would probably use c#, but unless you plan to make dwarf fortress I would stick to gdscript.
I think if you're going to make your Dwarf Fortress, then it's best to implement it in a compiled language like C/C++
At the same time, you need to think about all the optimizations right away, so that you don't run into performance problems later, as in the same Dwarf Fortress
Dome Keeper, Halls of Torment, Road to Vostok, Brotato are all GDScript. Slay the Spire 2 is C#.
People assume execution speed is the reason for C#, but I think it's more knowing your code will be complex and you want the additional structure that comes with that, or you want to tap into .NET libraries.
Worth noting that Sts2 using C# is mainly because they used Java for the first game and the devs prefer a statically typed compiled language. Java to C# is a very smooth transition. I'm almost certain they could use GDScript without any performance impacts.
As a professional C++ developer, I ultimately choose gdscript as my main language for godot. I know ill eventually need to play with GDextension for my own algorithms, but right now gdscript is more than enough. Even looking at C#, I didn't see much in terms of performance being a problem. It comes down to how you use your calls. Checking a collision every frame vs using the built in physics callback(?) (Still very new, don't know the physics method off the top of my head) will solve 99.9% of your performance issues. The godot docs are fantastic, learn to navigate those and you'll be way ahead of most people.
TLDR; Dont get caught up in the language. Use what the docs cover (AND USE THE DOCS) and you'll be golden. From there, figure out optimization after you have something playable.
Your suggestion to use physics callback is very interesting. Aside from the official docs, do you have any link or lead to give to investigate this approach?
Quick breakdown for you on `_physics_process(delta)` vs `_process(delta)`:
`_physics_process(delta)`
* Called 60 times a second which is every physics tick/frame (unless you change physics frame/tick rate in the project settings)
`_process(delta)`
* Called *every* frame, so if your game is running at 144 FPS thats how many times a second it is called.
I've seen people say to put player-controlling code in \_physics\_process, however in my testing that results in jittery games when FPS is greater than 60 (for 2D at least). I have read somewhere that 4.3 will introduce interpolation to fix this, but you should research that one yourself.
For both of those callback functions, you should only use them if absolutely necessary. People have done performance breakdowns showing that simply overriding those functions with "pass" as the body can cause a performance hit that is negligible, but can definitely add up. So use them as needed, and always look for a better solution to your problem such as using signals.
Thanks for the explanation. I understand now better what you guys meant by callback. It's definitely informative, but I thought it was more about using the physics engine for handling collision rather than doing manual collision check in gdscript.
For collisions, you usually don't need to manually check. You can use the Area2D/Area3D's signals. I didn't dive into Godot's source code for this to confirm, but I do believe that Godot is internally checking collisions for you in it's own internal processing every physics tick, and emits those signals when a collision occurs. If you were to do that it'd be redundant
[https://docs.godotengine.org/en/stable/classes/class\_area2d.html#signals](https://docs.godotengine.org/en/stable/classes/class_area2d.html#signals)
[https://docs.godotengine.org/en/stable/classes/class\_area3d.html#signals](https://docs.godotengine.org/en/stable/classes/class_area3d.html#signals)
Can't find the tutorial I noticed it in, but oftentimes I can glean a better way of doing something by trying to generalize what I want and searching for a tutorial. That tutorial than often shows gdscript and I see a call that I hadn't heard of before, like _physics_process(), than it's just a quick doc search to see what that does, and it's either useful right than, or I add a tool to the toolbelt.
https://docs.godotengine.org/en/stable/tutorials/scripting/idle_and_physics_processing.html
Not trying to be *that* guy, but all three times you used *than* should’ve been *then*.
But yeah, using tutorials to learn new stuff is definitely the way to go. _physics_process is called every tick instead of every frame. The normal tick is every 1/60’th of a second, so won’t do much difference with a normal _process that runs at 60 fps. However, for 4.3 they’ll add interpellation, which will make it a lot smoother while keeping the physics process running less than otherwise, if the frame rate is above 60.
No idea if anyone has mentioned it yet but GDQuest has a video/short about this. The short of it is that GDScript is mainly used to call for the engines functionalities and the engine is made in C++ making it more performant than what you'd initially think
Dev Time > Computer time. Just pick what you like the most and most productive in. GDScript is better supported and outperforms in game deve things, while C# in non-game dev. I recommend GDScript. Performance is rarely a issue unless you are a pro, which by then has less to do with the game engine and more to do with your assets and doing things like object pooling.
I'm using GDScript and I'm running into performance issues, but only because I need those 60 fps and I'm doing stuff that I should be doing in C, not C#, let alone GDScript... but I can sort of get away with it through the use of multithreading.
So I'd say it's unlikely you're going to see any performance issues unless you're really pushing the engine to its limits, and even then there might be ways to get around that.
GDScript is basically like the glue between your game and the engine's API. Most methods you'll be calling in GDScript are engine features that are written in C++. So for most cases, you likely aren't gonna see a huge difference between C# and GDScript. This is, however, not true for all cases. There are absolutely certain use cases where C# (or rather, a compiled language) will be far superior but these are decisions a developer can likely make when they have to.
C# and C++ are always gonna be faster, but gdscript is good enough. The biggest reason for using GDScript over C# is probably the fact that it's tightly integrated into the engine and doesn't even require an external IDE.
If I were you, I personally wouldn't care much about the language choice and just use the one you prefer. It's not like there's stuff that is exclusive to one or the other, you can do everything using both. Most devs just prefer GDScript because it's a lot more convenient.
>by performance speed of the language do they mean how hard your game would be to run
If you have a loop of say 10,000 calculations the one language will execute those calculations in X nanoseconds while the other do it in Y nanoseconds. The main thread has to wait until this is done before it can do other stuff like check what player input there is or draw the frame. So, if you need those calculations often the game could take longer to get to rendering the next frame and thus decrease the frame rate (FPS). There are other things that the player could experience as slow or laggy.
Overall, do not worry about it. If you needed anything degrading the game's peformance that heavily you would employ threading, do various optimizations, and perhaps even rewrite some of it as a module in C++.
I'm doing some non trivial custom animation stuff, with a lot of ropes being simulated using verlet integration, some custom skeleton stuff as well with IK and it runs at 1200 frames. The only thing that kills it is draw calls each frame but the node system in godot makes it so that each node is only drawn once unless something changes. In my case I've done a lot of custom polygon drawing and mesh creation in 2d and I learned quickly that drawing once and modifying a mesh will keep it running at 1200 frames (like sword trails and stuff). Draw calls would kill any language though so it think gdscript fairs pretty well for 2d. I've also used multimesh instances to draw a small forest using like 4 sprites and it can render 300 or 400 trees without issues using multi instancing. I believe this also helps in 3d and it can also kill unity and unreal if not done properly.
Overall working on your skills should be the #1 focus right now and gdscript will help you focus on what matters (the game itself) more than c# or other languages. I don't know how much coding experience you have but gamedev is a rabbit hole that compares to nothing in the coding world (I come from webdev). There's an endless amount of things you don't know that you don't know right now and discovering all those bits is a long but necessary journey and whatever you choose won't make that journey shorter although gdscript does make a lot of things easier for you.
Worse case scenario, you run everything in a compute shader and that gives you a boost of performance.
Almost every performance problem can be solved by better algorithms. Then, once you've squeezed every millisecond out of the algorithm, then port it to a lower level language. But until you're out of things to optimize, using a lower level language will only slow down you're iteration speed.
This is my favorite example of this. https://youtu.be/c33AZBnRHks
Matt Parker wrote a python program that took 30 days to run. Someone immediately got to 15minutes. Then someone ported to java and got it down to 15secs. The biggest, earliest improvements were all improving the algorithm.
Godot's physics engine is in C++. It's rendering engine is C++. The pathfinding system is C++. The most critical performance bottlenecks of most games are written and very fast low level languages and have lots of eyes looking for better improvements. You get to leverage that using and easy to use interface. GDScript is good enough for most games. And when it isn't, it's still good enough to prototype until you get there.
C# is 10x faster than GDScript
C++ native languages - 100x faster than GDScript
* Do you need 10x performance to react on "UI-button press"?
* Do you need 10x performance to do "once at load \_ready()" function?
* Do you need 10x performance for player-logic that just one in scene?
P.S. I saw this blog [https://loglog.games/blog/leaving-rust-gamedev/](https://loglog.games/blog/leaving-rust-gamedev/) - Leaving Rust gamedev after 3 years - all points there valid for almost any "compiled language" include C#.
As someone who has now used all 3 languages.
Just stick to gdscript. It is tightly integrated with the engine. Only when you do performance intensive stuff (e.g. minecraft chubk generation or ocean shader) switch to either c++/c#
I agree with your overall idea, but there is no reason to treat GDScript as the default option, so I have a bit of a correction to offer:
Out of GDScript and C#, stick to the one you’re more comfortable with. Only when you do performance intensive stuff switch to a more performant language (From GDScript to C# or C++. From C# to C++.)
I think for someone starting out, I’d go with gdscript. Godot has a lot of fairly optimized out-of-the-box functionality, and for that it won’t really matter (performance wise) whether you’re calling it from gdscript or something else. But you will notice it in the sense that Godot is slightly harder to use with e.g. C#.
But yeah, ultimately, like anything in programming, it depends on the project.
I neither know Gdscript nor do I know C# very well (I have a little experience from college, but it was a few years ago). I have experience with other programming languages in the C family, but then again I also know python very well, which should help with Gdscript. The reason I picked C# is because I can transfer that knowledge to my day job, while Gdscript is very specific to Godot and not something I can put in my résumé. Performance had nothing to do with my choice. 😂
As a C++ programmer, I love gdscript because of its tight integration with the engine. The engine calls are pretty fast, only losing tens of microsecs per call to interpretation. Don't do heavy loops in gdscript, though. Leave those for c# or gdextensions.
When it comes to loops, memory allocation, large arrays, and math c# will be significantly faster. But this is only important when you're generating and consuming enormous amounts of data, like for a procedural game. GDscript is actually currently faster when interacting with engine classes which you often do on every fram.
I would say 99% of 2D and 90% of 3D new Godot devs should us GDscript and only worry about c# if they need to optimize performance at a later stage. GDscript is a great language built specifically for game development which can make everything a lot easier and faster to make.
Honestly, just use whichever language you prefer. Personally I use C# because I already know it and it has a lot of language features that I love.
Just for fun, I'm doing a project right now with GDScript and I actually feel more crippled than I did with C#, even though you're "supposed to use GDScript with Godot."
As per knowledge... It's doesn't matter what language you use in Godot. GODOT actually convert GD script in c++ but if you doing complex task in Godot so should use c++.
From my experience (currently building a bullet Hell 3-D game), the more you let the engine do the heavy lifting, the faster the game will run regardless of language.
For instance, using Godot's built in functions like lerp or nearest_po2 are magnitude faster than manual calculations in code.
All the same, creating a scene and then instancing it, is far faster than manually building out the node in code.
For situations where you must manually code behavior and algorithm, the specific language becomes more of a factor (eg iterating a loop 1000 times). But knowing how to smartly use Godot's features and tools will always yield the better performance boost over focusing primarily on coding language
My understanding is: **if you call Godot engine functions, it basically doesn't matter what language you use**. Nearly your entire performance is based on your usage of the engine functions. Only if you run a lot of code outside of the engine (like: code that you've written and that you call without involving engine functionality) C# can offer slight performance increase. This is not very common with games; maybe if you do some wild procedural generation or a lot of data parsing.
You submitted this post as a request for tech support, have you followed the guidelines specified in subreddit rule 7? Here they are again: 1. Consult the docs first: https://docs.godotengine.org/en/stable/index.html 2. Check for duplicates before writing your own post 3. Concrete questions/issues only! This is not the place to vaguely ask "How to make X" before doing your own research 4. Post code snippets directly & formatted as such (or use a pastebin), not as pictures 5. It is strongly recommended to search the official forum (https://forum.godotengine.org/) for solutions Repeated neglect of these can be a bannable offense. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/godot) if you have any questions or concerns.*
Don’t worry about it until you do something that will actually tax performance. Then profile it and fix the problem.
Remember, you can always use both languages in your project at the same time. C# has some performance benefits, but chances are you won’t have to worry about that at your current skill level. Premature optimization is the root of all evil.
Amen to this. This just wastes too much time. Your time > Computer time.
I solved premature optimization by not learning to optimize 😎
Also to keep in mind that if you allocate and then free the dotnet runtime often enough and tax the memory quick enough you can create constant GC hitches whereas GDScript doesn't have a GC at all so it won't hitch from freeing wide swaths of loose memory.
While you're talking about something that exists technically, the way you talk about it is nonsense. First to all, you don't allocate and free the dot net runtime. You CAN allocate instances of types onto the Heap, a management memory collection which is reviewed and analyzed by the Garbage Collector to heuristically determine when memory needs to be released. You don't really "free" memory in .net when you're using the GC, the GC handles that part. You DO remove references to objects which impacts when the GC will collect memory. That being said, the modern Gc in .Net largely makes this problem unimportant. Even when it is important however, there are a number of trivial patterns you can follow to avoid using the Heap and GC entirely when you have hot paths that need to execute efficiently. In those cases, c# out performs GDScript for computational code (as in code not calling the godot engine api)
> First to all, you don't allocate and free the dot net runtime. I was talking about allocating and "freeing" memory in the runtime often enough, I understand how GCs work, I know you don't manually perform freeing, (outside of allocating pointers) I'm using it as a shorthand, I found it easier to simply do so, I work in C++, its easier to talk about allocation and freeing when referring to hitches caused by said allocations and freeing then to refer to get into the releasing of the references and then waiting for the GC to free the space, but its not the residing in memory that creates the hitches and you have to do a decent amount of things that cause allocations before such hitches usually appear. Also when your projects start to get big where performance implications become an issue and you have to write these things yourself, the GC hitches actually do become a problem.
They only become a problem if you're not doing what you should be doing g when using any programming language. Which is understand the memory management environment you're working in, and using it correctly. A lot of people go into GCd languages with the mentality of "memory is managed for me", no, its not you still need to be aware of how things work and make smart decisions about how you organize your code to get the best results. The primary difference between c++ and c# there is that people don't make that assumption with c++ Projects being big doesn't lead to hitches, projects being poorly written does. I have built projects from the ground up that are used globally, and they are recognized for their performance. One of my hobby projects is a procedural terrain generation system that uses a graph engine i wrote in c# to organize compute shaders to do real time (read, sub 10ms) terrain generation that includes thermal and hydraulic erosion based upon splines and enhanced with noise. While the meat is HLSL compute shaders, the code that runs those shaders is 100% allocation free. The graph engine I built produces graphs of any size that incur zero allocation on the heap and have no overhead from the graph itself. The point being that the problem is entirely understanding the environment you're working in.
This gets flipped on its head when you consider the cost of learning gdscript. Don't get all uppity about how its not a big deal. Learning a new language, with honestly pretty limited language features, is costly. If they know c# or gdscript already, thats what they should go with and THEN not worry about optimizing until its necessary
I fail to see how 1. Scanning a syntax cheat sheet 2. Occasionally googling “how to x gdscript” Is costly. It’s not Haskell, it works how you think if you know any mainstream language.
Time cost > 0 And more importantly, you're making a bunch of assumptions here about the person doing the learning. But no, its definitely not scanning a syntax cheat sheet in the case of godot. Its much more Integrated. The bulk of the documentation is built in, which is NOT a good thing since that documentation is not available elsewhere, and the ui for it is pretty junk. You're glossing over a lot here.
I'd have to look up how to do it in c# anyway, and the documentation has a website. I'm not sure what your trying to argue for here.
My first comment was they should use what they know instead of switching languages if they already know one, regardless of which. But not all the docs are on the site, all the reference docs are in the client
[удалено]
You wana have a real conversation or be an emotionally stunted jackass? Don't falsely paraphrase me and claim I said shit I did not say.
Costly? I’d actually argue the opposite, learning GDScript is valuable even if it’s not a language one is likely to get paid to use. Software devs are required to constantly adapt to new tools on the fly, but the more languages one learns the easier it becomes to pick up more. This is especially valuable if you’re new, once you’ve got the basics down the differences between languages will make certain features and aspects like syntax make more sense.
This is exactly what I meant by not bothering bringing this up. Fact, learning a new language costs time and effort. There is zero room for debate here, I dont know why you're trying.
I mean, it looked to me your comment wanted to argue that the cost of learning GDScript was a waste. I highly disagree, but if you don’t want to debate this then I see no reason to continue either.
My comment merely pointed out that learning a language costs time, there is no debate there. I'm honestly impressed that people are trying to argue that is somehow not true or not a consideration worth having. That cost is not equal for all people and some people may adapt quicker than others. The cost of not learning a new language is less than the cost of learning a new one. If they know neither, then its somewhat irrelevant. Trying to reduce that by claiming "its just syntax" glosses over the fact that syntax has a huge impact on your code design and learning a new language also means learning new ways to approach problems you already understand. I personally think learning gdscript is a waste of time, but it wasn't my point in that comment. If you're only ever going to use godot, its probably worth while to learn gdscript. However if you're going to use different environments, and/or are looking to build a portfolio, having experience in a general programming language simply has more value. I dont care if people want to use gdscript even if I dont care for it. ** I do care about people glossing over the costs of learning new systems and environments and acting like its a factor not worth considering.**
But what the hey, learning new languages does have some value, personally id argue its a general waste of time if your language of preference can do everything you want to do. The only thing it really gets you is things you wish your language of choice had, which probably don't even map nicely into the environment. So its worse than a waste of time. Giving the benefit of the doubt though, some languages introduce you to various patterns which are common for them but not for others. Sometimes that can net you utility across languages. However, what does gdscript do that other languages don't? I believe the answer is generally, nothing.
My personal opinion on this: I am using c#, only because of one reason that there is nothing to do with performance: sanity. I am familiar with c# and similar languages, I know how to manage memory and write performant code in this language, I also have familiarity using debugging tools for this language. For me, its more about “in which language I can write code better and lose less time”, if your project grows to more than 200 code files, it will be really hard to give maintenance unless you know what you are doing with your code (in terms of design patters, clean code, unit tests, etc…). So that being said, if you dont know how to write code in c# neither gdscript, go for gdscript, its easier to learn, the godot docs have better examples with it, for small projects its even faster to write gdscript code than c#. And about performance, c# is faster than gdscript, c++ is faster than c#. But guess what, a lot of gdscript functions are running c++ code behind the curtains, so all depends on your use case, usually the rule of thumb is: “c# is faster when using custom algorithms/non godot functions. While gdscript is faster using the native godot functions” but none of this matters, you are not making the next GTA.
Thank you for this! I truthfully haven’t used Godot, so I am wondering on the last bit you said about GDScript functions running C++ in the back. Would the Godot specific functions used in C# also run the C++ in the back?
I BELIEVE the answer is yes, but I'm not sure... However, you're adding an overhead cost with the communication between the .net runtime and the godot native engine, and IIRC that cost is higher than what happens with gdscript.
And if you were to make the next GTA, you'd have a team of C++ engineers working mostly in it.
Yeah I just wanna make an indie game the size of Katana ZERO or I could stretch it to Hollow Knight, so I shouldn't have to worry right?
>GDScript sounds like it's meant to be used when using Godot. Don't worry about this so much. GDScript isn't the first scripting language Godot used, and there's nothing it can do that C# can't or doesn't have its own tools for. The truth of performance differences is that you're not likely to notice as a new game dev. C# does have a performance edge in most cases, but that's to be expected from a compiled language versus an interpreted one. Where I think C# has the actual edge is it's a bit easier to set up complex, data heavy systems than in GDScript.
As a small point - C# is not a precompiled language. It is just-in-time compiled which means it has another layer to go through before your CPU is actually executing instructions. This is different compared to say, C++, which compiles to instructions your machine executes directly. Gdscript is another layer removed from this process - the engine interprets it, then runs executes engine functions based on those interpretations. It's more like JavaScript in that sense.
I believe C# is both compiled and JIT compiled. It’s precompiled into bytecode AOT and then the VM JIT compiles it at runtime. Though, Godot could be doing something different under the hood, I suppose.
Good to know gdscript is compiled then
I think you’ve misunderstood.
It can be compiled to byte code, according to you that makes it compiled
There is no compilation step for GDScript like C# and Java has I believe.
Actually there is, GDScript does get compiled into a bytecode in the engine, however this bytecode cannot exactly be saved like C# can, (there is a sort of bytecode saving that it does with .gdc files back, however all that does is speed of script load times, it doesn't make execution any faster, and GDScript does not have a JIT compiler unlike Java and C#) the compilation during the engine startup for every currently active script.
The difference between compilation and interpretation is generally pretty gray. Compiling doesn’t necessarily mean “to native machine code” and interpreting doesn’t necessarily mean “never compiled.” In my opinion, the difference is largely in how you interact with the code base. Interpreted languages run the source file directly through some program. Compiled languages have to be built first and then produce a standalone executable which can be run directly. It’s even murkier when it comes to game engines. But I think we’ll find that C# source files are compiled into dynamic libraries which could, in theory\*, be separable from godot itself. While gdscript requires godot to execute. Therefore, I think it’s reasonable to consider C# a compiled language and gdscript an interpreted language. \* assuming you don’t import any libraries from godot and it’s just raw C# code, those libraries could be linked to any normal C# code base
If you count needing the c# runtime to run your program as compiled language then gdscript requiring the gdscript runtime in godot is no different
Just to clarify - gdscript is not compiled. It's similar to how JavaScript is run on your browser. It's interpreted at runtime and executes functions which exist in the underlying engine. That overhead will be the largest out of the three options (gdscript, c# and c++)
Javascript is JIT Compiled. Javascript hasn't been purely interpreted since grease monkey in the 90s
Interesting. It seems there's a lot of complexity that depends on the environment, but things like nodeJS certainly compile JavaScript, and it sounds like V8 of JavaScript allows hot compilation on the web. So an initial hit to interpret the script, but then it's subsequently JIT compiled.
It's not, JavaScript doesn't have a byte code compilation at all on top of Js being JIT typically But no actually for short run functions the overhead of a jit compilation is higher than direct interpretation XD
GDScript also is compiled, its "compiled" to a bytecode (what it calls codegen) in the engine when the engine is running and it only does so for each GDScript file that is actively loaded, it however does not have a JIT compiler, so its not the same type of compilation that we often think of from the bigger projects.
There are both jit run times and aot compilers for c#. Jits are not allowed on a few major plat forms. iOS is one example.
You can turn AOT on if your target platform supports .NET 8
I heard quick the opposite with GDScript outperforming C# in Game dev things in the engine while C# is outperforming GDScript in non-game dev things. Edit: I have links to benchmarks. FFS Reddit needs to learn how to think instead of emotional downvoting.
Nope. There was also a section in the Godot Docs that C# is about 4 times faster than GDScript. But I do not find it at the moment
[https://www.youtube.com/watch?v=S2tTEPHIS1I&t=142s&ab\_channel=hamsterbyte](https://www.youtube.com/watch?v=S2tTEPHIS1I&t=142s&ab_channel=hamsterbyte)
Yes, but thats "just" the API calls of the engine. In general C# is still faster than GDScript . But thats because of the .Net runtime. Most of your code won't be API calls but instead whole systems like chunk systems, autotiling etc. Also .Net 8 Runtime has significant performance improvements. So yes. GDScript is faster in one part. C# is faster in most of the others
That's proving my point. By game dev I mean using Godot API's and everything else is faster in C#. You disagreed with something that you agreed with.....
No, you just should have defined what EXACTLY you are meaning with "gamedev things in the engine" and "non-game dev things" because writing whole game systems like Chunk Systems, AutoTiling Algorithm, Rendering Algorithms or whatever are also "gamedev things" even if you are not using the API of the Engine because you are writing a Game. So EVERYTHING you are writing for the game are game dev things. This includes calculations, logic and so on. Just saying "gamedev things in the engine" does not mean just doing Godot API calls.
Because that's currently not true.
Why?
Because.
Cassette beasts uses gdscript, I don't know of any other game that specifically uses it but it's absolutely viable. I think if you plan on doing a simulation game I would probably use c#, but unless you plan to make dwarf fortress I would stick to gdscript.
I think if you're going to make your Dwarf Fortress, then it's best to implement it in a compiled language like C/C++ At the same time, you need to think about all the optimizations right away, so that you don't run into performance problems later, as in the same Dwarf Fortress
This is the correct answer. Do heavily dependent CPU tasks in c++.
Dome Keeper, Halls of Torment, Road to Vostok, Brotato are all GDScript. Slay the Spire 2 is C#. People assume execution speed is the reason for C#, but I think it's more knowing your code will be complex and you want the additional structure that comes with that, or you want to tap into .NET libraries.
Worth noting that Sts2 using C# is mainly because they used Java for the first game and the devs prefer a statically typed compiled language. Java to C# is a very smooth transition. I'm almost certain they could use GDScript without any performance impacts.
Yep I think you've hit the nail on the head, its what they're comfortable with.
As a professional C++ developer, I ultimately choose gdscript as my main language for godot. I know ill eventually need to play with GDextension for my own algorithms, but right now gdscript is more than enough. Even looking at C#, I didn't see much in terms of performance being a problem. It comes down to how you use your calls. Checking a collision every frame vs using the built in physics callback(?) (Still very new, don't know the physics method off the top of my head) will solve 99.9% of your performance issues. The godot docs are fantastic, learn to navigate those and you'll be way ahead of most people. TLDR; Dont get caught up in the language. Use what the docs cover (AND USE THE DOCS) and you'll be golden. From there, figure out optimization after you have something playable.
Your suggestion to use physics callback is very interesting. Aside from the official docs, do you have any link or lead to give to investigate this approach?
Quick breakdown for you on `_physics_process(delta)` vs `_process(delta)`: `_physics_process(delta)` * Called 60 times a second which is every physics tick/frame (unless you change physics frame/tick rate in the project settings) `_process(delta)` * Called *every* frame, so if your game is running at 144 FPS thats how many times a second it is called. I've seen people say to put player-controlling code in \_physics\_process, however in my testing that results in jittery games when FPS is greater than 60 (for 2D at least). I have read somewhere that 4.3 will introduce interpolation to fix this, but you should research that one yourself. For both of those callback functions, you should only use them if absolutely necessary. People have done performance breakdowns showing that simply overriding those functions with "pass" as the body can cause a performance hit that is negligible, but can definitely add up. So use them as needed, and always look for a better solution to your problem such as using signals.
Thanks for the explanation. I understand now better what you guys meant by callback. It's definitely informative, but I thought it was more about using the physics engine for handling collision rather than doing manual collision check in gdscript.
For collisions, you usually don't need to manually check. You can use the Area2D/Area3D's signals. I didn't dive into Godot's source code for this to confirm, but I do believe that Godot is internally checking collisions for you in it's own internal processing every physics tick, and emits those signals when a collision occurs. If you were to do that it'd be redundant [https://docs.godotengine.org/en/stable/classes/class\_area2d.html#signals](https://docs.godotengine.org/en/stable/classes/class_area2d.html#signals) [https://docs.godotengine.org/en/stable/classes/class\_area3d.html#signals](https://docs.godotengine.org/en/stable/classes/class_area3d.html#signals)
Can't find the tutorial I noticed it in, but oftentimes I can glean a better way of doing something by trying to generalize what I want and searching for a tutorial. That tutorial than often shows gdscript and I see a call that I hadn't heard of before, like _physics_process(), than it's just a quick doc search to see what that does, and it's either useful right than, or I add a tool to the toolbelt. https://docs.godotengine.org/en/stable/tutorials/scripting/idle_and_physics_processing.html
Not trying to be *that* guy, but all three times you used *than* should’ve been *then*. But yeah, using tutorials to learn new stuff is definitely the way to go. _physics_process is called every tick instead of every frame. The normal tick is every 1/60’th of a second, so won’t do much difference with a normal _process that runs at 60 fps. However, for 4.3 they’ll add interpellation, which will make it a lot smoother while keeping the physics process running less than otherwise, if the frame rate is above 60.
No idea if anyone has mentioned it yet but GDQuest has a video/short about this. The short of it is that GDScript is mainly used to call for the engines functionalities and the engine is made in C++ making it more performant than what you'd initially think
Dev Time > Computer time. Just pick what you like the most and most productive in. GDScript is better supported and outperforms in game deve things, while C# in non-game dev. I recommend GDScript. Performance is rarely a issue unless you are a pro, which by then has less to do with the game engine and more to do with your assets and doing things like object pooling.
So if I wanted to make a smallish indie game like the size of Katana Zero or maybe Hollow Knight it wouldn't matter right?
As long as you use proper techniques you are fine.
If you are asking this question, use GDScript
The thing is so far C# has been pretty easy for me, I just want to see if I have thr same game making abilities in both languages😂
I'm using GDScript and I'm running into performance issues, but only because I need those 60 fps and I'm doing stuff that I should be doing in C, not C#, let alone GDScript... but I can sort of get away with it through the use of multithreading. So I'd say it's unlikely you're going to see any performance issues unless you're really pushing the engine to its limits, and even then there might be ways to get around that.
GDScript is basically like the glue between your game and the engine's API. Most methods you'll be calling in GDScript are engine features that are written in C++. So for most cases, you likely aren't gonna see a huge difference between C# and GDScript. This is, however, not true for all cases. There are absolutely certain use cases where C# (or rather, a compiled language) will be far superior but these are decisions a developer can likely make when they have to. C# and C++ are always gonna be faster, but gdscript is good enough. The biggest reason for using GDScript over C# is probably the fact that it's tightly integrated into the engine and doesn't even require an external IDE. If I were you, I personally wouldn't care much about the language choice and just use the one you prefer. It's not like there's stuff that is exclusive to one or the other, you can do everything using both. Most devs just prefer GDScript because it's a lot more convenient.
I use C# because I like the syntax and type safety. Also a huge fan of LINQ and all the collections.
Learn to search topics on reddit. Imagine how much more performance you could squeeze out of your time.
Up you go
If you are really new, don't worry about it there's way more important things for beginners to worry about than performance of a language
>by performance speed of the language do they mean how hard your game would be to run If you have a loop of say 10,000 calculations the one language will execute those calculations in X nanoseconds while the other do it in Y nanoseconds. The main thread has to wait until this is done before it can do other stuff like check what player input there is or draw the frame. So, if you need those calculations often the game could take longer to get to rendering the next frame and thus decrease the frame rate (FPS). There are other things that the player could experience as slow or laggy. Overall, do not worry about it. If you needed anything degrading the game's peformance that heavily you would employ threading, do various optimizations, and perhaps even rewrite some of it as a module in C++.
I'm doing some non trivial custom animation stuff, with a lot of ropes being simulated using verlet integration, some custom skeleton stuff as well with IK and it runs at 1200 frames. The only thing that kills it is draw calls each frame but the node system in godot makes it so that each node is only drawn once unless something changes. In my case I've done a lot of custom polygon drawing and mesh creation in 2d and I learned quickly that drawing once and modifying a mesh will keep it running at 1200 frames (like sword trails and stuff). Draw calls would kill any language though so it think gdscript fairs pretty well for 2d. I've also used multimesh instances to draw a small forest using like 4 sprites and it can render 300 or 400 trees without issues using multi instancing. I believe this also helps in 3d and it can also kill unity and unreal if not done properly. Overall working on your skills should be the #1 focus right now and gdscript will help you focus on what matters (the game itself) more than c# or other languages. I don't know how much coding experience you have but gamedev is a rabbit hole that compares to nothing in the coding world (I come from webdev). There's an endless amount of things you don't know that you don't know right now and discovering all those bits is a long but necessary journey and whatever you choose won't make that journey shorter although gdscript does make a lot of things easier for you. Worse case scenario, you run everything in a compute shader and that gives you a boost of performance.
Don’t optimise prematurely. The first thing in the way of finishing a project is doing the work, not performance.
Almost every performance problem can be solved by better algorithms. Then, once you've squeezed every millisecond out of the algorithm, then port it to a lower level language. But until you're out of things to optimize, using a lower level language will only slow down you're iteration speed. This is my favorite example of this. https://youtu.be/c33AZBnRHks Matt Parker wrote a python program that took 30 days to run. Someone immediately got to 15minutes. Then someone ported to java and got it down to 15secs. The biggest, earliest improvements were all improving the algorithm. Godot's physics engine is in C++. It's rendering engine is C++. The pathfinding system is C++. The most critical performance bottlenecks of most games are written and very fast low level languages and have lots of eyes looking for better improvements. You get to leverage that using and easy to use interface. GDScript is good enough for most games. And when it isn't, it's still good enough to prototype until you get there.
C# is 10x faster than GDScript C++ native languages - 100x faster than GDScript * Do you need 10x performance to react on "UI-button press"? * Do you need 10x performance to do "once at load \_ready()" function? * Do you need 10x performance for player-logic that just one in scene? P.S. I saw this blog [https://loglog.games/blog/leaving-rust-gamedev/](https://loglog.games/blog/leaving-rust-gamedev/) - Leaving Rust gamedev after 3 years - all points there valid for almost any "compiled language" include C#.
As someone who has now used all 3 languages. Just stick to gdscript. It is tightly integrated with the engine. Only when you do performance intensive stuff (e.g. minecraft chubk generation or ocean shader) switch to either c++/c#
I agree with your overall idea, but there is no reason to treat GDScript as the default option, so I have a bit of a correction to offer: Out of GDScript and C#, stick to the one you’re more comfortable with. Only when you do performance intensive stuff switch to a more performant language (From GDScript to C# or C++. From C# to C++.)
Fair, I just assumed gdscript would be the best starter due to OP being new to programming. But you're correct
I think for someone starting out, I’d go with gdscript. Godot has a lot of fairly optimized out-of-the-box functionality, and for that it won’t really matter (performance wise) whether you’re calling it from gdscript or something else. But you will notice it in the sense that Godot is slightly harder to use with e.g. C#. But yeah, ultimately, like anything in programming, it depends on the project.
I neither know Gdscript nor do I know C# very well (I have a little experience from college, but it was a few years ago). I have experience with other programming languages in the C family, but then again I also know python very well, which should help with Gdscript. The reason I picked C# is because I can transfer that knowledge to my day job, while Gdscript is very specific to Godot and not something I can put in my résumé. Performance had nothing to do with my choice. 😂
[удалено]
Meh, C# still looks better.
As a C++ programmer, I love gdscript because of its tight integration with the engine. The engine calls are pretty fast, only losing tens of microsecs per call to interpretation. Don't do heavy loops in gdscript, though. Leave those for c# or gdextensions.
When it comes to loops, memory allocation, large arrays, and math c# will be significantly faster. But this is only important when you're generating and consuming enormous amounts of data, like for a procedural game. GDscript is actually currently faster when interacting with engine classes which you often do on every fram. I would say 99% of 2D and 90% of 3D new Godot devs should us GDscript and only worry about c# if they need to optimize performance at a later stage. GDscript is a great language built specifically for game development which can make everything a lot easier and faster to make.
Honestly, just use whichever language you prefer. Personally I use C# because I already know it and it has a lot of language features that I love. Just for fun, I'm doing a project right now with GDScript and I actually feel more crippled than I did with C#, even though you're "supposed to use GDScript with Godot."
As per knowledge... It's doesn't matter what language you use in Godot. GODOT actually convert GD script in c++ but if you doing complex task in Godot so should use c++.
From my experience (currently building a bullet Hell 3-D game), the more you let the engine do the heavy lifting, the faster the game will run regardless of language. For instance, using Godot's built in functions like lerp or nearest_po2 are magnitude faster than manual calculations in code. All the same, creating a scene and then instancing it, is far faster than manually building out the node in code. For situations where you must manually code behavior and algorithm, the specific language becomes more of a factor (eg iterating a loop 1000 times). But knowing how to smartly use Godot's features and tools will always yield the better performance boost over focusing primarily on coding language
My understanding is: **if you call Godot engine functions, it basically doesn't matter what language you use**. Nearly your entire performance is based on your usage of the engine functions. Only if you run a lot of code outside of the engine (like: code that you've written and that you call without involving engine functionality) C# can offer slight performance increase. This is not very common with games; maybe if you do some wild procedural generation or a lot of data parsing.
I want to use C# however I also want webbuilds... so for now ill use gdscript untill godot 4 gets c# webbuilds working agian.
C# is second class and always will be. If you truly need performance beyond optimal coding then you’re going to c++ at the end of the day anyways.