@jacksonmj (View Post)

Second, partsPosData. For each coordinate, it stores the number of particles in that position. It contains three bytes for each coordinate. So for a save the size of the entire screen, this is 612*384*3 = 705024 bytes. However, since this is typically 0 or 1 for the majority of positions in most saves, the entropy is low and it compresses well. If storing positions or particle indexes, these have a much larger range of values and much higher entropy, so don't compress so well.

My idea is: change things here. For example, I have particle #0 at (123,456), calculate like below:

y*XRES+x

XRES=612

so (123,456)=75732

particle #1 at (321,123) = 196575

particle #2 at (0, 0)=0

Store the relative number of two particles. On this example, it stores 75732, 196575-75732=120843, 0-120843+235008=114165. If some particles are erased then just store 'none' for type. Usually the particles are made with Ctrl tool, the entropy is still low and can be compressed easily.

For example, if you draw a calculator, there is an ALU in that calculator. People always copies the ALU, so it still has a loop (1, 1, 1, 612, 1, 1, 1, 612, ..., 1, 1, 1, xxx) so the entropy is low