Quest for a 32bit FPG Format

[MikeDX]

Hello Bennu users!

Now that DIV is becoming stable, it is time to open up to 32bit graphics.

For this, I will require a new FPG format. Now I have a couple of options. First is to design a new format, based upon the original FPG8 format of DIV, or there is a possibility of adopting an existing 32bit format.

What would you think of DIV supporting bennu fpg natively? Or should DIV have its own format FPG.

Whatever I choose would be open, the format published and anyone would be allowed to use it (like the DIV 8bit FPG, FNT, MAP, etc). No problems at all.

So, let me know what you think!

[darío]

Having build several FPG-related tools this is what I think.

1. Everyone will be fine with DivDX supporting (originally Fenix) / BennuGD / PixTudio / DivGO 32bpp fpgs. I think people will mostly appreciate it rather than "be against it", me included.

2. If a new FPG format is to be created I would expect some improvements over the existing one. Removing parts of functionality that might not be useful or adding new functionality that can be useful. If the new FPG format is not going to bring any big benefit I do not think is worth the effort from a "practical perspective".

3. If there is a motivation for a new FPG format is okey, but why not give also support to current 32bpp format? It is just the "natural extension" of DIVs format, so what already exist would fit in DIV's concepts and the FPG editor of DIV can continue to work in the same fashion.

Now, if a new format is to be created these are some thinks I would like you to consider:

- Making sure the magic numer does not match Fenix format. Ideally it is also different from DIV's 8bpp format so as not to break current editors compatibility.

- Remove useless information such as the 12 chars field in each map that was originally used to store the "original location of the file"

- Adding perhaps a count field to avoid having to read the whole file in order to know how many graphs there are in the FPG.

- Perhaps, make it possible to create a table of "string keys" where it is possible to retrieve graphics not by their position but by a "name"?

Some other ideas:
- Instead of creating a new Format, give support to Fenix 32bpp one. However, create a new set of functionality to be able to load "texture-atlas" such as the ones used by other game programming frameworks and tools (for example, texturepacker).

Hope it helps.

[SplinterGU]

you can use bennugd fpg format, no problem for it...

dario, texture-atlas was the first feature in bennugd2. :)

[darío]

Great, I start to get tired of creating specific tools to specific file formats! :)

[Drumpi]

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 :D :D :D (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.

Dario:

- 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.