Talk:BSAVE Header

NeoTA (talk) : I just realized when browsing the link I just added here -- map data uses BSAVE header, but it can exceed 32767 bytes in size (it notes that there is a 'maximum of 100000 tiles per layer'). What happens there, when the BSAVEd array is larger than can be described in the size field (at best, 65536 bytes.)?

...

NeoTA (talk) : I just tested it, and the answer is 'strange happens'. Instead of any sort of sane header, we get 7 0-bytes which describe precisely nothing about the remaining data. O_o

Actually, no, that's just what the map handling does... and it does it even if the total data size is <32767 bytes. So saying the map lumps have a BSAVE header is somewhat misleading.. They probably did once, buut...

The Mad Cacti (talk): I think tilemap lumps are actually the only place where the BSAVE header contains anything truly useful: for very old games the T lumps are always 32007 bytes long. (But we don't make use of that, leading to phantom map layers because number of map layers is determined only by lump size! Bug I mean to fix.) The header on new T lumps is actually garbage, not necessarily zero bytes.

In a number of places (according to grep, only GEN, FNT, MAS, PAL (and DOR when upgrading 1999 format games)) we still read the BSAVE header including the length, and write BSAVE headers that look like QBASIC ones. But those are all unnecessary and might be replaced with garbage, as has happened to all the other lumps previously with BSAVE headers as loading/saving code gets rewritten.

I'll update.