This is awesome! Found your video on the Godot subreddit and really enjoyed it. Splitting the lighting and the chunking calculations into separate frames was a simple, cool idea for fixing the stuttering. Best of luck with Miner's Delight!
2:48 Id recommend using Minecrafts method of lighting. Based on world position and light diffusion based on the defuse strength of a given block. For example -The world lights highest value is 12 for example -An Empty block has a diffusion of 0. -Glass also has a diffusion of 0 tinted glass up to 4 -Dirt, Rocks, etc has a diffusion on 5 -Each block subtracts from the total light highest value but clamp it to 0 as the lowest possible value. Ad shade the block accordingly. -Empty space block below the dirt could be set to 1+(current light value) -So 3 dirt blocks deep would cause darkness. But you only update it in ticks or when a change occurs i.e break a block (signals could be used here) Easier said than done maybe lol
The fun part is going to be seeing how you tackle moving objects that need to persist outside of the screen, when there's no scene for them to exist in. :)
I had the stutter when loading up chunks as well for my project, I ended up just going for fairly small chunks that loaded quickly but making a c++ script is probably gonna be better in the long run it sounds.
Hi. While a compiled language like C++ is always better. When your code triggers a recursive black hole, there is usually a better solution than to seek more performance. What your shader code might need is normalization of some values. When values get close to zero the computations start to take longer and longer, while there is no significant effect to the outcome. The trick is to set values close to zero to zero. In this case you probably need to test the value for the amount of light a object reflects. When the amount of light reflected drops under a threshold you can either set it to zero or just don't do the next recursive call. This way instead of thousands of recursive calls you can limit them to just a hand full. The same principle holds for e.g. physics and audio calculations, values close to zero don't matter. Set them to 0 and save a ton of computing time. BTW Values approaching a limit can often be treated in a similar way. For example if a value can't be larger than 1. Then a*1 is faster than a*0,99999999999999999. Happy coding.
Thanks for the advice! I definitely agree with you, and after looking at my lighting code again it seems like the recursion wasnt the issue per say. I have a cutoff for the recursion of depth 6 so there isnt a recursive black hole. I think the issue comes from calling the recursive functions on several thousands of separates tiles which adds up, Im still looking for a way to optimize this. But i definitely think your advice is helpful!
Nice project I would like to see more of the combat side. One thing, the players sprite is in the ground and when standing still his one foot is bending to the side(not saying it is bad I just dont really like the looks of a crippled foot)
Hey really nice game you have there, and some really smart fixes for the lags! I am wondering how did you aproach splitting the calculations in 2 separates frames, do you use bools that close and open parts of the function and call it on _process and at the end you deactivate them? Haha how did you do it?
Yeah, my code works something like this: var counter = 0 func _process(): match counter: Case 1: func1() Case 2: func2() counter = (counter + 1) % num_parts
Im just using one tilemap node right now, but i think instancing separate tilemap nodes would be better from a performance standpoint. I might do that later on.
This is awesome! Found your video on the Godot subreddit and really enjoyed it. Splitting the lighting and the chunking calculations into separate frames was a simple, cool idea for fixing the stuttering. Best of luck with Miner's Delight!
Thank you! Appreciate it!
2:48 Id recommend using Minecrafts method of lighting. Based on world position and light diffusion based on the defuse strength of a given block.
For example
-The world lights highest value is 12 for example
-An Empty block has a diffusion of 0.
-Glass also has a diffusion of 0 tinted glass up to 4
-Dirt, Rocks, etc has a diffusion on 5
-Each block subtracts from the total light highest value but clamp it to 0 as the lowest possible value. Ad shade the block accordingly.
-Empty space block below the dirt could be set to 1+(current light value)
-So 3 dirt blocks deep would cause darkness. But you only update it in ticks or when a change occurs i.e break a block (signals could be used here)
Easier said than done maybe lol
Sorry jumping the gun. Paused the video to type. I didnt realized you used C++ instead😅
1:14 Thats Taboo to dig down in any game even your own😂
looks cool, ill definetly have to follow this!
Yay I hope you enjoy the following devlogs! :D
this looking great man!
Thank you!
Quality slurp noises 👌
I tried my best! :)
The fun part is going to be seeing how you tackle moving objects that need to persist outside of the screen, when there's no scene for them to exist in. :)
Yup thats going to be a bit tricky, hopefully i can find a way. By the way i look forward to playing Cloudscape!
Epic devlog!
Thanks! Hope you enjoy the next devlog as well!
Hi, love the game. Could you please make a tutorial on how to make a 4 directional character with customization ? Thanks!
I had the stutter when loading up chunks as well for my project, I ended up just going for fairly small chunks that loaded quickly but making a c++ script is probably gonna be better in the long run it sounds.
Hi. While a compiled language like C++ is always better. When your code triggers a recursive black hole, there is usually a better solution than to seek more performance.
What your shader code might need is normalization of some values. When values get close to zero the computations start to take longer and longer, while there is no significant effect to the outcome. The trick is to set values close to zero to zero.
In this case you probably need to test the value for the amount of light a object reflects. When the amount of light reflected drops under a threshold you can either set it to zero or just don't do the next recursive call. This way instead of thousands of recursive calls you can limit them to just a hand full.
The same principle holds for e.g. physics and audio calculations, values close to zero don't matter. Set them to 0 and save a ton of computing time.
BTW Values approaching a limit can often be treated in a similar way. For example if a value can't be larger than 1. Then a*1 is faster than a*0,99999999999999999.
Happy coding.
Thanks for the advice! I definitely agree with you, and after looking at my lighting code again it seems like the recursion wasnt the issue per say. I have a cutoff for the recursion of depth 6 so there isnt a recursive black hole. I think the issue comes from calling the recursive functions on several thousands of separates tiles which adds up, Im still looking for a way to optimize this. But i definitely think your advice is helpful!
Nice project I would like to see more of the combat side. One thing, the players sprite is in the ground and when standing still his one foot is bending to the side(not saying it is bad I just dont really like the looks of a crippled foot)
Thanks for the feedback! I'll get around to updating the sprites
Hey really nice game you have there, and some really smart fixes for the lags! I am wondering how did you aproach splitting the calculations in 2 separates frames, do you use bools that close and open parts of the function and call it on _process and at the end you deactivate them? Haha how did you do it?
Yeah, my code works something like this:
var counter = 0
func _process():
match counter:
Case 1:
func1()
Case 2:
func2()
counter = (counter + 1) % num_parts
godot exbert!
Looks nice! Did you instanced a TileMap-node for each chunk or is your chunk-system reloading the same TileMap all the time?
Im just using one tilemap node right now, but i think instancing separate tilemap nodes would be better from a performance standpoint. I might do that later on.
I have terraria