My First Patch - Face Customizer

[MacLir]

Looks good Jez!

Hopefully, the devs will like enough to put it in the trunk.

[jez]

bobingabout: I'm still very interested in tyhe remappable hair thing. At the moment I'm just planning on usign the available sprites and the only remapping will be eye colour, which is already done.

After this patch is released, perhaps we could work together to get some extra remapping done. Please wait until I've released the final version of the patch before we work on this. One thing that bothers me is that this would require a new, extra file with extra face sprites in it (the ones that are remappable). How would this work? Currently this code relies on a GRF file found in the original TTD that you have to copy over, presumably for legal reasons. Would you simply have to access your new GRF file to get the 'remappable' sprites?

[Chrill]

Looking good! Me like, me like!

[DaleStan]

One thing that bothers me is that this would require a new, extra file with extra face sprites in it (the ones that are remappable).

No, it wouldn't; all sprites are remappable. You just have to write the right color-map table(s).

[jez]

Bobingabout previously posted a file, Faces3.GIF. If you look at it you'll see the hair colours look green. I think he purposely changed them so they had a palette that was easily re-mappable in TTD. That's why I say that, in order to use that, you'd need a new GRF.

[bobingabout]

i've got many projects on the go you see

yes, the reason i chose to create remapable hair is to get rid of the situations where you end up with brown hair and black facial hair and eyebrows. Green is remap2, as developed by TTDPatch, and was used because eyebrows are on the same sprites at eyes using remap1. also, some of the colours used by hair and such are also used by some skin tones, so in many cases a manual tweak was required.

most of the hair is complete, there are a couple that arn't, a few repeats that don't need to be done, and all the facial hair and eyebrows that need to be done.


you know whats strange? in my other projects i'm the code guy, but for OTTD, i'm a graphics guy

[jez]

bobingabout: Oh, was that why you were doing the remapping? Sorry, I'd rather not force all facial hair to be the same colour. I just made a face with a white moustache, jet-black eyebrows and brown hair. It looked alright. Hair can be dyed, you know. I think we should allow that.

I thought the purpose of your remapping would be to allow extra colours, and maybe even start to allow remapping other things (tie, shirt, etc) so that they could have custom colours too.

I'm not an expert on how the remapping works in OpenTTD. I'll have to do some research on it, or you'll have to tell me here; either is good.

Does the game use a 256 colour palette? The reason I ask that is because I think things like water 'sparkle' animation are done by rotating the colour palette, which is traditionally done in 256 colour mode. Or, is it using a high-colour palette with 256 colour sprites, so you can only use 256 shades with the sprites but then remap to whatever colour you feel like, resulting in a composite game image of more than 256 colours?

[DaleStan]

Does the game use a 256 colour palette?

Yes. Both ends (.grf files and video output) are 256-color.

Color maps are simply tables of 256 bytes, where the value in byte n is the color to draw when color n appears in the sprite being drawn.

[jez]

Green is remap2, as developed by TTDPatch, and was used because eyebrows are on the same sprites at eyes using remap1.

You've lost me. Could you explain what you mean in terms of someone who isn't an expert at OpenTTD colour remapping?

[DaleStan]

http://wiki.ttdpatch.net/tiki-index.php ... oordinates

Start there, and then come back and ask questions about the parts you don't understand.

[jez]

I've read that before and again, and my questions still stand.

[DaleStan]

You're going to have to ask better questions, then. Explain what, exactly?

Every minute detail of how TTD's color-mapping functions work?
The format of a recolor table?
The reason for choosing those particular colors for CC2?
The method of using a certain remap table?

[jez]

Erm, how about... what is remap1 and remap2? The phrase, "eyebrows are on the same sprites at eyes using remap1", is literally nonsense.

[DaleStan]

"remap2" is the set of colors labeled "Patch Company 2"; "remap1" is the set labeled "Company".
So called because they are the two ranges of colors for which company-color colormaps are readily available, and because Company came before Patch Company 2.

And bobing meant "as", not "at".

[jez]

"remap2" is the set of colors labeled "Patch Company 2"; "remap1" is the set labeled "Company".
So called because they are the two ranges of colors for which company-color colormaps are readily available, and because Company came before Patch Company 2.

OK, so why would you want to use those colours to remap facial features? They have nothing to do with a company's colour scheme.

I'm finding this whole discussion pretty confusing. When I think of a traditional remappable 256 colour palette, when you remap a colour, it changes the colour of all pixels on that screen. I don't think you're talking about remapping the 'Company' section because that would change all the companies' vehicle colours; as for changing Patch Company 2, well. Isn't that designed to be used for something else, other than this? Some 'secondary' company colour or something?

And bobing meant "as", not "at".

"eyebrows are on the same sprites as eyes using remap1"

Still nonsense.

[DaleStan]

Ah. There's the misunderstanding. Color-mapping is done in the sprite-drawing routines, not in the video hardware. In this way, the same four or eight sprites (one per direction) can be used for all instances of a given vehicle, even though there are sixteen different company colors, and it has to be possible to display a vehicle in any of the colors. Similarly, the same sprite is used for all instances of a town building, even though there are seven possible accent colors.

The "palette animations" (water sparkles, crossing and runway lights, &c.) are done using the "change the RGB value assigned to a given palette index" system, but "color mapping" constitutes "draw a different palette index than the one that appears in the sprite".

So why would you want to use those colours to remap facial features? They have nothing to do with a company's colour scheme.

And they don't have to. The CC-blues (remap1) and CC-greens (remap2) are distinct from any company company's selection of what color those should turn into. There are nearly three hundred different standard remapping sprites. Any sprite can be drawn using any of these color-maps, regardless of the company's current color selection(s).

"eyebrows are on the same sprites as eyes using remap1"

Eyes use the CC-blues (remap1), and then are drawn with the appropriate color-map. In order to make the eyes and eyebrows be different colors, they have to be different colors in the sprite too, and the easiest other set of colors to use is the CC-greens (remap2), since there are standard color-maps that allow both colors to be modified independently, simply by selecting the correct one.

There are also the recolorable browns, but there are no maps that simultaneously change the browns and any other color range, so using the browns would require modifications to the sprite drawing-system to allow multiple color-maps to be specified when drawing a single sprite.

[jez]

Ah. There's the misunderstanding. Color-mapping is done in the sprite-drawing routines, not in the video hardware. In this way, the same four or eight sprites (one per direction) can be used for all instances of a given vehicle, even though there are sixteen different company colors, and it has to be possible to display a vehicle in any of the colors. Similarly, the same sprite is used for all instances of a town building, even though there are seven possible accent colors.

Ah. So, sounds like you were telling an untruth with:

Yes. Both ends (.grf files and video output) are 256-color.

Is it not as I suggested, and that the ACTUAL output is in high colour, (surely you have to display more than 256 colours at once with colour mapping) even if it is based on an original 256 colour palette that may be modified for some sprites?

The "palette animations" (water sparkles, crossing and runway lights, &c.) are done using the "change the RGB value assigned to a given palette index" system

Is this in video hardware or just coded?

So why would you want to use those colours to remap facial features? They have nothing to do with a company's colour scheme.

And they don't have to. The CC-blues (remap1) and CC-greens (remap2) are distinct from any company company's selection of what color those should turn into. There are nearly three hundred different standard remapping sprites. Any sprite can be drawn using any of these color-maps, regardless of the company's current color selection(s).

Ok... I assume you mean something like 'custom colour' by 'CC'. In that case, it's rather unfortunate that that linked page refers to them as 'company (2)'... I can't really think of a more inappropriate name. Should be something like 'Remappable' and 'Remappable 2'. Honestly, why can't people just explain stuff clearly?

In order to make the eyes and eyebrows be different colors, they have to be different colors in the sprite too, and the easiest other set of colors to use is the CC-greens (remap2), since there are standard color-maps that allow both colors to be modified independently, simply by selecting the correct one.

... like 0x314? 0x30F? 0x30D? Left-shifted by PALETTE_SPRITE_START? Is there any way I can get a list of these colour-maps, and their identifier values? Which particular map was being suggested for use with the hair? From one of bobingabout's above posts, it looks like you can set 8 custom palette values (presumably in the CC-green slots) then somehow tell the sprite system to remap certain colours to these. Obviously I don't know exactly how this works. Any decent documentation?

[DaleStan]

Ah. So, sounds like you were telling an untruth with:

Yes. Both ends (.grf files and video output) are 256-color.

Is it not as I suggested, and that the ACTUAL output is in high colour, (surely you have to display more than 256 colours at once with colour mapping) even if it is based on an original 256 colour palette that may be modified for some sprites?

No, on all counts. The colormaps are just 256 byte translation tables. The mapped output has the same palette that input had.

If you know C:

Code: Select all

if(remap){
  for (i=0; i<spritesize; i++)
    sprite[i] = trans_table[sprite[i]];
}
draw(sprite);

Where sprite is the palette index of the i-th pixel.

"palette animations"

Is this in video hardware or just coded?

My limited experience with drawing 256-color paletted images says that you can do two things:
1) Assign a byte value to a pixel. This color is looked up the video controller's palette, and that color is drawn.
2) Modify the video controller's palette, so that a given color index appears with a different actual color.
Assuming my memory is correct, palette animations use the second system to produce animation.

Ok... I assume you mean something like 'custom colour' by 'CC'.

No, I actualy meant "company color". The "CC-blues" and "CC-greens" are called "Company colors" because that is their best-known use. But "recolorable" or "remappable" would both be be a more accurate terms.

like 0x314? 0x30F? 0x30D? Left-shifted by PALETTE_SPRITE_START? Is there any way I can get a list of these colour-maps, and their identifier values?

The TTD-standard remap-tables are listed in this table. The other 256 are found in twocc[w].grf, and include first sixteen. The first would, I assume, map both CC ranges to dark blue, and the second would map one to blue and the other to pale green, but I don't know which. I have no clue what identifiers are used for these maps.

Which particular map was being suggested for use with the hair? From one of bobingabout's above posts, it looks like you can set 8 custom palette values (presumably in the CC-green slots) then somehow tell the sprite system to remap certain colours to these.

One of the 256 in twocc[w].grf. So, yes, red eyes and purple hair? This is now possible, unless the GUI forbids it.

Any decent documentation?

As to how [O]TTD[P] sprite-drawing code works? Not really, unless the rest of that HousesAndIndustryTiles page is useful.
As to the content and format of a recolor table? Try this. It's written with NFO coders in mind, but it may be helpful.

[jez]

So why would you want to use those colours to remap facial features? They have nothing to do with a company's colour scheme.

And they don't have to. The CC-blues (remap1) and CC-greens (remap2) are distinct from any company company's selection of what color those should turn into. There are nearly three hundred different standard remapping sprites. Any sprite can be drawn using any of these color-maps, regardless of the company's current color selection(s).

"eyebrows are on the same sprites as eyes using remap1"

Eyes use the CC-blues (remap1), and then are drawn with the appropriate color-map. In order to make the eyes and eyebrows be different colors, they have to be different colors in the sprite too, and the easiest other set of colors to use is the CC-greens (remap2), since there are standard color-maps that allow both colors to be modified independently, simply by selecting the correct one.

There are also the recolorable browns, but there are no maps that simultaneously change the browns and any other color range, so using the browns would require modifications to the sprite drawing-system to allow multiple color-maps to be specified when drawing a single sprite.

I've been vexing about this remapping system for hours, and reading as much about it as I can, and I'm still a little confused (although understanding it better now ) - I'd really appreciate an explanation of what I don't understand to finally enlighten me.

The gfx engine starts with a sprite that has a 256 colour palette. Assuming we're performing a remap drawing operation, it takes that sprite, and draws it with a pseudosprite's palette, where the pseudosprite's palette values are all numbers between 0 and 255 that 'point' to a palette entry in the 'real palette' (the actual palette that OpenTTD uses for output). That much makes sense.

However, if this is the case, what I'm not understanding is why 16 colours are being reserved in the final palette for remapping. Surely this is unnecessary. I could create a sprite in shades of red, say, and then create a pseudosprite that would map each of those red palette entries to a valid 'real palette' number. Those colours that are used for the company vehicles and get remapped based on your company's colour scheme; they could have been drawn in greyscale and a pseudosprite could remap them to whatever colour. Why only ever remap using 8 shades of blue or green that happen to exist in the 'real palette'??

The only reason the system is the way it is, that I can think of, is a limitation in the graphics system that means all input sprites have to share the same palette. Am I correct with this? Also, I'm guessing that those CC and CC2 colours aren't actually reserved, just handy in remap operations. I guess you could draw a sprite that used colours in the CC and/or 2CC range without specifying a remap operation, and it would just output those blue/green colours. Also, I guess you could draw a sprite in shades of red, greyscale, or whatever (that existed in the 'real palette'), and create a pseudosprite that remapped it to valid 'real palette' entries, and the only reason that isn't done is ... tradition? Traditionally, those 16 colours are used for remaps, and... because of that tradition, the existing remap pseudosprites mostly remap only those colours? It all seems a bit limiting to me.

Is the above correct? If that's correct, I've understood.

[DaleStan]

The gfx engine starts with a sprite that has a 256 colour palette. Assuming we're performing a remap drawing operation, it takes that sprite, and draws it with a pseudosprite's palette, where the pseudosprite's palette values are all numbers between 0 and 255 that 'point' to a palette entry in the 'real palette' (the actual palette that OpenTTD uses for output). That much makes sense.

Correct.

However, if this is the case, what I'm not understanding is why 16 colours are being reserved in the final palette for remapping. Surely this is unnecessary. I could create a sprite in shades of red, say, and then create a pseudosprite that would map each of those red palette entries to a valid 'real palette' number. Those colours that are used for the company vehicles and get remapped based on your company's colour scheme; they could have been drawn in greyscale and a pseudosprite could remap them to whatever colour. Why only ever remap using 8 shades of blue or green that happen to exist in the 'real palette'??

Because that's the way CS designed it? There's not really any better reason, except that in order to have 16 company colors, each with eight shades, there must be at least 128 colors in the "holy grail" palette for that alone.
Since there were only 8 colors in the CC range, Patchman (I assume) decided that consistency was a gem and used 8 colors for CC2.

The only reason the system is the way it is, that I can think of, is a limitation in the graphics system that means all input sprites have to share the same palette. Am I correct with this?

Yes. This palette is supplied by the game.

Also, I'm guessing that those CC and CC2 colours aren't actually reserved, just handy in remap operations. I guess you could draw a sprite that used colours in the CC and/or 2CC range without specifying a remap operation, and it would just output those blue/green colours.

Again correct; if no remap table is supplied, the sprite is drawn exactly as it appears in the file.

Also, I guess you could draw a sprite in shades of red, greyscale, or whatever (that existed in the 'real palette'), and create a pseudosprite that remapped it to valid 'real palette' entries, and the only reason that isn't done is ... tradition?

Again correct, but unless there was a chance of using more than one remap table, it's less obfuscating and easier to apply the remap to the input sprite, rather than telling the sprite-drawing system to remap the sprite.

Traditionally, those 16 colours are used for remaps, and... because of that tradition, the existing remap pseudosprites mostly remap only those colours?

Again correct. And you are correct in that it's limiting; you're perfectly welcome to draw up a write up a new set of remap tables that perform the remaps you want.
Patchman did exactly that when creating the 2cc remap tables. He used a Perl script to generate them, and I expect he'd be willing to show it to you if you are interested.