Data format for "16bpp indexed" (?)

[chadderack]

Hi...

... so I'm beating my head on a rock over how MAME decodes graphics tiles for Black Tiger. The source says that the format of the gfx2 chip (holding the tiles) is "bitmap_ind16" or BITMAP_FORMAT_IND16.

from "bitmap.h"

// bitmap_format describes the various bitmap formats we use
enum bitmap_format
{
	BITMAP_FORMAT_INVALID = 0,      // invalid forma
	BITMAP_FORMAT_IND8,             // 8bpp indexed
	BITMAP_FORMAT_IND16,            // 16bpp indexed
	BITMAP_FORMAT_IND32,            // 32bpp indexed
	BITMAP_FORMAT_IND64,            // 64bpp indexed
	BITMAP_FORMAT_RGB32,            // 32bpp 8-8-8 RGB
	BITMAP_FORMAT_ARGB32,           // 32bpp 8-8-8-8 ARGB
	BITMAP_FORMAT_YUY16             // 16bpp 8-8 Y/Cb, Y/Cr in sequence
};

Near as I can figure that makes no sense, because if it is palettized (indexed) then it should be far less than 16bpp (more like 4bpp).

At any rate, the entire tile bitmap for Black Tiger has 800h (2048 decimal) total tiles of which any can be used to construct a tilemap in any level. The palette data is added later. The size of the entire tile bitmap is 40000h (or 262,144 bytes). This computes out to 80h bytes (128 bytes) per tile, 1024 bits per tile.... so a 16x16 pixel tile (with 256 pixels) should be represented by 4 bits per pixel.

That (to me) meant that each nybble in the raw data represented a palette index from 0x0 to 0xF... so "FF" would represent two pixels, each colored with the 0xF color from the current palette.

The raw data doesn't seem to agree.

What I don't understand when looking at the raw data is how it can represent what is in the tilemap (meaning... the bytes in the raw data don't seem to decode from 4bpp at all)

Look at the upper left tile (16x16 pixels) here and then look at the raw data.


palette... (indexed)

Palette "F" colors (selected) (BRG FORMAT!)
        BRG
 0x0: 0x111 
 0x1: 0x9FF 
 0x2: 0x7EC 
 0x3: 0x6DA 
 0x4: 0x5C8 
 0x5: 0x4A7 
 0x6: 0x486 
 0x7: 0x375 
 0x8: 0x164
 0x9: 0x353
 0xA: 0x143
 0xB: 0x111
 0xC: 0x111
 0xD: 0x111
 0xE: 0x111
 0xF: 0x011

raw data...


I thought about how it might be represented by only 40h (64 bytes), but it didn't work. It would require 2bpp, which only gives the possibility of 4 colors instead of 16.

I guess there's the possibility that the bytes for each bit plane are not packed together, and some of the rest of the tile data for that specific tile is at some offset.

Anyone have insights into this? Or maybe a good example of that file format? I assume it's widely used; otherwise, MAME's code bloat would be far worse than it is (to handle several implementations of a 16bpp indexed format).

Thanks for any hints!


ETA: I did consider that the entire bitmap was flipped upside-down (some implementations of bitmaps do this), and checked for that... but it didn't seem to be right, either.
And I guess I'm being very pedantic, because I could just grab the tiles as they are from MAME and stop complaining... but I want to understand the encode format.

[chadderack]

Might have to build a debug version of MAME to figure out what's going on here. The problem with pulling tile sets from MAME is that they aren't really correct in terms of the bits that are set sometimes.

What I mean is... the tile map can have any of 16 palettes applied to it, and when that happens, the pixels can change dramatically... there's no pixel representation in the raw data (far as I know) ... and it's hard to construct 16x16 tiles by hand just to check. (I've done that... it's tedious, prone to error, and so far I've gotten nowhere with it).

Going to have to punt on this, probably. Not sure how else to tackle it at this point. Hopefully inspiration will strike.

[chadderack]

Building MAME now. Takes a while, apparently. Almost through all 391 projects... no errors... CLANG/LLVM. We'll see. I'll post any results I get here, for completeness.

[chadderack]

I've built the MAME debug version and run it.
My results are in the post here

http://eab.abime.net/showpost.php?p=...&postcount=192

[redblade]

turaco_CL (turaco command line) is an old DOS/linux based arcade gfx format convertor from arcade gfx to PCX.

Before Turaco_CL there was turaco which was a DOS arcade gfx rom editor with an Amiga pointer, maybe use that program?

[chadderack]

Originally Posted by redblade

turaco_CL (turaco command line) is an old DOS/linux based arcade gfx format convertor from arcade gfx to PCX.

Before Turaco_CL there was turaco which was a DOS arcade gfx rom editor with an Amiga pointer, maybe use that program?

Cool, man. Thank you for the suggestion. I'll remember it in case I run into further issues. But it seems I've been able to solve the graphics format.