Should we rework the block data storing
Salodo opened this issue · comments
When I was looking at the code I notices you are storing the values using a dictionary where the key is the position. This method is great except, when looking at the other Issues like Issue #6 where you want to place different blocks based on height in the colum. And Issue #7 and #16 where you discuss about using chunks to optimize drawing and generating infinite terrain.
I dont think the way tiles are stored should change, because for most generations the current system is perfect. but when I look at the code I see alot of instances where the grid is directly acceses, which should rather be though a set_block and get_block variable, that way you could exchange the ways blocks are stored to suite the generation type.
I suggest using an oct tree but its 2d so its actually a quad tree, to store data. Then you could use a simple algorithm to get the top most block of each colum. A octree is great for storing limited sized worlds, but not great for infinite sized worlds. But that is where the dictionary method comes in, at a certain point when one octree has too mutch depth, then you can split the oct trees up into dictionaries of oct trees whith a maximum of 4 octrees in memory to make it look seemless. And then loading and unloading as needed.
This sounds interesting. I'll have to look more into it when I can since I'm not familiar with quad trees, but if it helps with optimization (main problem rn) when drawing it'd be great.
I don't think this is no longer necessary, closing.