News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

GUI Theme - the artist discussion

Started by Max-Max, September 08, 2013, 02:32:49 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Max-Max

On request I started this thread so the artists can bring there ideas, comments or needs into the Theme project without having to browse through endless of code related comments.

When the basic underlying structure is in place, we could virtually have one image for every single piece in the GUI. But as the first goal, milestone, we focus on what we have in the GUI.

I might add one guideline already when designing the skin images; do not add transparent offsets around the images.
The new theme system can resize the GUI components and are calculating how to line up the GUI images. Any transparent offset added will screw up the calculations. To solve this, the transparent offsets are removed when the skin loads.

Further down the road you will have plenty of possibilities to add padding, margins, sizes etc...

Note!
Any guidelines and recommendations noticed here may be subject to changes until it is officially released.
- My code doesn't have bugs. It develops random features...

Max-Max

#1
GUIDE - BUTTONS (round button)

A button is designed as usual with three images; left middle and right. The height is not limited to the old hard coded 14 pixels, it can be any size from 3 pixels up to 64. For best result the full button (all three images together as one) should be dividable with 3 in both x and y direction. The actual size of the button can be specified in the new theme.tab file, located in the PAK folder. This can in the end be overridden by the user in the theme folder located in Simutrans root.

The theme manager will concatenating these three images into one image and slice it up in a 3 by 3 grid.


These 9 pieces is then used to draw the button in any desired size. The simplest form of button that can be shown in any size can be expressed with 3x3 pixels. For the most effective drawing, the middle part should be the full cell width.

The corner pieces should not spill over to the adjacent pieces, but can be drawn in any way within their own areas. The top, left, bottom and right edge pieces are extended and should not contain any repeated patterns. This would look out of synch when resized.

The middle piece is the button background and fills the area inside the corner and edge pieces.
Further down the road I'm looking into how we can do a pattern fill, specify resize rules and some drawing behaviours.

Colours
The text colour than now be defined as well. It is now possible to create dark buttons because the text can be set to matching colour. There are different colours for enabled and disabled buttons. The colour is defined in the theme.tab file and can be set either as an colour index or a RGB value. The RGB value is for the moment mapped to the nearest indexed colour and must be proceeded by #.
Example: button_color_text = #AABBCC
The result may be unpredictable until the theme is tested. We are discussing how we can use the true RGB555 version of it.

Exceptions
None of the button images will have any transparent padding removed. Further down the road, we will add images for a focused button. This image will likely draw an image around the button and there fore padding must be left to give it the proper space.

Related theme tab variables
These are the button related variables and their default values if not defined.
gui_button_width = 92
gui_button_height = 14
button_color_text = 240
button_color_disabled_text = 229
- My code doesn't have bugs. It develops random features...

prissi

Why is the button needed to be scaleable? Imho the font size must be anyway theme dependent. Hence the three images would suffice and button sizes are derived directly from the images (less error prone). Also a MAC like button (completely round sides) cannot be realized by this at all (or rather is a single size as now too). (Just look at the aqua skin in the snv).

Max-Max

We can get into a lot of details and scenarios where virtually anything can be used in the wrong way.
If you design a button that "can't" be resized, don't resize it then, it is as simple as that. In the end it is up to the user.
The artist specifies the size he designed and when we move forward he can also specify if this element can be resized, but we aren't there yet. I also have some thoughts of using a similar model as Window Icon handles resolutions, but that is only thoughts and we will see where it end up...

Why we resize the buttons?!?
This can impossible be a surprise to you, we have been talking about this ever since the project started. To target hires-screens and/or portable devices we need to resize them to fit our needs. I have even posted screen shots showing buttons of different sizes.

I'm sitting with a 2560x1440 screen and I really need some bigger GUI controls. A portable device needs a GUI big enough to detect a finger without the user guessing where he is pointing. Some people really like to have a lot of info on the screen and wants to shrink everything to get in more. This is all possible with the new theme system, leaving it up to the user to configure it for his/her needs and taste.

When it comes to fonts... I do intend to have a look at the font system as soon the theme v1.0 is up. As I said once before, I worked 14 years developing printers using bitmap fonts...
- My code doesn't have bugs. It develops random features...

Leartin

Actually, prissi, you can design a skin with completely round buttons that is scaleable. The only issue is that once you scale it, the buttons aren't completely round anymore, however, they still work and won't look too bad. I think having resizable buttons is core to the idea of gui themes, after all, it's easy to create a skin pak and overwrite every pak with it, but that's not the point. The idea is to create more freedom in gui design, for pak-developers and users alike. If, as a pak-developer, you don't like it that your round buttons scale to be rounded buttons, just don't scale them, and they will look as intended. Sure, users might change it anyway to something that fits their need, but again, thats the point of the whole project and you can't force a user not to change anything even now.

However... After some pages of code discussion I don't pretend I understand, it's only now you state your concerns about intended functions? How is it even possible to critesize something and offer suggestions on how it should work when you don't know it's purpose?




Max-Max, you state that tte buttons shouldn't contain a pattern because they are to be resized. Can't you use them like a pattern, putting them next to each other instead of stretching them? I don't care too much about the buttons, because a pattern is distracting to the eye when text is involved. But it would be nice to have for scrollbars, which should have a similar 3x3 pattern for scaling. Arrow-buttons next to the scrollbars, too.

Is it planned to enable graphics in places where no graphics were used before, like titlebar, windowborder,... So that one could create a more rounded, modern look.


About Fonts... I looked into the Simutrans Font and it wouldn't be too hard to resize/recreate it at 1.5 or 2x scale. But that's only true for the latin alphabet, at least for me, because with kanji I just don't know what is intended to be round, straight,... Wouldn't the same problem arise with any font if it's pak dependant? While big names like Deja Vu might contain all the signs needed, most just don't. While I'd be eager to design my own bitmap font for Simutrans including multiple sizes and every œ, ý , ç and ê, it would be hard (but possible) to include russian/cyrillic, and impossible to do kanji. How could such a problem be solved?

Max-Max

Quote from: Leartin on September 09, 2013, 09:02:50 AMMax-Max, you state that tte buttons shouldn't contain a pattern because they are to be resized. Can't you use them like a pattern, putting them next to each other instead of stretching them? I don't care too much about the buttons, because a pattern is distracting to the eye when text is involved. But it would be nice to have for scrollbars, which should have a similar 3x3 pattern for scaling. Arrow-buttons next to the scrollbars, too.
If you resize an GUI element in no-pattern-size increments, the pattern will only be half displayed in the end, not aligning up witht he border pieces. Let me illustrate with an example:



The first image is the 3 parts for a button; left middle and right.
In the second image the theme manager has concatenate them into one image and then divide it in a 3x3 grid (well, I have already come up with a better solution. I don't know if it will make it into the next patch although, so we stick to this meanwhile).
Lets assume we increase the width and height one pixel. Because the pattern is repeated every second pixel (2x2 pattern), only half the pattern will be displayed against the edge pieces; picture three.

To solve this my plan is to let the designer tell Simutrans the pattern size. Simutrans will then snap all scaling in multiples of the pattern size to ensure that full pattern is always displayed. But this will be further down the road, for now it will be misaligned if scaled.

Quote from: Leartin on September 09, 2013, 09:02:50 AMIs it planned to enable graphics in places where no graphics were used before, like titlebar, windowborder,... So that one could create a more rounded, modern look.
O'boy, do I have plans ;) First of all I need to get the theme structure in place and the first goal is to theme the GUI elements already skinned. My intention is to have virtually everything themed but this also requires a new GUI code structure. This will be the second step (new GUI code). Then we can start to do some serious themes ;)

Quote from: Leartin on September 09, 2013, 09:02:50 AMAbout Fonts... I looked into the Simutrans Font and it wouldn't be too hard to resize/recreate it at 1.5 or 2x scale. But that's only true for the latin alphabet, at least for me, because with kanji I just don't know what is intended to be round, straight,... Wouldn't the same problem arise with any font if it's pak dependant? While big names like Deja Vu might contain all the signs needed, most just don't. While I'd be eager to design my own bitmap font for Simutrans including multiple sizes and every œ, ý , ç and ê, it would be hard (but possible) to include russian/cyrillic, and impossible to do kanji. How could such a problem be solved?
I haven't looked so much at the font system yet, but as to my knowledge it uses both unicode and ASCII encoding.
If a glyph (an image used to build a character) is missing, Simutrans shows a default glyph in its place. The unicode fonts are capable of displaying virtually any character set. Well, traditional Chinese also used in Taiwan, Hong Kong and Macau use BIG5 encoding but the Kangxi radicals (214 Chinese characters) are reserved in the unicode character map U+2F00-2FDF.
If a font becomes popular any one can add the missing glyphs to the unicode font.

At my former work I wrote a couple of True Type to bitmap font converters. Due to copyrights and ownerships I can't publish them. As a parallel project I'm writing a new converter that will allow you to convert a TTF to bitmap font in one single button push. If and when this tools becomes useful, a localised character set can be taken from another font to create a more complete unicode font to use with Simutrans.

A professional True Type font has separate fonts for different styles; Normal, Bold, Italic etc...
When it comes to Simutrans we use the normal styled font and creates shadowed and outlined styles in the drawing process. I think this work quite well except for the outlined font. Maybe it is enough to adjust the algorithm...

In the discussions we have touched the subject of having two font sizes, one normal and one bigger for headlines etc...
But for now, we stick to what we have.
- My code doesn't have bugs. It develops random features...

Ters

Nine-part button images always seemed natural to me, but it is a good point that buttons with round ends don't scale with it. However, they don't scale well with raster graphics at all anyway. On the other hand, it might not be only GUI elements that need to scale on high-DPI devices, so those things get blocky anyway. I've seen a few flash games that also emulate low DPI, so maybe it will look trendy. I don't know how feasible it is for the theme manager to fully support both three and nine-part button skins. It might even have been easier to implement than the automatic cutting code.

Max-Max

#7
Quote from: Ters on September 09, 2013, 04:32:42 PMI don't know how feasible it is for the theme manager to fully support both three and nine-part button skins. It might even have been easier to implement than the automatic cutting code.
The theme manager manages theme objects, for now there are 3 kinds of them; Frame (9x9 approach), Horizontal (1x3) and vertical (3x1). We can easily add more object types and the manager can even select a specific type based on the artists specification.
For example, a button can be specified as a frame, scalable in all directions, or as a horizontal theme only scalable horizontally.

When I talk about scaling, I don't talk about image stretching. So for all scaling is done by extending the edge elements (tiling).
To address the resolution problem I have some ideas to use the same approach as Windows does with the icons. To store several versions of the same element and select the one with the best match in size.

But this doesn't exclude that we can add a theme object handling scaling by image stretching.
- My code doesn't have bugs. It develops random features...

prissi

The nine component button also does not allow to have a gradient from the to to the bottom, i.e. some 3D "light from above" effect. I think this is a very severe limitation for any button design, no pattern, no color ramp, now arbitary edges. Just look at the buttons on pak64.scifi


Markohs

Well, we can always add support for 24-bit depth images, that way gradient won't be needed. But that's not so easy.

Ters

Quote from: Max-Max on September 09, 2013, 07:34:14 PM
When I talk about scaling, I don't talk about image stretching. So for all scaling is done by extending the edge elements (tiling).
To address the resolution problem I have some ideas to use the same approach as Windows does with the icons. To store several versions of the same element and select the one with the best match in size.

But this doesn't exclude that we can add a theme object handling scaling by image stretching.

I think we all understood that, and simple linear scaling is what some themes may require. Multiple resolutions means yet another level of magic numbers, and less compatibility with existing themes.

Quote from: Markohs on September 09, 2013, 08:57:31 PM
Well, we can always add support for 24-bit depth images, that way gradient won't be needed. But that's not so easy.

Huh? Seems like you are confusing gradients with dithering or something.

Markohs


Max-Max

Quote from: prissi on September 09, 2013, 08:25:28 PM
The nine component button also does not allow to have a gradient from the to to the bottom, i.e. some 3D "light from above" effect. I think this is a very severe limitation for any button design, no pattern, no color ramp, now arbitary edges. Just look at the buttons on pak64.scifi
It is not a limitation, just don't define it as a framed themed button. Define it as a horizontal themed button. This will be possible further down the road. But as requested I do this in small steps. Don't forget that just because you can change the size, doesn't mean that you have to change the size. Gradient buttons could work okay if we have a theme object stretching the images.

Gradient designed buttons will face the same problem as round buttons. As Leartin pointed out:
Quote from: Leartin on September 09, 2013, 09:02:50 AM
Actually, prissi, you can design a skin with completely round buttons that is scaleable. The only issue is that once you scale it, the buttons aren't completely round anymore, however, they still work and won't look too bad. I think having resizable buttons is core to the idea of gui themes, after all, it's easy to create a skin pak and overwrite every pak with it, but that's not the point. The idea is to create more freedom in gui design, for pak-developers and users alike. If, as a pak-developer, you don't like it that your round buttons scale to be rounded buttons, just don't scale them, and they will look as intended. Sure, users might change it anyway to something that fits their need, but again, thats the point of the whole project and you can't force a user not to change anything even now.

Quote from: Ters on September 09, 2013, 09:24:16 PMMultiple resolutions means yet another level of magic numbers, and less compatibility with existing themes.

Multiple resolutions would be optional, hence backward compatibility. As I said, it was only an idea...
- My code doesn't have bugs. It develops random features...

prissi

I would not scale buttons: it will look either ugly or confine the artist. A theme should only work at its intended size for which it is made (and can made as pretty as possible). Actually that is the purpose of themes, or?

Max-Max

Quote from: prissi on September 09, 2013, 10:13:05 PM
I would not scale buttons: it will look either ugly or confine the artist. A theme should only work at its intended size for which it is made (and can made as pretty as possible). Actually that is the purpose of themes, or?
Okay, you will not scale buttons, good to know :thumbsup:
As long the user don't fiddle with the them.tab files, there is no button scaling, ta-daaaa!!!

This thread was meant to be for the artists and not to caught up in technical details. It seems like you have misunderstood the whole purpose of the project, even if you self added the theme.tab where button sizes can be overridden.

So what do you suggest? That we terminate the project? We already have themes in the skin-PAK and it seems like you are happy with it as it is, or? Is there anything in my work that you like?
- My code doesn't have bugs. It develops random features...

prissi

No I like the idea of themes, i.e. themes for tablets, themes for phones, several standard themes, themes for large contrast, themes for extra large screens. (That was why I found you button sizes in theme.tab very strange, as the images will anyway define a size.)

That all has nothing to do with sizes, at least no predominantly but with design. But creating too much from code one inhibits design. The artist is your friend in simutrans, not your enemy. We always had more artists than coders.

With this in mind: Give the artist freedom. (If the 9 buttons can be used as 3 buttons, i.e. only the top row contains the images and second and thrd row are empty, then both worlds may be happy.) But I strongly suggest a design, which not a priory removes all neat 3D-effect or button shapes from a designer, like a windows7 like button for instance.

EDIT: And yes, I would add an option to a theme to forbid simutrans to scale this theme ...


Max-Max

I really don't understand why we have this discussion at all... You only see imaginary potential constrains in a project that has just started. You have no idea what it will look like when it is finished. You only see small updates (because that is what you requested) and those make no sense because they are still in development.

The theme manager, that you are so much against, separates the GUI controls function from its look. The artist will give the rules for a certain control to the theme manager. I intend to give the artist as much freedom I can and still give the end user the possibility to tweak it to his/her needs.

As long no tweaking takes place, it is the artist's design that is shown.
If the artist wants to make a scalable theme, I'm sure he is competent enough to know what design will be suitable.

I'm sure that the end user is intelligent enough to see if a theme gets f#& up when scaled, but that is up to the end user, isn't it?
-Just because you can eat poison doesn't mean that you have to.

I really start to loose interest in this project...
- My code doesn't have bugs. It develops random features...

Yona-TYT

#17

Sometimes it is hard thinking differently :-[


@Max-Max, Go ahead with your project, take heart :thumbsup:


Are has devoted much time to this, we can not give up now :police:

Leartin

Sorry, it's just a quick job done with paint on a machine where every pixel needs 5 minutes to appear, but attached is the button prissi showed, how it would be cut, and how it looks when scaled to be bigger. Does it really look that bad? Its not like there can't be more than a shape filled with one color, even patterns are possible as long as they are not regular. In the worst case the middle of the button is an area of only one color, but don't forget that that's the place there text is.

Max-Max

Hello all artists.

I just want to do a poll with you guys. When designing for example buttons, in what way would you prefer to draw them.

Both attached pictures define the same button element as UP, DOWN and DISABLED.
Both variants look the same and behave the same in Simutrans.

So what do you prefer, image one (roundbutton.png) or the second one (button.png)?
- My code doesn't have bugs. It develops random features...

Max-Max

It doesn't seems like no one is reading this thread, but anyway...
I have made a decision about this project that can be read here.

I will continue to update this thread with progress and ask about what you artists wants, without any implementation details.
- My code doesn't have bugs. It develops random features...

An_dz

I did, but though I was not much of the "artist". But I prefer option 2, as you probably do as well.

kierongreen

Indeed - this isn't so much of a poll as a "I want to prove I'm right".

Ters

I believe that's what many polls are for.

Max-Max

Quote from: kierongreen on November 26, 2013, 08:44:47 PM
Indeed - this isn't so much of a poll as a "I want to prove I'm right".
Gee, I just wanted some artist input and a discussion from an artist perspective since the other thread is caught in technicalities.
- My code doesn't have bugs. It develops random features...