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
@African-AmericanGoose2 күн бұрын
And 2D ? you have some tips ?
@Yogoda127Күн бұрын
@@African-AmericanGoose Sorry, I only do 3D 😁
@mr.hi_vevo4142 ай бұрын
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
@Csf912 ай бұрын
Try to cache objects and enemies that spawn into memory to re-use the memory space instead of creating and destroying objects, too.
@SSukram_2 ай бұрын
How would you do this?
@hk_asa0pvp2 ай бұрын
@@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.
@igorthelightАй бұрын
@@SSukram_ Google "object pooling in Godot/Unity/Unreal Engine"
@rremnarАй бұрын
@@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.
@fragileglass96222 ай бұрын
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.
@iLgaming33411 күн бұрын
Good work out there, soldier
@moonstonewarlockАй бұрын
Great video! Thanks! 😎
@JackBasciono2 ай бұрын
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
@VenexSource2 ай бұрын
Thanks for the tips!
@TheEshanDas2 ай бұрын
These are very good tips atleast for a beginner like me. Amazing work
@rremnarАй бұрын
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.
@DestusG2 ай бұрын
I saw our game 😅
@slavcabbage26192 ай бұрын
Really nice tips I will definitely be using these
@VenexSource2 ай бұрын
Glad you like them!
@thehansboi2 ай бұрын
why is tip #3 so quiet lmao, rest of the video felt like i was listening to someone underwater lol
@ClokworkGremlin2 ай бұрын
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.
@jammjumble99282 ай бұрын
really nice tips!
@FruitZeus2 ай бұрын
I saw there’s also a visibility occluder 3D node. How is this different than regular occlusion culling?
@HansMilling2 ай бұрын
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.
@Gnidel2 ай бұрын
Just leave it up to user whenever to use it or not.
@ObsydianX22 күн бұрын
Yeah, I have to use VSync when testing my game or it’ll run at 300+ FPS and turn my fans into launch thrusters.
@eobet22 сағат бұрын
Visibility notifier? Godot doesn’t have frustrum culling by default?
@mystiogan58912 ай бұрын
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.
@Flux0_0-u2d2 ай бұрын
You can use godot physics server
@SamFX2 ай бұрын
Very good tips
@davidkurosaki84572 ай бұрын
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
@hokokotokokoto70822 ай бұрын
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 ?
@kleinesmaddy2 ай бұрын
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.
@thisisgod2639Ай бұрын
@@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
@kleinesmaddyАй бұрын
@@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.
@kleinesmaddyАй бұрын
@@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.
@kleinesmaddyАй бұрын
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. ;-)
@grimreaper85812 ай бұрын
I didn't watch the video yet but very cool keep going
@jonpatchmodular21 күн бұрын
Ahhahah yes 54fps... I think you dropped the decimal point there... T_T help
@andrekoscianski2 ай бұрын
👍
@MoiCestVinci25 күн бұрын
Now it's a WokeDot engine can we use a fork, maybe Redot game engine.
@charlieking76002 ай бұрын
So you're retelling official documentation. Nothing new at all.
@SSukram_2 ай бұрын
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
@bojaidin2 ай бұрын
Who cares? Some people learn better by watching/listening to videos than they do just reading
@SSukram_2 ай бұрын
@@charlieking7600 also some people have vision impairments or things like dyslexia, which may make it hard to read
@바오-c3pАй бұрын
?? Then is there anything he can tell if it's not included in documentation?