News:

SimuTranslator
Make Simutrans speak your language.

Simutrans color managers

Started by Ters, October 31, 2013, 05:58:58 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ters

There's been some discussion about how colors are and should be managed in Simutrans in the GUI Theme topic. To avoid derailing it, I'll post further facts and ideas here.

Colors in Simutrans can currently be divided into three categories: real colors, player colors and light colors. Real colors are the full range of 15-bit RGB values. As far as I know, until recently, all these come from images in pak files.

Player colors are 28 gradients of 8 colors, 224 in total. From these, each player may select two gradient ranges for use as that players primary and secondary color.

Light colors are 15 colors which have defined an unlit daytime color value and a lit nighttime color value.

The 224 player colors and 15 daytime light colors are combined, along with black padding, are combined into a list of 256 colors. These colors are what's been used for drawing the non-image based parts of the GUI so far. There also exists a corresponding list of the same 256 colors adjusted for the day-night cycle (except that lights are not lit), which I'm not sure what is used for.

All 32768 real colors, the 16 colors for a currently selected player (not the active player in the game) and the 15 colors for the lights are also combined into two gigantic lists used for converting pak images into the final colors displayed on screen. One liste is in full daylight, while the other changes with the day-night cycle, including lights being lit.

For the new GUI, it's a good idea to break away from using player colors only for doing the GUI. When doing so, it makes little sense to use the light colors in the GUI. I've tried to sketch out the contents and relationships between the different sets of colors, here represented by manager classes. The nature of the theme color manager is just a stab in the dark, while the light and player colors are dictated by the pak image format. I've omitted the real colors, showing only the 31 special colors in WorldColorManger. The list of functions in each class is by no means exhaustive, and just shows the most important and non-trivial in terms of making use of the class.

prissi

Ok, some additional informations: There was once a 256 color version (or to be more precise, simutrans until 80.xx was 8 bit color). I also tried a 32 bit version but it was nearly 4 times slower screen rendering (more memory to move and very little optical improvement).

The 16 light colors can be redefined by the graphic sets. So far pak64.japan and pak96 does this for a pink. Hence those are not allowed for the GUI use ... The color indices are also use in pak files for factory colors.

I think any new routine should prefer the _rbg functions and use a red color which is defines as RGB_RED (which is then resolved in simcolor.h to whatever indices this is). COLOR_RED will be only compatibility.

And again all those managers: I grew up with tron and its Master Control Program, and with the latest financial crisis: I rather have more routines doing work and less managers ;)

Ters

The nice things about programming is that you can actually have managers that do some serious work, even if you have to write them yourself on the computer.

On a more serious note, the uppermost row of "managers" (conceptually the lowest level managers) are essentially just a global array and the code to fill them, which may rather lie in the configuration subsystem. They need not be implemented in terms of a class to mask this fact. The main point of the drawing is the difference between what colors are used and how when drawing the world and drawing the GUI.

prissi

Sorry, I even try to mark my joke with a ;) It is just the trend to call everything manager, even if it's just an array of colors.

Ters

I understood the joke, and tried to make one back. But I thought that even as a joke, there is something in it that needed clarification.

Max-Max

Since the array was such a bad idea I have converted the theme colours (system colours) back to separate variables but holding a RGB value.

This resulted in a massive update of almost every GUI related module because now you can't mix a SYSCOL_XXX colours with a COL_XXXX or MN_XXXX colour, such as:

PIXVAL color = (if) ? SYSCOL_TEXT : COL_BLACK;

Where SYSCOL_TEXT is an RGB PIXVAL and COL_BLACK is an unsigned char colour index, and to add more complexity we have PLAYER_COLOR_VAL as well indexed.

Converting SYSCOL_XXXX into an index is just a waste of code because the reason for defining system colours is precisely to get colours not available in any index.

Now I have to figure out how to make a patch of all this...
- My code doesn't have bugs. It develops random features...

Ters

I think all the COL_<color> macros should be converted into proper RGB values now that RGB drawing functions are in place. They are a relic from the 8-bit days, or so I assume. The MN_ and COL_<not color> colors should be converted into SYSCOL_ colors, whether they are in an array or not.

prissi

There are a lot of functions that assume color x+3 is much bright and -3 is much darker in the player routines, and when drawing signs (i.e. the ddd routines). Obvoiusly you can convert 95% of the other stuff, but some need to stay. Also for the minimap, which used fixed 8 bit indices (not least for speed).

Max-Max

My initial point was to add the theme related colours to the existing system because it needed to be redone anyway. In this way I could focus on theme instead of a new colours system. An array could also easily, later on, be converted into an object by its index operator, meaning less effort to change the colour system.

I have only updated what is needed for the theme to work since colour management isn't really a part of my project and no one liked my object oriented idea anyway.

I just have to figure out how to make the patches now...

Quote from: prissi on November 03, 2013, 09:35:43 PM
There are a lot of functions that assume color x+3 is much bright and -3 is much darker in the player routines, and when drawing signs (i.e. the ddd routines). Obvoiusly you can convert 95% of the other stuff, but some need to stay. Also for the minimap, which used fixed 8 bit indices (not least for speed).
I used color_idx_to_rgb() to convert indexed colours, so the Player colours still works...
But yes, if colours shouldn't be indexed, how are you going to solve this in an effective way?
- My code doesn't have bugs. It develops random features...

Ters

Quote from: prissi on November 03, 2013, 09:35:43 PM
There are a lot of functions that assume color x+3 is much bright and -3 is much darker in the player routines, and when drawing signs (i.e. the ddd routines). Obvoiusly you can convert 95% of the other stuff, but some need to stay.

That's only true for very specific colors, which is why such colors are a special thing in my diagram above.

Quote from: prissi on November 03, 2013, 09:35:43 PM
Also for the minimap, which used fixed 8 bit indices (not least for speed).

Indicies into specialcolormap_all_day I assume? There is nothing I propose that should prevent that from still being possible.

prissi

Ok, the GUI can use exclusively _rgb rouitnes, that is true. Sorry for the misunderstanding.

Ters

There is however the lingering feature request for being able to define player colors directly, rather than just select them from a predefined list. That's something that will conflict with anything that relies on specialcolormap_all_day containing a well known set of colors as well as the player colors.

prissi

Specialcolormap_all_day cannot be changed, since also factory and goods color rely on them. Specifying player colors will rather have to be done other that that (Maybe using indices>256?)

Ters

Quote from: prissi on November 04, 2013, 11:20:23 AM
Specialcolormap_all_day cannot be changed, since also factory and goods color rely on them. Specifying player colors will rather have to be done other that that (Maybe using indices>256?)

Exactly. I was thinking that player colors need not be in the same index range at all. However, some things might use specialcolormap_all_day for both specifying colors "directly" (COL_BLACK & co) and for player colors, and if they use 8-bit indicies like the minimap, there will be problems.