cinera_handmade.network/cmuratori/hero/code/code063.hmml

[video member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Simulation Regions" vod_platform=youtube id=a7_vSEEgArQ annotator=schme annotator=jpike]
[0:25][Recap on getting initial usage code down to avoid bad design]
[2:03][Design constraints for high/low frequency entities]
[4:46][Float precision problem for large worlds]
[8:21][Problem of scaling to large entity counts]
[10:06][Realizing the problem - wrong way to think about low frequency entities]
[11:18][Realizing the solution - simulation regions]
[16:18][Handling entities moving outside boundaries of simulation region]
[18:39][Starting the code reorganization]
[19:33][The sim_region struct]
[21:10][How to alter SetCamera]
[21:56][Ending simulation by mapping entities in a sim_region into low space]
[24:18][Beginning simulation by mapping entities into a sim_region]
[26:12][Simplifying entity structs]
[27:26][More details on BeginSim]
[29:11][Adding an entity to a sim_region]
[34:23][Switching from camera space positions to simulation space positions]
[38:02][Adjusting the entity structs]
[39:48][Memory allocation for sim_regions]
[42:45][Storing back to low entities in EndSim]
[45:45][Deleting code that is no longer applicable]
[48:53][Replacing SetCamera with getting a sim_region in the main loop]
[51:04][Moving camera position update from main loop to EndSim]
[51:48][Adjusting rendering for simulation regions]
[56:00][Wrapping up for today - fixing compiler errors]
[59:10][Q&A][:speech]
[59:46][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.]
[1:00:29][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?]
[1:02:29][How many TODOs do you have?]
[1:04:36][How will you handle the disparity in update rate between offscreen and onscreen entities?  Does it matter?]
[1:05:40][Will the sim_region away from the player cause large timesteps from the normal?]
[1:06:22][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?]
[1:06:44][What will happen if your sim_region and player location are at the same place?  Will it bug out?]
[1:08:11][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?]
[1:13:34][How will we update low frequency regions given the sparse nature of the world?]
[1:14:04][Is there a major advantage to using 'fors' instead of 'whiles'?]
[1:15:10][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.]
[1:17:33][How many low entities does it take to screw in a light bulb?]
[1:18:26][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?]
[1:20:01][Do you approach design in a similar way to your architecture (i.e. exploration-based design, design sort of emerges itself organically, etc.)?]
[1:20:24][Is multi-threading in the scope of topics for the project?]
[1:21:20][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?]
[1:22:29][How much work would it take to turn the game you are making from a 2D world into a 3D world?]
[1:23:07][To clarify my early design question, I just mean as far as your design decisions for Handmade Hero.]
[/video]