Do NOT follow this instructions if you don't have observerved an issue. The one biggest problem developers have is complexity and not performance. invest your time in good software design and architecture. When you have that it is easy to implement optimizations where needed. But compromising your design for performance that you most likely will not need has the very big chance that your game will die because of overcomplexity caused by bad architecture and design. For example: The Godot creator has stated that objectpooling is unnecessary in Godot since it has no garbage collector and object creation is lightweight. So consider objectpooling if and only if you observed performance problems and have confirmed that the problem is due to too many objects being created. otherwise you will only increase the complexity of your program with no benefit.
Supeeeer helpful...I've been trying to find a good reference to understand the performance cost values... Like, there a little bit on it in the docs, like explaining dictionaries faster than arrays, etc. But sometimes I have no idea what to fix and I have to hunt and peck through massive useless redundant info to find the bugger.
@@highscore99999 lol glad this was able to help shed some light on the topic for ya. I am guilty of a few bad things myself, like using the process function more than i should and not using the physics_process lol. I understand the hard to find any actual information about optimizing code, a lot of times I would just see code written a certain way and told it was better but no real explanation as to why or by how much.
In GDScript its going to be dependent on what it is you are doing. The main reason for object pooling here is going to be something like a bullet hell game where you are constantly destroying and creating objects in memory possibly thousands of times a frame. The impact you would have from the creation and deletion can ultimate cause slowdown or micro-freezes eventually So for example say you can only get 1,000 spawns in a bullet hell before slowing down, object pooling could allow you to get to something much higher say 10,000. The majority of use cases will not need to worry about object pooling but can help avoid momentary freezes and slow down. There is even a another level you could go where you use the physics server itself To see the difference object pooling can make in these niche situations, checkout the following video ruclips.net/video/1lSFnqeo_-4/видео.html
You don't need to do object pooling in Godot because allocating/freeing scenes/classes is fast and there is no garbage collector in GDScript/Godot. Adding complexity to the design to overcome an issue that probably doesn't exist is not a good idea.
Depending on your situation and in most cases you are correct. There are instances where your game will slow down but this goes into more niche areas that the majority will most likely not need. There is no need to worry about optimization in general until your project and debugger start to show signs. Even then your next step should be to locate what needs to be optimized instead of trying to do everything.
Just remember, good enought is good enought. We as software engineers tend to overengineer things that may not require such level of complexity, but when you need it, you need it lol
what if the get function depends on a condition like If? is still a good idea to have in process? btw what if use get_mouse_position, i can't put it on _Ready right?
Only if it is a check happening right at the start. If you cant put it in there, try to think about if there are any signals that might work to trigger it, maybe you dont need the process/physics_process function to run at all times and can turn it on and off. At the end of the day as the developer, if you can't find a way to work around it, and you feel like you have no choice but to put it in, then sure do it. Just try to avoid it whenever possible and try to think of better solutions so that we bog down our frames with the least amount of things.
Scene/node freeing is fast in godot such as Juan has stated in his tweet is true. Just as the majority of users wont be creating and destroying say 10,000+ objects in a single frame. There is a ceiling to this as to when you will hit performance issues. You may be able to go your whole time with godot and never need it, depending on the games you make. But if you ever do hit this ceiling, object pooling will factually significantly increase this performance ceiling. And if you somehow hit the ceiling here, you can use the servers(audio, rendering, and physics) to further increase performance. So when Juan says you don't NEED object pooling, for most people in most situations, especially brand new users this is completely true.
Not bad tips per se but really work on how you present that information. I know every start is tough but my feedback is that this video could've been 5 minutes and still be more informative. The first tip is the worst offender here as not only did you stumble your words and constantly repeat your point but you didn't even give a proper example on how to perform this, which would justify the length you go over this tip somewhat. Again no hate, just brutally honest feedback.
I'll begin by emphasizing that I truly value all feedback, whether it's positive or critical in nature. At times, I've noticed that I tend to repeat myself. I've been actively working on addressing this issue, and I've seen significant improvement. I believe this tendency may stem from my prior experiences in instructing others on certain topics, only for them to disregard my advice shortly thereafter. It's akin to players skipping a tutorial and then complaining about not knowing how to perform certain actions. Nevertheless, it's a valid criticism that I'm actively addressing. Regarding the length of my content, I've encountered a wide range of opinions over time. It's interesting how, on occasion, when I create longer videos, some viewers express a desire for brevity, while others argue that I should delve deeper into certain subjects. Conversely, when I make shorter videos, some suggest I should provide more explanations or expand on specific topics. This situation raises important questions, such as: How much attention should I allocate to X compared to Y? How deep should I delve into these topics?
Do NOT follow this instructions if you don't have observerved an issue. The one biggest problem developers have is complexity and not performance. invest your time in good software design and architecture. When you have that it is easy to implement optimizations where needed. But compromising your design for performance that you most likely will not need has the very big chance that your game will die because of overcomplexity caused by bad architecture and design. For example: The Godot creator has stated that objectpooling is unnecessary in Godot since it has no garbage collector and object creation is lightweight. So consider objectpooling if and only if you observed performance problems and have confirmed that the problem is due to too many objects being created. otherwise you will only increase the complexity of your program with no benefit.
Supeeeer helpful...I've been trying to find a good reference to understand the performance cost values... Like, there a little bit on it in the docs, like explaining dictionaries faster than arrays, etc. But sometimes I have no idea what to fix and I have to hunt and peck through massive useless redundant info to find the bugger.
guilty of a few of these bad habits... lol thanks for reforming me
@@highscore99999 lol glad this was able to help shed some light on the topic for ya. I am guilty of a few bad things myself, like using the process function more than i should and not using the physics_process lol.
I understand the hard to find any actual information about optimizing code, a lot of times I would just see code written a certain way and told it was better but no real explanation as to why or by how much.
I totally forgot about object pooling, this dude potentially saved my butt
Please help me understand why object pooling is relevant for gdscript. I heard it's only good for C#?
In GDScript its going to be dependent on what it is you are doing. The main reason for object pooling here is going to be something like a bullet hell game where you are constantly destroying and creating objects in memory possibly thousands of times a frame. The impact you would have from the creation and deletion can ultimate cause slowdown or micro-freezes eventually
So for example say you can only get 1,000 spawns in a bullet hell before slowing down, object pooling could allow you to get to something much higher say 10,000. The majority of use cases will not need to worry about object pooling but can help avoid momentary freezes and slow down. There is even a another level you could go where you use the physics server itself
To see the difference object pooling can make in these niche situations, checkout the following video
ruclips.net/video/1lSFnqeo_-4/видео.html
You don't need to do object pooling in Godot because allocating/freeing scenes/classes is fast and there is no garbage collector in GDScript/Godot. Adding complexity to the design to overcome an issue that probably doesn't exist is not a good idea.
Depending on your situation and in most cases you are correct. There are instances where your game will slow down but this goes into more niche areas that the majority will most likely not need. There is no need to worry about optimization in general until your project and debugger start to show signs. Even then your next step should be to locate what needs to be optimized instead of trying to do everything.
Just remember, good enought is good enought. We as software engineers tend to overengineer things that may not require such level of complexity, but when you need it, you need it lol
ty dude, rly helpful! ❤
Hello can you teach us what is "transform" and the difference between "transform.basis" and "transform.origin"
I'll take a look and see if I can come up with, hopefully, a clear explanation.
Keep up the good work
cool tips!
Nice!!
Great❤
what if the get function depends on a condition like If? is still a good idea to have in process? btw what if use get_mouse_position, i can't put it on _Ready right?
Only if it is a check happening right at the start. If you cant put it in there, try to think about if there are any signals that might work to trigger it, maybe you dont need the process/physics_process function to run at all times and can turn it on and off.
At the end of the day as the developer, if you can't find a way to work around it, and you feel like you have no choice but to put it in, then sure do it. Just try to avoid it whenever possible and try to think of better solutions so that we bog down our frames with the least amount of things.
Godot creator: Don't use object pooling.
First tip in the video: use object pooling.
Scene/node freeing is fast in godot such as Juan has stated in his tweet is true. Just as the majority of users wont be creating and destroying say 10,000+ objects in a single frame. There is a ceiling to this as to when you will hit performance issues. You may be able to go your whole time with godot and never need it, depending on the games you make. But if you ever do hit this ceiling, object pooling will factually significantly increase this performance ceiling. And if you somehow hit the ceiling here, you can use the servers(audio, rendering, and physics) to further increase performance.
So when Juan says you don't NEED object pooling, for most people in most situations, especially brand new users this is completely true.
1) what
Not bad tips per se but really work on how you present that information. I know every start is tough but my feedback is that this video could've been 5 minutes and still be more informative. The first tip is the worst offender here as not only did you stumble your words and constantly repeat your point but you didn't even give a proper example on how to perform this, which would justify the length you go over this tip somewhat.
Again no hate, just brutally honest feedback.
I'll begin by emphasizing that I truly value all feedback, whether it's positive or critical in nature.
At times, I've noticed that I tend to repeat myself. I've been actively working on addressing this issue, and I've seen significant improvement. I believe this tendency may stem from my prior experiences in instructing others on certain topics, only for them to disregard my advice shortly thereafter. It's akin to players skipping a tutorial and then complaining about not knowing how to perform certain actions. Nevertheless, it's a valid criticism that I'm actively addressing.
Regarding the length of my content, I've encountered a wide range of opinions over time. It's interesting how, on occasion, when I create longer videos, some viewers express a desire for brevity, while others argue that I should delve deeper into certain subjects. Conversely, when I make shorter videos, some suggest I should provide more explanations or expand on specific topics. This situation raises important questions, such as: How much attention should I allocate to X compared to Y? How deep should I delve into these topics?