There are slight differences between Fenix 16bits FPG format and DIV 8bits format. If I remember them OK, DIV format especifies it's bpp in a header field, while Fenix do it in magic number.
So, we really need a new format? If so, it will not be so different as the Fenix/Bennu, and maybe we can have tools if someone recode them a little... But that's the problem, if "someone" do it
(It's hard to find volunteers).
I don't think we need a new format, unless you want the users use the built-in utility to make graphics.
- The 12 chars data was added to the format because it's used by DIV graphic editor to easily replace/refresh maps created from an FPG and to put them again in the same FPG. Can we use it? Maybe not... but it was 12 chars long only? That wasn't the graph filename?
- A count field probably is useless. FPG don't store maps with ID order, and they can skip some number (I have FPGs with graph 1, 2, 5, 6 and 10 only). You can count it manually, or maybe LOAD_FPG can get this value when reading the whole file, but I don't think it needs to be in the file.
- You can find by "name" if you want, but I don't think DIV internal code has something like "string keys" or hash, so the searching may be the same way if you do it by DIV code. I don't know.
- Texture atlas is a good idea. Div has it in the editor, but not in the main code. But as I said... somewhere, map_block_copy can do the trick, unless we are talking about sprites with different sizes or with autoadjust.