For 3D: - Split big geometry objects into large chunks so only visible chunks are drawn, the rest is automatically culled by the engine. - Use level of detail (LOD) for objects with a lot of geometry - Deactivate enemies that are far away from the player with process_mode = Node.PROCESS_MODE_DISABLED
What have you found to be the best way to determine if the enemy is far away from the player? Constantly subtracting global positions? In area 3D that follows the player?
@@zacharykirby7543 Maybe using the physics engine could work, but I calculate the distance to the player with Vector3.distance_squared_to, not each frame but each second or so. You can even make the script run in a parallel thread with the node thread group options.
Even as a seasoned developer. Always room to grow. I had no idea about the visibility onscreen notifier. Thank you for unearthing that little gem for me.
@@SSukram_ it would be like hiding a node with visible = false and later visible = true. rather than instancing and adding then freeing it i guess correct me if I'm wrong.
@@hk_asa0pvp I've heard of doing this for bullet hell games. That you don't want to free and rebuild bullets, but reuse the ones that were made. Though this does cause hitching. So you may need to preload these on scene load.
Your video is incredibly high quality, with concise and easy to understand content, great examples, no annoying intro or outro, and animations, BUT it's really held back by your mic quality. People often click off of videos immediately after hearing videos with bad mic quality, but thankfully that's one of the easiest things to fix, so long as cost isn't an issue. It's much harder to fix writing quality than mic quality. You deserve far more views, so I hope you can get there soon! Keep up the good work
You should really be using type hinting whenever possible (that's "always") in Godot. For basically the reasons listed. Static typing is one of the most powerful tools in a programmer's tool belt for preventing runtime bugs.
A few other things that should be optimized is animations and shaders. Animations, if not required to keep runnin for game specific purposes, can be stopped client side, when it is out of view. Shaders shouldn't be calculated when out of view. I think that is why some games cause the GPU to be very hot, because they are all being calculated for the whole scene.
very nice, but i need to implement these on my own graphics engine :) for now i have static redering and dynamic rendering, it's to hard to implement everything a keep the project with a good struct, i applied the adapter pattern to my GUI, using a buffered image for static rendering, then for the dynamic camara rendering i am getting stuck ...
when making a 3d game, Lod or level of detail can help a lot. by making your own low poly models or with an i engine setting i believe, but i'm not sure.
Static typing does not improve performance in any way because the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution.
@@kleinesmaddy Actually no. Static typing sets the exact bytecode in the binary file to be read by the engine instead of interpreting and producing it during runtime. This can save some, for example, in a for loop like this: for i in range(100): var v := foo(i) The engine won't have to guess v's type every time that line executes because it's already predefined
@@thisisgod2639 While I appreciate your perspective, I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution. To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used. In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process. In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported.
@@thisisgod2639 While I appreciate your perspective, I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution. To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used. In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process. In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported.
I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution. To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used. In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process. In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported. P.S. Just because my comment keeps getting deleted doesn’t make a false statement true. ;-)
Can you help me with this mechanic in a video it's for a farm game One has 4 gardens before planting you must put the fertilizer and then the plant, and to start generating points or grow, you have to put water, for example in 3 hours that plant produces 1000 points but it must be watered every 1 hour, because the soil dries while it is dry it does not generate points the points freeze but the hours continue advancing, then in the end instead of 1000 points you will have less example 300. Please could you make a video please Of course one would buy with those same points the fertilizer the plant, among other things
There is something new, a video with visuals, that explains each point in a clear and concise way. Literally all educational stuff online is based on existing research and documentation etc. Just because you are a godot veteran doesn't mean everybody is, some people out there don't read the docs in their spare time
For 3D:
- Split big geometry objects into large chunks so only visible chunks are drawn, the rest is automatically culled by the engine.
- Use level of detail (LOD) for objects with a lot of geometry
- Deactivate enemies that are far away from the player with process_mode = Node.PROCESS_MODE_DISABLED
And 2D ? you have some tips ?
@@The_BlackGoose Sorry, I only do 3D 😁
What have you found to be the best way to determine if the enemy is far away from the player? Constantly subtracting global positions? In area 3D that follows the player?
@@zacharykirby7543 Maybe using the physics engine could work, but I calculate the distance to the player with Vector3.distance_squared_to, not each frame but each second or so. You can even make the script run in a parallel thread with the node thread group options.
Подскажите пожалуйста как генерить lod-ы для геометрии из obj файлов?
Even as a seasoned developer. Always room to grow. I had no idea about the visibility onscreen notifier. Thank you for unearthing that little gem for me.
Try to cache objects and enemies that spawn into memory to re-use the memory space instead of creating and destroying objects, too.
How would you do this?
@@SSukram_ it would be like hiding a node with visible = false and later visible = true.
rather than instancing and adding then freeing it i guess correct me if I'm wrong.
@@SSukram_ Google "object pooling in Godot/Unity/Unreal Engine"
@@hk_asa0pvp I've heard of doing this for bullet hell games. That you don't want to free and rebuild bullets, but reuse the ones that were made. Though this does cause hitching. So you may need to preload these on scene load.
Your video is incredibly high quality, with concise and easy to understand content, great examples, no annoying intro or outro, and animations, BUT it's really held back by your mic quality. People often click off of videos immediately after hearing videos with bad mic quality, but thankfully that's one of the easiest things to fix, so long as cost isn't an issue. It's much harder to fix writing quality than mic quality.
You deserve far more views, so I hope you can get there soon! Keep up the good work
I saw our game 😅
Great video! Thanks! 😎
Good work out there, soldier
Quick and effective, and I’ve learned new things ! Thanks dude
really nice tips!
I saw there’s also a visibility occluder 3D node. How is this different than regular occlusion culling?
These are very good tips atleast for a beginner like me. Amazing work
Really nice tips I will definitely be using these
Glad you like them!
why is tip #3 so quiet lmao, rest of the video felt like i was listening to someone underwater lol
You should really be using type hinting whenever possible (that's "always") in Godot. For basically the reasons listed. Static typing is one of the most powerful tools in a programmer's tool belt for preventing runtime bugs.
Improve your mic quality and add quiet music in the background. Will make this more watchable, however, in terms of content: Good stuff, very useful
Thanks for the tips!
A few other things that should be optimized is animations and shaders. Animations, if not required to keep runnin for game specific purposes, can be stopped client side, when it is out of view. Shaders shouldn't be calculated when out of view. I think that is why some games cause the GPU to be very hot, because they are all being calculated for the whole scene.
very nice, but i need to implement these on my own graphics engine :)
for now i have static redering and dynamic rendering, it's to hard to implement everything a keep the project with a good struct, i applied the adapter pattern to my GUI, using a buffered image for static rendering, then for the dynamic camara rendering i am getting stuck ...
is the black dude in yellow from tinto brass movie?
Remember that disabling VSYNC makes your game very power hungry, so it’s a big no no on steamdeck, phones and other battery powered devices.
Just leave it up to user whenever to use it or not.
Yeah, I have to use VSync when testing my game or it’ll run at 300+ FPS and turn my fans into launch thrusters.
@@ObsydianX Clean your pc
You can use godot physics server
baked lighting ⛔
baked lightning ✅
Very good tips
when making a 3d game, Lod or level of detail can help a lot. by making your own low poly models or with an i engine setting i believe, but i'm not sure.
Visibility notifier? Godot doesn’t have frustrum culling by default?
It has, ignore this tip. You dont need it in 4.x anymore
static typing over dynamic typing i see how it could boost perf in editor but does it make a difference once you export the game ?
Static typing does not improve performance in any way because the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution.
@@kleinesmaddy Actually no. Static typing sets the exact bytecode in the binary file to be read by the engine instead of interpreting and producing it during runtime. This can save some, for example, in a for loop like this:
for i in range(100):
var v := foo(i)
The engine won't have to guess v's type every time that line executes because it's already predefined
@@thisisgod2639 While I appreciate your perspective, I believe there's a misunderstanding regarding the role of static typing in performance optimization.
As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution.
To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early.
However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used.
In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game.
The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process.
In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported.
@@thisisgod2639 While I appreciate your perspective, I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution.
To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used.
In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process.
In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported.
I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution.
To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used.
In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process.
In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported.
P.S. Just because my comment keeps getting deleted doesn’t make a false statement true. ;-)
I didn't watch the video yet but very cool keep going
Can you help me with this mechanic in a video it's for a farm game
One has 4 gardens before planting you must put the fertilizer and then the plant, and to start generating points or grow, you have to put water, for example in 3 hours that plant produces 1000 points but it must be watered every 1 hour, because the soil dries while it is dry it does not generate points the points freeze but the hours continue advancing, then in the end instead of 1000 points you will have less example 300. Please could you make a video please
Of course one would buy with those same points the fertilizer the plant, among other things
👍
it's called refactoring not cleaning, but ok
Ahhahah yes 54fps... I think you dropped the decimal point there... T_T help
Now it's a WokeDot engine can we use a fork, maybe Redot game engine.
So you're retelling official documentation. Nothing new at all.
There is something new, a video with visuals, that explains each point in a clear and concise way. Literally all educational stuff online is based on existing research and documentation etc. Just because you are a godot veteran doesn't mean everybody is, some people out there don't read the docs in their spare time
Who cares? Some people learn better by watching/listening to videos than they do just reading
@@charlieking7600 also some people have vision impairments or things like dyslexia, which may make it hard to read
?? Then is there anything he can tell if it's not included in documentation?