Question concerning recolor tables and 2cc

[Uwe]

In order to support the ECS cargos without having to draw extra sprites for each bulk cargo, I have toyed around with recolor tables. That works very well, I can use one sprite for all bulk cargos (coal, ore, grain, ...), the actual cargo color is determined by the recolor table. However, since my set is all based on 2cc sprites, I'm now a bit clueless as to how combine both. The recolor table determines the final color of a pixel, the company color remapping for the blue and green pixels is therefore not used - at least that's what I see in my test grf file. Do I have to set up recolor tables for all possible company colors and the various cargos? And where could I find out which company color mapping should be used? Or is there another solution that I fail to see?

Regards,
Uwe

[michael blunck]

In order to support the ECS cargos without having to draw extra sprites for each bulk cargo, I have toyed around with recolor tables. That works very well, I can use one sprite for all bulk cargos (coal, ore, grain, ...),

Good thing that you finished this. Being on this, did I sent you the original (false colour) sprites for ECS bulk cargo, or did you invent your own one, meanwhile? I really don´t remember, sorry ...

However, since my set is all based on 2cc sprites, I'm now a bit clueless as to how combine both. The recolor table determines the final color of a pixel, the company color remapping for the blue and green pixels is therefore not used - at least that's what I see in my test grf file. Do I have to set up recolor tables for all possible company colors and the various cargos?

Yes, this is called "combinatorial explosion".

And where could I find out which company color mapping should be used?

Spmewhere in the TTDPatch .grf specs (newhouses, I presume ...)

Or is there another solution that I fail to see?

Unfortunately, no. That´s the problem with 2cc, it´s a pre-defined mapping and for your cargoes, you want another one, so NxM ...

(Luckily, I don´t use 2cc in DBXL. )

regards
Michael

[Uwe]

Thanks for the answer, I already feared something like that. And yes, you did send me some these cargo sprites.

[PikkaBird]

And where could I find out which company color mapping should be used?

The 4th byte of vehicle property 43 contains company colour information.

Although the end result would be a monstrous block of nfo, it wouldn't actually be that hard to make the 256 recolour sprites for each cargo; a little tedious to do the first one perhaps... but yeah, I'd be inclined to just use one CC and a more managable 16 sprites.

[Uwe]

Well, with at least 7 different cargos and the additional idea of having random colors for trailers and such this amounts to 256*(7+x) recolor sprites, yielding a total of at least 1792 recolor sprites. Quite a lot if you ask me. Therefore I'd like to ask if the behaviour of recolor sprites could possibly be changed so that the player colors are applied automatically regardless of any recolor sprites from the grf file. Of course this would have to be based on some criterion, as the current behaviour needs to be preserved as well. I'm sure I'm not the only one who would want to use 2cc and color refits together.

[michael blunck]

Well, with at least 7 different cargos and the additional idea of having random colors for trailers and such this amounts to 256*(7+x) recolor sprites, yielding a total of at least 1792 recolor sprites. Quite a lot if you ask me.

Hehe. Didn´t I tell you? BTW, you forgot that you´ll need 2 different sets of those 1792 recolour sprites, for DOS and Windows.

Therefore I'd like to ask if the behaviour of recolor sprites could possibly be changed so that the player colors are applied automatically regardless of any recolor sprites from the grf file. [...]

That´s problematic because 2cc is nothing special than a certain mapping, like any other mapping is.

regards
Michael

[Uwe]

Resurrecting this old topic... I've worked out a small C program to generate me fitting recolour sprites to imitate the 2CC behaviour. Now the tricky part is to get them to play in NFO, at least I encountered some problems while doing so... Usually, recolour sprites are mapped using action D to reserve some place for the sprites and then action A to define the sprites themselves, like so:

Code: Select all

27 * 9	 0D 01 00 00 FE FF 08 21 00 // reserve a block for 21 sprites
   28 * 5	 06 01 02 03 FF // set the correct sprite ID for the recolour sprites
   29 * 5	 0A 01 21 00 00// define 21 recolour sprites

Using action A, 255 sprites can be defined in one go. Since recolour sprites for 2CC are exact multiples of 256, NFOrenum complained about one too many recolour sprite. So, I worked around this by reserving space for 256 sprites, then defining 255, and then add another action D to calculate the correct sprite offset for the last sprite:

Code: Select all

24 * 9	 0D 01 00 00 FE FF 08 00 01 // reserve room for 256 general sprites
   25 * 5	 06 01 02 03 FF
   26 * 5	 0A 01 FF 00 00
//... 255 recolour sprites going here...
  282 * 9	 0D 02 01 01 FF FF 00 00 00 // compute sprite offset (+FF from the index returned by GRM reservation)
  283 * 5	 06 02 02 03 FF
  284 * 5	 0A 01 01 00 00 // define last recolour sprite

Now I'm wondering if there's a cleaner way to achieve that, especially since the 256 sprites are only for one freight refit. In total, I've got seven different freight recolour schemes, so I need to define 1792 recolour sprites (+the same for DOS because of the differing palette).

I've also read about action 5 type 0A (2CC recolour maps). There, an extended byte is used to adress 256 sprites. I know that this is the way the 2CC recolour sprites are defined in ttdpbasew.grf - but how are they invoked later on? Would it be possible for me to define my recolour sprites using action 5? If so, what would I need to return in the callback 2D chain? The wiki page about this callback mentions some 2CC stuff, but I fail to see which would be the correct return value.

[DaleStan]

Using action A, 255 sprites can be defined in one go.

Incorrect. Up to 65025 sprites can be defined per action A.

Would it be possible for me to define my recolour sprites using action 5?

Possible, quite. A good idea? No. You'd be relying on the nondefinition of all but the first 256 sprites, and there is no guarantee that undefineds will stay undefined.

For this reason, I will not answer the remainder of your questions on this subject. The necessary information is all documented, if you really want to rely on the current undefined behaviour.

[Uwe]

Ouch. Thanks for pointing out my inability to read and completely understand the specification of action 6 and action A. I've got it working now - perhaps I should stop coding when I'm out of coffee.

[Uwe]

*bump* Christmas is over, time for another possibly stupid question...

For some trucks we want to have randomly coloured cargo (containers for example). Instead of drawing lots of sprites for each color, I thought it would be quite useful to use random recolor sprites. So I set up the random action 02 to point to var actions 02 which then point to various recolor sprites. However, that doesn't seem to work. After consulting the wiki, it seems the reason is that the results of callback 2D are cached. So, is it actually possible to remap colors depending on (un)loading of the vehicle and the associated vehicle triggers?

For better understanding the most important code snippets:

Code: Select all

16 * 5	 0D 01 00 00 00 // set param 1 to old value of 0
17 * 9	 0D 00 00 00 FE FF 08 00 07 // reserve room for 1792 general sprites (a bit crazy, but anyway)
18 * 5	 0D 01 02 00 01 // calculate param 0 - param 1
19 * 44	 06 01 82 03 [...] // add param 01 to 2 bytes at offset 03 in next action A
20 * 44	 0A 0E 80 00 00 [...] // setup all the recolor maps
21 * 257	 00 [...] // qst of many recolor maps

// define the graphics using false colors that are mapped using the recolor sprites
1896 * 9	 02 01 A1 01 01 00 00 00 00 // tractor
1897 * 9    02 01 B1 01 01 01 00 01 00 // trailer
// color refit using adv. action 02, there are several of them, each using another constant value as offset into the recolor sprites
1904 * 17	 02 01 31 85
        7F 00 20 FF FF 00
        1A 00 01 00          // constant value 01
     00 00 80

1919 * 39	 02 01 22 80 84 00 10 30 00 31 00 32 00 33 00 // randomly choose one of the mappings
                                  34 00 35 00 36 00 37 00 //
                                  38 00 39 00 3A 00 3B 00 //
                                  3C 00 3D 00 3E 00 3F 00 //

1920 * 14	 02 01 10 81 10 00 FF 01 21 80 01 01 FF 80 // articulation callback
1925 * 14	 02 01 0C 81 0C 00 FF 01 02 80 11 11 A1 00 // tractor, make shorter and use graphics set A1
1926 * 14	 02 01 0B 81 40 00 FF 01 0C 00 00 00 B1 00 // check position (tractor or trailer), trailer uses graphics set B1
1927 * 18	 02 01 0A 81 0C 00 FF 02 // check callbacks
     10 00 16 16 // articulated
     22 00 2D 2D // color mapping
     0B 00

1931 * 16	 03 01 01 21 02 FF 01 00 // buy menu
  			  05 0A 00 // goods -> false colors
                          [...]

Is the handling of CB 2D actually correct in this way? Is there some way to trigger an update of the cached recolor map whenever the random action c-id 22 changes the triggers and points to a different action 02?

[michael blunck]

Is the handling of CB 2D actually correct in this way? Is there some way to trigger an update of the cached recolor map whenever the random action c-id 22 changes the triggers and points to a different action 02?

Yes. No, only by using CB32 (which wouldn´t help in your case) and when rearranging the consist.

regards
Michael