Even something as simple as RLE (run length encoding) is likely to cut the size by a factor of 5 or even 10. There are multiple compression schemes we can use to reduce the size of the chunks. Here’s the description of the current file format: It also means that every chunk has exactly the same size on disk, which is extremely important. This is very inefficient, but very fast, simple and error-resilient. At that point, the world is so far down it might never climb out again, no matter how good it is.Īs a result, one of my priority tasks for 2.3 is to change the world storage format to reduce world sizes.Ģ.2 and earlier use a naive format, where chunk data is stored verbatim – every block taking 32 bits. The result is worlds becoming unavailable and dropping down through the ranks, until Dropbox unblocks the account after a few days. This has always happened, but now, with worlds twice as large, it happens twice as often. They download many large worlds from Community Content and everything grinds to a painful halt.Īnother issue caused by large worlds is exceeding of Dropbox bandwidth limit for people who host their worlds for Community Content.
The problem is that many, many people are running out of space on their devices. In hindsight, this may have been a mistake. This is something I haven’t paid enough attention to.Īnother aggravating change I eventually relented on for 2.2 – after getting much feedback from you – was to increase of the maximum worlds limit on device from 20 to 30. The files have become huge – some larger worlds are reaching multiple gigabytes. In 2.2, the increase in height doubled it again. This doubled the size of the world files too. It’s this doubling effect that I want to focus on this post.īack in 2016 when releasing 1.29, I doubled the size of each block to use 32 bits. It also doubled the size of the world files. This was a long overdue change that allows you to build properly high structures. As you all know, 2.2 doubled the height of the world.
0 kommentar(er)
