Darker special color for windows

[VS]

To answer directly what you're asking - in this format it would be:

Code Select Expand

0x00, 0x00, 0x00

But you must understand that this only changes the appearance of already existing specials. The first three umbers encode day and the next three night colour. But the actual colour in images is still the same as before. When editing simuconf.tab, you "select" the original with the number in brackets, then give how it should look. The current entries just repeat the old table, so that everything looks the same.

You could try changing one of the entries to 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF (might need spaces or lowercase?) and get some unexpected results (one of the specials will now always be saturated red, with any existing pakset). Thus, I fear that this is bordering on useless, since a change in this table would break all backwards compatibility.

edit: It's not useless, but useful only for future paksets that start with clean slate. Either that, or a massive overhaul of already existing pakset.

edit2: I will try to assemble some statistics on actual usage of specials (in near future). Maybe there are some unpopular ones...

[The Hood]

Thanks VS, that's helpful. Backwards compatibility won't be a problem with pak128.Britain as currently there are no night colours whatsoever. If I understand correctly, in order to get night colours I would have to use shades or similar to paint on the special colours where desired (making the windows appear special grey in the image rather than pak128.Britain black in the png file) then use the entries in simuconf.tab to get the program to redraw these as black in daytime (to get the same appearance as now) and whatever I chose for night. Is this right?

[Fabio]

An extremely simple Imagemagick script could do the trick of replacing e.g. 0x090909 (new special colour) with 0x0a0a0a in all images in a folder in minutes. Just run it locally and commit to svn. If we decide for new colors, I can help with the script.

[VS]

Hood -> Yes. However, while drawing in Shades or any other program, you will still see just the "original" colours, only their appearance [later] in game will change. Let's say you convert the five greys to other colours. Then, you'll have to paint still with the greys, even though they would be red or white in game.

Fabio -> Sorry, but you're totally out of the loop The current specials stay. You can just configure how they look. We got no new colours. We can only change the old ones. This breaks all the images, as the specials are already used.

[prissi]

Pink (was only added for french signals) and blue lights are almost not used.

[Spike]

very nice, that is a great thing

[Fabio]

Sorry, I got it completely wrong this time. I thought it was about mapping new colours and associated problems, not redefining old ones to newer values.

[kierongreen]

You can't keep the background colour in a register without a to me very exotic way of drawing things

What I was meaning was the transparent colour - as in, the value you will test an image pixel against to determine whether the following however many pixels are transparent. I think I used this method in one of my own projects.

Actually the simutrans image code works slightly differently than I remembered (it has been several years since I last looked at it!) - it uses a pixel counter to say how many transparent or opaque pixels follows. This means that adding a special shadow colour is much, much more of a performance hit.

For each line currently when plotting simutrans does:

Code Select Expand


do
  read number of transparent pixels, and skip over these

  read number of opaque pixels
  for each opaque pixel
    copy from source to destination

until no pixels remaining;


The plot can be a straight copy, or a 25%, 50% or 75% blend of either the image or it's outline with the background - there is no function for an arbitrary % blend. In each of these cases plot or blend is a simple function which is just a loop plotting or blending x number of pixels.

Note that at the moment blends only use image outlines - if I remember correctly this was due to both being faster and producing a better effect in game.

Now, if we were to allow one 50% special colour transparency for shadows this would mean:

Code Select Expand


do
  read number of transparent pixels, and skip over these

  read number of opaque pixels
  for each opaque pixel
    test to see whether a shadow
      YES: blend black colour
      NO: copy from source to destination
until no pixels remaining;


When plotting an image every pixel will be slower than normal, with shadow pixels slower still. Purely guessing (if anyone is interested they could try to benchmark) I'd say image plotting would be around 5% slower for an image with no shadows, rising to maybe 40% slower for one with lots of shadow pixels.

Also an image with blended shadows will have twice the number of shadow pixels as one using a dithered shadow pattern - for a typical tree this may result in around 10% more pixels being plotted, further contributing to performance loss. However for clipped plotting in particular this is very slightly offset by not having to switch between skipping and plotting pixels.

[colonyan]

"special_color[0]=0x57, 0x65, 0x6F, 0xD3, 0xC3, 0x80 ,,, "
I can not figure why there are 6 colours assigned for each special colour.
Basically this allows to designate day colour for each night time colour right?
Can someone share how to use these lines?