Author
currently trying to figure out what tile molesters indexedcolor actually does...
Quote from: TM Help file
indexedcolor
Description:
Defines a set of colors through a table of predefined RGB values (palette). When a color in this format needs to be rendered, it can be looked up in the table to find its corresponding RGB representation.
Attributes:
id - Unique identification string. [Req]
bpp - Bits per pixel. This value implicitly defines the size of the RGB lookup table; for example, if 6 bits per pixel are used, the table must hold 2^6=64 entries. [Req]
format - Refers to the id attribute of a defined directcolor format. The entries in the RGB lookup table are stored in this format.
endianness - The byte order of the RGB lookup table data (read on). Can be little or big; the former is default. [Opt]
Subtags:
data - The RGB lookup table data, stored as a string of hexadecimal digits. The string is interpreted as a sequence of bytes stored in the appropriate directcolor format, using the specified byte order.[Req]
description - Plaintext description of the color format. [Req]
Example:
<indexedcolor id="CF02" bpp="6" endianness="big">
<data>757575271B8F (and so on...) 000000</data>
<description>Nintendo (NES)</description>
</indexedcolor>
Description:
Defines a set of colors through a table of predefined RGB values (palette). When a color in this format needs to be rendered, it can be looked up in the table to find its corresponding RGB representation.
Attributes:
id - Unique identification string. [Req]
bpp - Bits per pixel. This value implicitly defines the size of the RGB lookup table; for example, if 6 bits per pixel are used, the table must hold 2^6=64 entries. [Req]
format - Refers to the id attribute of a defined directcolor format. The entries in the RGB lookup table are stored in this format.
endianness - The byte order of the RGB lookup table data (read on). Can be little or big; the former is default. [Opt]
Subtags:
data - The RGB lookup table data, stored as a string of hexadecimal digits. The string is interpreted as a sequence of bytes stored in the appropriate directcolor format, using the specified byte order.[Req]
description - Plaintext description of the color format. [Req]
Example:
<indexedcolor id="CF02" bpp="6" endianness="big">
<data>757575271B8F (and so on...) 000000</data>
<description>Nintendo (NES)</description>
</indexedcolor>
Got it? Me neither...
So basically, it's an RGB look-up table. I'm currently trying to figure out the EGA table in there (because it's smaller than the NES table and more widely documented):
Code:
<indexedcolor id="CF03" bpp="4" endianness="big">
<data>000000990000009900CC6600000099990099009999CCCCCC666666FF666666FF66FFFF666666FFFF66FF66FFFFFFFFFF</data>
<description>Enhanced Graphics Adapter (EGA)</description>
</indexedcolor>
<data>000000990000009900CC6600000099990099009999CCCCCC666666FF666666FF66FFFF666666FFFF66FF66FFFFFFFFFF</data>
<description>Enhanced Graphics Adapter (EGA)</description>
</indexedcolor>
So far, I figured out this is supposedly the standard EGA 16 color table set-up to match standard CGA colors. Enhanced Graphics Adapter has the standard color table given. Notice how Color Graphics Adapter talks about some hardware trickery for brown (we'll come to that in a moment).
Somewhat more readable, I already (think I) figured out what this is supposed to be:
Code:
B G R
000000 <-- Color 0x00
990000
009900
CC6600
000099
990099
009999 <-- Color 0x06
CCCCCC
666666
FF6666
66FF66
FFFF66
6666FF
FF66FF
66FFFF
FFFFFF <-- Color 0x0F
000000 <-- Color 0x00
990000
009900
CC6600
000099
990099
009999 <-- Color 0x06
CCCCCC
666666
FF6666
66FF66
FFFF66
6666FF
FF66FF
66FFFF
FFFFFF <-- Color 0x0F
It seems endianess is talking about the order of the RGB values as opposed to byte/short/word order for some reason. However, all these values are off by 1 or 2 (except for 0xFF values, obviously).
Now, color 0x06 is interesting, because it seems to be what Color Graphics Adapter talks about (the hardware fluke). The color value is the one given for Dark Yellow if you ignore the fact that the values are off by some percentage.
So I conclude, this table was created algorithmically by some means and that algorithm either messed up, or one can fix this on the fly by using the information that the palette is in 6bpp. Going from the original help text, I originally thought this would be a hexadecimal string of 6bit-values for some reason ― as in, it would index the 64 color palette given in Enhanced Graphics Adapter, which doesn't seem to be the case.
So is there some interpretation as to how this can be used to get the correct (as per Wikipedia) color values at runtime?
Also, does this actually work in TM? I tried using a direct color mode (RGB555, RGB888) and set the palette format to EGA, but it didn't seem to actually do any palette look-up at all and most certainly did not overwrite the current in-use palette. So how and when is this actually used? I notice the color "intensities"/"saliency"(?) increasing/decreasing when switching between NES and EGA, but not the colors changing drastically as if a palette was swapped.
Also, since none of the two examples actually use the "format" specifier, I'm a bit at a loss as to how it changes the representation of the data tag's data.
cYa,
Tauwasser