is presently its sole maintainer,
You can support him:
Fix typo in SetCamera
Recap of world coordinate wrapping problem & sparse world storage design
Introduction to hash tables
Handling hash collisions: External chaining
Handling hash collisions: Internal chaining
Replace tile chunk counts with a hash table
Creating the hash function
Looking up entries in the hash table and creating new entries in the table
Reviewing the code that has been written
Moving the world origin
Debugging missing entities
Why not center the world at 0,0,0 and use signed ints for the tile position? [code change]
Is a hash map essentially just a creatively shaped tile chunk? If that's the case could you preempt the hash function by contributing more bits from the Z coordinate as opposed to the X and Y for a towery map for example? Am I thinking about this right?
What do you think about, and do you ever do, “free” optimizations in early or late stage development such as […] and instead trying to fail as early as possible? Best case scenario you only did one comparision rather than four.
What sort of cookie is best for programming?
What do you think about splitting the hash map code from the tile code such that you can use hash map for other stuff later on?
You're not passing the arena to the hash lookup function.
Is the world going to be generated on the fly or at game startup?
Instead of chunks have you thought about spatial hashing? I'm considering it for my game to allow an open generated world but not confined to grid aligned tiles or fixed size objects.
What about using an octree for sparse style storage rather than a hash map?
Since you are using a memory arena for all allocations how will you handle dynamic amount of objects like enemies, particles, etc.?
Shouldn't the safe margin be INT32_MAX minus margin?
When will this little guy have feet?
Isn't the explanation where one letter points to the next letter until the end of the word?
I think you said that a hash table was just one of many ways to store the sparse data. Could you briefly mention one or a couple of the other methods?
Does starting at 0 cause a problem with the tile chunks since now we are using that as the uninitialized variable? [code change]
Shouldn't Chunk->TileChunkX=0 be Chunk->NextInHash->TileChunkX? [code change]
Will you write an analog function to malloc?
(follow-up) I see. I guess what I was thinking about was what the full 4Bn x 4Bn map would look like if you passed each index in the hash map the opposite way through the hash function. It seems like it doesn't matter in any case becafuse no matter what it's always going to be better than O(n) and most of the time it's O(1) with a tiny bit of performance cost to throw the coordinates through the function.
Most of your comments are notes and todos. Do you ever add section title comments to separate long blocks of code?
Do you see any value in adding unit tests for certain bits of this functionality?
Can you visualize the shape of the map so I can understand why a hash table is better than an array?
The randomized map only goes up and to the right at the moment. Is it good enough to catch bugs?
Will the renderer be a separate piece of code as like the platform player so that it can be substituted with something like OpenGL?