is presently its sole maintainer,
You can support him:
Recap on getting initial usage code down to avoid bad design
Design constraints for high/low frequency entities
Float precision problem for large worlds
Problem of scaling to large entity counts
Realizing the problem - wrong way to think about low frequency entities
Realizing the solution - simulation regions
Handling entities moving outside boundaries of simulation region
Starting the code reorganization
The sim_region struct
How to alter SetCamera
Ending simulation by mapping entities in a sim_region into low space
Beginning simulation by mapping entities into a sim_region
Simplifying entity structs
More details on BeginSim
Adding an entity to a sim_region
Switching from camera space positions to simulation space positions
Adjusting the entity structs
Memory allocation for sim_regions
Storing back to low entities in EndSim
Deleting code that is no longer applicable
Replacing SetCamera with getting a sim_region in the main loop
Moving camera position update from main loop to EndSim
Adjusting rendering for simulation regions
Wrapping up for today - fixing compiler errors
Recommendation for names - instead of stored entities you could have stasis_entity and stasis_region; for the high frequency, you would keep the sim_region and sim_entity.
Since we know that an entity's speed is bounded, couldn't we calculate a sim_region with bounds such that no entity can move outside of it during the frame? That way anything that the entity could collide with would be pulled into the sim_region?
How many TODOs do you have?
How will you handle the disparity in update rate between offscreen and onscreen entities? Does it matter?
Will the sim_region away from the player cause large timesteps from the normal?
I missed whether this new system is based around discrete rooms or integer mapped coordinates. If it's based on rooms, would it be trivial to think in coords instead?
What will happen if your sim_region and player location are at the same place? Will it bug out?
Why is the low-high frequency system so important? Isn't creating basic gameplay rules and AI interactions in a small world more in-line with your philosophy of doing the simple thing first?
How will we update low frequency regions given the sparse nature of the world?
Is there a major advantage to using 'fors' instead of 'whiles'?
What will the entities that are not visible on the screen be doing? I can't really think of examples of things that need to be updated if they're far from the player.
How many low entities does it take to screw in a light bulb?
For your sparse storage, why not store the (x,y,z) coords bit-shifted into an aligned integer to use it as a composite key into a dictionary or hash map?
Do you approach design in a similar way to your architecture (i.e. exploration-based design, design sort of emerges itself organically, etc.)?
Is multi-threading in the scope of topics for the project?
If a far away room gets updated and the rooms around it are updated too, don't we have this recursive problem where the around rooms need their neighbor too?
How much work would it take to turn the game you are making from a 2D world into a 3D world?
To clarify my early design question, I just mean as far as your design decisions for Handmade Hero.