Grit - multi images, one palette?

[Quirky]

I posted about this to the gbadev forums but it didn't get much of a response. I think it may be better off here anyway. I'm trying for no response on 2 forums, then I'll post it as a patch to the sf.net patch tracker

I've been adding functionality to grit for converting several images but only generating a single (optimised) palette file. It is the one feature that I miss from gfx2gba. Grit's current behaviour is to create a 256-entry palette for each image. I realise that -pw or -pe can create smaller palettes, but that is no help in this case. The global palette option is if various images share some of their colours, not necessarily all, and there are up to 16 or 256 unique colours in total.

Here are the tech details.. The main design problem I've had has been that the current overall grit processing works something like this:

Code: Select all

for filename in filenames
{
  GRIT_REC record = new GRIT_REC(filename)
  process(record)
}

So the records don't know about their siblings and each one is destroyed after it generates its output. My change is to cache the records like this:

Code: Select all

vector<GRIT_REC> grv;
for filename in filenames
{
  GRIT_REC record = new GRIT_REC(filename)
  grv.push_back( record );
  process(record)
}

COLOR global_palette[256];
for record in grv
{
  for color in record.palette
  {
    if color not in global_palette
    {
      add_to_global_palette(color);
    }
    replace_index(old_palette_index, new_palette_index);
  }
}
output(global_palette);
output(records in grv);

So I add a copy of all the GRIT_REC items to a vector, then use the _pal_rec from each of these to create an optimised global palette. Finally, I re-index the _img_rec.data using the optimised palette indices instead of each image's own palette. Obviously if there are more than 16/256 unique colours there isn't much it can do - it just prints an error and creates a palette with the extra colours missing. This was how gfx2gba worked and is the least hassle all round - let the user optimise colours using pixel editing programs, but let the tool generate useful palette information. Finally, it outputs the tile data, doesn't add palette info for the tiles, and outputs a global palette file.

I'm working on an NDS example or 2 as well, so I can test typical use cases.

Does that make sense to anyone? Is this something that would be of interest to people? I know I've used this a lot in the past. Oh, and is anyone working on adding this type of thing already? Wouldn't want to duplicate work, but I am *almost* done with it now.

[WinterMute]

I'm not 100% sure but I think grit's batch mode does what you need. From the readme

Code: Select all

Special: batch bitmap->tilemap conversions. This is an example 
makefile rule for mapping and converting many bitmaps into a 
file with tilemaps and a shared tileset.
The following converts files a1.bmp a2.bmp and a3.bmp to regular 8bpp
tilemaps. The maps are stored into tilemap.s, WITHOUT the palette or 
tiles. The -fx option gathers the tileset into tiles.bmp, which is 
converted into a palette and tileset by the second command in the 
rule. 

[code]
GIT		:= grit.exe
BMPS	:= a1.bmp a2.bmp a3.bmp
TILESET	:= tiles.bmp

tilemap.s : $(BMPS)
	$(GIT) $^ -o $@ -fa -fx $(TILESET) -p! -g! -mR8
	$(GIT) $(TILESET) -o tileset.s

[/code]

[Thaumaturgus]

For the above code by WinterMute, are the maps from images a1.bmp, a2.bmp, and a3.bmp accessed in the *.s file by their original names (a1, a2, a3) even though the tilemap itself is shared and has its own name?