Temperatures are currently stored as a 16 bit int, except for values near room temperature which are stored as an 8 bit signed integer offset from room temperature. This means they are saved to a precision of 1 degree, and go from 0 to 65535. As far as I know, there are currently no floating point numbers in the save format.

It would be more difficult to load and store, especially since temperatures are not in their own array but are interleaved with field descriptors and all the other properties, which are stored using whole bytes. Also I suspect the bzip2 compression operates best when the bytes repeat rather than just the bits, but I haven't tested that.

The current save format is a balance between file size and being reasonably simple to read and write. For most saves, I think it gave around the same file size as the previous save format (PSv), the advantage was just being a lot easier to parse and to add extra data to.

If you enjoy experimenting with compression techniques, then yes, storing temperatures as 14 bit integers is something you could try. There are a number of other things you could try too, which might give bigger gains, such as:

• grouping the data by property then particle instead of by particle then property (on the basis that a property might have similar values in different particles)
• grouping property data (except type) by particle type (on the basis that particles of the same element might have similar property values)
• delta encoding
• Huffman coding (since if you're going to make life complicated by coding data in units that aren't a multiple of 8 bits long, you may as well use an efficient code to do it)

(Though note that changes need testing on a broad range of saves to make sure they reduce file sizes on average, rather than reducing just for a few saves and making the rest of them bigger.)