TODAY I: booted into my linux partition for the first time in like three months (well excepting that one other time i did it) and fixed up some of my rhombic game code.
SPECIFICALLY i made the async chunk loading code a little more functional -- before i had just hardcoded it to try and load up the chunks 0 0 0/1 1 1 inclusive and then stop, which was okay for the kind of testing i was doing but not really, uh, effective for actually walking around. so i hooked it up to keep a list of the chunks within three grid units of the player and add/remove/resort them as the player moved, so it's now at least trying to keep a loaded buffer around the player. it's still pretty arbitrary about which of those chunks it's going to load (i'm just sorting by manhattan distance, so it'll load {anything one unit away}, and then {anything two units away} and then {anything three units away}. maybe i should just go w/ straight-up summing the difference; i don't really want a load volume that's a weird diamond but that's probably preferable to it loading corners) and it will never unload any chunks (though it will give up on trying to load a chunk if you move far enough away) so this is only slightly better.
also it takes like ~20seconds to load a chunk, and i have no clue why. i'm assuming half of it is my slow geometry code and the other half is, like, haskell copying the entire map data structure over so the loading thread can mutate it or w/e; i have no clue how the async library practically works.
(i also spent a few hours today trying to assemble a minecraft modpack while the absurdity of wrangling other peoples' code to play a game i didn't really even like when if the actual goal was "assemble a collection of game interactions that expresses this thing in yr head" then that would be much better-served by working on my own game steadily increased)
SPECIFICALLY i made the async chunk loading code a little more functional -- before i had just hardcoded it to try and load up the chunks 0 0 0/1 1 1 inclusive and then stop, which was okay for the kind of testing i was doing but not really, uh, effective for actually walking around. so i hooked it up to keep a list of the chunks within three grid units of the player and add/remove/resort them as the player moved, so it's now at least trying to keep a loaded buffer around the player. it's still pretty arbitrary about which of those chunks it's going to load (i'm just sorting by manhattan distance, so it'll load {anything one unit away}, and then {anything two units away} and then {anything three units away}. maybe i should just go w/ straight-up summing the difference; i don't really want a load volume that's a weird diamond but that's probably preferable to it loading corners) and it will never unload any chunks (though it will give up on trying to load a chunk if you move far enough away) so this is only slightly better.
also it takes like ~20seconds to load a chunk, and i have no clue why. i'm assuming half of it is my slow geometry code and the other half is, like, haskell copying the entire map data structure over so the loading thread can mutate it or w/e; i have no clue how the async library practically works.
(i also spent a few hours today trying to assemble a minecraft modpack while the absurdity of wrangling other peoples' code to play a game i didn't really even like when if the actual goal was "assemble a collection of game interactions that expresses this thing in yr head" then that would be much better-served by working on my own game steadily increased)
