Modify Chunk Loading to Support Significantly Larger World Sizes#54
Modify Chunk Loading to Support Significantly Larger World Sizes#54Digitalfear117 wants to merge 1 commit intosmartcmd:mainfrom
Conversation
|
I'm worried about the concurrency problems this may cause. Needs deep testing? |
|
That's fair, and honestly there is still more work to be done here to make this truly useful. Mostly just wanted to get this out there since I have been working on this for like the past 15 hours lol. However it does work. I think it's time for me to get some sleep though |
|
i tested a bunch of forks merged together the more chunk patch pr (default is 32727 max coords x or z) has a bug ig i was flying from 0, 0 to the world border without closing and the more i traveled the more the debug screen (the f3 one that shows version and structure like stronghold location) when i opened it was lagging eventually making me have 3 fps when opened. |
|
Thanks. This is why we should test stuff before merging. |
Pull Request
Description
Allows for significantly larger world sizes by decoupling render list allocation from total world size.
Previously, increasing the world size caused the renderer to reserve command/display list storage for every possible chunk position in the world, even if most of those chunks would never be active at the same time.
Changes
Previous Behavior
The renderer used a fixed mapping between a chunk’s global index and its render list storage. Even though only a limited number of chunks can actually be rendered around the player at once, the engine still reserved render resources for the entire possible world footprint.
Root Cause
The rendering resources were allocated based on maximum possible world size, not active chunk usage.
New Behavior
Render list storage is now allocated dynamically for active chunks and released when those chunks are no longer referenced. This allows world size to scale much further without requiring render resources to scale with the full world bounds.
Fix Implementation
Replaced the fixed global render list mapping with a dynamic allocation model. Active chunks now acquire render list storage on demand and release it when no longer referenced.
I have set the current limit to 32*64 but feel free to try larger values. Just note that the game may use a lot of ram if you set it to something crazy like 512x64 lol