News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Theme colours

Started by An_dz, May 01, 2014, 07:06:11 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

An_dz

I don't get what all the colours are in the code. I want to fix them on the dialogs as well as the sizes, but I am having difficulties understanding what every colour should do.

Why gui_button_text_color exist if it's not even defined in simcolor.cc and the working option is gui_button_color_text?

Why there is gui_static_text_color and gui_text_color? The comment says gui_text_color is for checkboxes but checkboxes use gui_button_color_text. I guess that gui_text_color should be used in edit areas and gui_static_text_color in the rest.

What does gui_text_highlight and gui_disabled_text_color should do? The comment says gui_disabled_text_color is for disabled buttons but gui_button_color_disabled_text exist for it.

And those I have no idea: gui_face_color and gui_color_cursor.

Ters

There is no simcolor.cc, so what did you expect?

Joking aside, amid the confusion regarding what the new themeing should do, there was an idea that themes should not be bound by the ancient 8-bit color palette simcolor.h operates on. What you see is probably a half-done or misunderstood attempt at this.

prissi

There are two kinds of buttons, buttons with any color and uniform color buttons. Maybe this is where the naming originally wanted to go; but then the colors for color buttons (i.e. minmap, finances) are defined by the game anyway.

Some cleanup seems quite justified then.

An_dz

#3
Ok, since there's no consensus on what every option should do I'll propose my idea of options:

gui_color_text = Colour of most texts
gui_color_text_highlight = Colour of text in tabs, finance window headlines, ware list bonus text, minimap zoom indicator, fps info in video options.

gui_color_edit_text = Text colour in edit areas and alike
gui_color_edit_text_selected = Text colour in edit boxes when the text is selected
gui_color_edit_background = Background colour of edit areas, charts and alike
gui_color_edit_background_selected = Colour of the background of the selected text
gui_color_edit_beam = Colour of the editing beam/cursor

gui_color_chart_text = Chart text (maximum value, months/years)
gui_color_chart_lines = Chart lines that divide it

gui_color_button_text = Text colour for buttons
gui_color_button_text_disabled = Disabled buttons text
gui_color_button_text_selected = Pressed buttons text

gui_color_colored_button_text = Text colour for coloured buttons
gui_color_colored_button_text_selected = Text for pressed coloured buttons

gui_color_checkbox = text colour for checkboxes
gui_color_checkbox_disabled = text colour for disable checkboxes

gui_color_ticker_text = Text colour in ticker
gui_color_ticker_background = Ticker background
gui_color_ticker_divider = Ticker top divider

gui_color_statusbar_text = Text colour in statusbar
gui_color_statusbar_background = Statusbar background
gui_color_statusbar_divider = Statusbar top divider

These stay the same but change the name to keep a standard:
gui_highlight_color => gui_color_highlight
gui_shadow_color => gui_color_shadow

These keep unchanged:
tooltip_background_color
tooltip_text_color
cursor_overlay_color
front_window_text_color
bottom_window_text_color

prissi

The ticker color depends on the news, i.e. player color, warning, ... As such, it does not make sense to skin it (or if skinned, then the intended color is ignored).

The following are not feasible, or need further thoughs, since they have to work with all back and forgrounds, and can be set by the program. At the moment useless imho.
gui_color_colored_button_text = Text colour for coloured buttons
gui_color_colored_button_text_selected = Text for pressed coloured buttons

Otherwise a very sensible suggestion.

An_dz

It's up to the theme creator to test the colours. Most themes will probably use the default colors, but maybe someone needs to invert the colors for pressed and unpressed, and with these he/she can. And if the theme uses bad colours it won't be used, simple, the important is the default theme be fully working.

The gui_color_ticker_text is really useless as the messages are in player colour.

prissi

The colors in the finance window and in the soem other windows needs to be consistent, if any helpfiles are of use. I think theme dependent help files are out of question, as getting help files finished is hard enough.

An_dz

I'm not talking about changing the colour of the buttons, only the colour of the text. I agree to keep the button colour defined by the game.

Also, I decided to remove gui_color_chart_text as well as gui_color_chart_lines and replace them with gui_color_chart_lines_odd, gui_color_chart_lines_even and gui_color_chart_lines_zero and for the left values use gui_color_text_highlight. Got to test good default values though. Maybe will need to add gui_color_chart_text_(odd|even)

prissi

That sounds quite reasonable.

An_dz

Quote from: Ters on May 01, 2014, 07:54:21 PM
Joking aside, amid the confusion regarding what the new themeing should do, there was an idea that themes should not be bound by the ancient 8-bit color palette simcolor.h operates on. What you see is probably a half-done or misunderstood attempt at this.
So that's why I can't get the colour I expected. If I try to use black I get #210400.

prissi

#10
You should get black as this is in the color table. Otherwise it is a bug ...

EDIT: This is indeed a bug, an ugly one too, as colors in the pakset could go to 255 and will access random memory (mostly code) when accessing those colors. These defualt windows colors need to be added.

An_dz

It's not a bug, but a wrong implementation. After reading the code I found that display_get_index_from_rgb in simgraph16.cc gets the nearest colour in part of the 8bit palette (only from special_pal with 224 colours).

But, simcolor.h is just a big define file and all functions uses the colours as PIXVAL, which is in RGB555, so I guess we could store the RGB555 value in simcolor.h and use it directly.

To keep compatibility can't we use color_idx_to_rgb(idx) in every value which uses the old value in simcolor.h? Not sure, but the only other uses of this palette is on objects with mapcolor parameter, so we could convert them too on their load.




Back to the colour parameters, I made a patch. I found some parameters that should be removed and some others to be added.

Ters

Quote from: An_dz on May 04, 2014, 10:09:37 PM
But, simcolor.h is just a big define file and all functions uses the colours as PIXVAL, which is in RGB555, so I guess we could store the RGB555 value in simcolor.h and use it directly.

That was what I suggested many months ago.

prissi

Yes and no; that part of the code was not finalized (and some thing like factory colors use hardcoded index in pak files). But indeed, the buttons could store rgb and use the rgb functions.

An_dz

#14
I guess that moving the colours to RGB require us to create an HSB/HSV function so we can brighten the colours and remove the color+1 calculations. What do you think?

Edit:
I found the display_blend_wh_rgb function. I may use it, but I think the best is derive a function to simply blend two colour so it's faster.

Ters

color+1 only brightens colors in certain circumstances. Depending on the situation, the GUI should either get brighter and darker colors explicitly from the theme, or manipulate the PIXVAL before sending it on. The former case should be preferred, because that gives the theme author the most control and freedom. Player colors are an exception, although I'd like to see the way to get brighter and darker player colors formalized a little.

An_dz

Then maybe some functions would need to be changed as they only receive a base colour and derive the colours.

At the dialogs I have already changed some of them to use SYSCOL_HIGHLIGHT and SYSCOL_SHADOW, when appropriate.

I have the idea of creating an array of player colour. Store inside it, in PIXVAL, the 16 colours, 8 primary and 8 secondary.

A fast search for color(+|-)1 calculations reveals that we only use them for tooltips, this was a superficial search using /(colou?r|farbe) ?(\+|\-) ?\d/.

Ters

Quote from: An_dz on May 26, 2014, 07:55:08 PM
A fast search for color(+|-)1 calculations reveals that we only use them for tooltips, this was a superficial search using /(colou?r|farbe) ?(\+|\-) ?\d/.

Why do tooltips do that? Because they don't have highlight and shadow?

Quote from: An_dz on May 26, 2014, 07:55:08 PM
I have the idea of creating an array of player colour. Store inside it, in PIXVAL, the 16 colours, 8 primary and 8 secondary.

I was thinking something like that. Perhaps a class rather than just a naked array. But first player colors must be freed from being embedded in one of the special colors palettes.

An_dz

A more in depth search has shown just another place:
void reliefkarte_t::add_to_schedule_cache
gui\karte.cc@108

Quote from: Ters on May 26, 2014, 08:04:35 PM
Why do tooltips do that? Because they don't have highlight and shadow?
Tooltips are built from display_ddd_* functions, the standard is display_ddd_proportional. They receive a base_colour and use display_fillbox_wh and display_v_line to build a 3D box. The colours of the highlighted & shadowed lines simply use colour(+|-)1.

Quote from: Ters on May 26, 2014, 08:04:35 PM
But first player colors must be freed from being embedded in one of the special colors palettes.
Why first? Can't this be implemented later? Can't I first convert everything to use RGB functions? Can't I just use idx_to_rgb for now?

Ters

It's been a while since I looked into the color management, so I don't remember the details. One thing I remember is that it is very difficult to understand, with colors being copied from one place to the next. I think player colors, at least the current player colors, are stored three or four different places already.

It might be that breaking up the special colors palette is what you're doing in the first place.

prissi

With player colors a darker shade is not equal in rgb distance, due to the different sensitivity of the eye. Hence the color +- 1.

Also station names (and any other ddd box function) uses color index +-.

Ters

Quote from: prissi on June 04, 2014, 08:49:50 PM
With player colors a darker shade is not equal in rgb distance, due to the different sensitivity of the eye. Hence the color +- 1.

Isn't this eye sensitivity thing true for all colors?

prissi

But ddd boxes are the only place where reproducable darkening/lightening is needed.

An_dz

How should I define the colours in PIXVAL in simcolor.h? Because right now I was using color_idx_to_rgb but if any of these are used outside a function in any cc it's undefined/zero/black.

Ters

Conversion to PIXVAL must happen after the graphics subsystem has been started. Color constants should in my opinion be defined as RGB triplets, either in code or tab files, and fed through get_system_color() by the theme manager when it starts up.

An_dz

#25
Thanks, guess now I can continue.

Edit:
Got it, thanks Ters!

Edit2:
It just worked for the scrolling credits in banner, the colour buttons (eg. map) are still black.

An_dz

#26
The documentation for the new colour parameters is updated:
http://simutrans-germany.com/wiki/wiki/tiki-index.php?page=en_themeDef#Colors

Note that the patch just added them, it still doesn't work in most dialogues, it may also have some places using the wrong parameters as well.

Yona-TYT


Very nice   :thumbsup:


I wonder if I can use transparency in some cases for example statusbars... it would look great in my humble opinion.


An_dz

I've created a repo in GitHub with this project: https://github.com/An-dz/simutrans/
Took a while to clean it from other patches I have. :)

An_dz

I have a questions regarding player colours in player_frame_t.cc, there's this line:
player_get_finances[i].background_color = PLAYER_FLAG | ((player_ ? player_->get_player_color1() : i*8) +4);
Why does it have this i*8? Because to me if the player exists it will use the first argument, the player saved colour. The i*8 options is only used when the player doesn't exist, but if it doesn't exist this button doesn't even show up, so why we create a custom colour for every one? Why not a fixed colour?

prissi

When you activate a player, then indeed this button get activate and then the default plaer color is needed. SO indeed, on creation this might be useless with the standard theme.