19 September 2021, 18:36 | #1 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
Data format for "16bpp indexed" (?)
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" Code:
// 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 }; 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) Code:
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 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. Last edited by chadderack; 19 September 2021 at 19:01. |
20 September 2021, 00:06 | #2 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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. |
21 September 2021, 22:07 | #3 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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.
|
22 September 2021, 19:50 | #4 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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 |
23 September 2021, 04:38 | #5 |
Zone Friend
Join Date: Mar 2004
Location: Middle Earth
Age: 40
Posts: 2,130
|
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? |
23 September 2021, 13:52 | #6 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"Diabolik" & "Dylan Dog" & "Tex" & "Time Runners" series | DamienD | request.Old Rare Games | 20 | 21 July 2022 16:58 |
"Voices8" 8 Channel Soundtracker "DemoSongI" song - "This is the Amiga with 8 Voices" | DemosongIHunter | request.Music | 45 | 23 May 2022 20:07 |
"Data Cache Emulation" configuration not saved(?) | oRBIT | support.WinUAE | 5 | 30 March 2019 19:01 |
Code / data / tools of Scoopex "TWO" (rotozoom cracktro for Starquake) | Yragael | Coders. Tutorials | 4 | 24 November 2018 10:44 |
Data Becker "Multi Paint" (1992) | 1988 | request.Apps | 5 | 28 July 2015 08:01 |
|
|