Constr.Site & Prod.Site: Dim House Picture In The Background

Bug #787365 reported by Astuur
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Widelands media development
Fix Released
Undecided
Unassigned
widelands
Fix Released
Low
Shevonar

Bug Description

While it is doubtless nice to see the house in question in the background of the contruction site
and the productions site window, this picture makes it hard to see and identify the wares that are
shown in the windows foreground. This is especialy true, when such wares are greyed out.
My suggestion is that the picture of the house should be assigned a 50 luminosity before blending it
into the window. The aim is to show the wares more clearly.
I have attached a montage to demonstrate the effect showing the empire Colosseum as an example.

Tags: ui
Revision history for this message
Astuur (wolfsteinmetz) wrote :
Revision history for this message
Hans Joachim Desserud (hjd) wrote :

I thought the houses in the background were already partially transparent, but I guess that was just wishful thinking on my part. I agree. Though, how is this implemented; is the changes done to the code or the building images? If the latter, will this affect how the buildings are displayed outside the dialogs or do we use a duplicate images, where one is transparent and the other isn't?

Just a bit off-topic: it's nice of you to use the tags to mark the bug report, but please try to stick to the official tags for the most part. :)

Changed in widelands:
importance: Undecided → Low
milestone: none → build17-rc1
status: New → Confirmed
tags: removed: background construction production site window
summary: - Constr.Site & Prod.Site: Dim House Picture
+ Constr.Site & Prod.Site: Dim House Picture In The Background
Revision history for this message
Alexia Death (alexiade) wrote :

I've always found the covered over building images there buggy/broke looking. I even filed a bug report once over the way they looked. Perhaps the building icon could be used? Aligned to bottom left corner of the window above the buttons?

Revision history for this message
Astuur (wolfsteinmetz) wrote :

Oops! Sorry - wasn't even aware that there is something like official tags (Where can I find those?)

There is a misunderstanding here. Luminosity is not transparency.
I don't know any other word for it in English - it's "Leuchtkraft" in German.
There is a HLS-System (Hue, Luminosity, Saturation) for defining colors, just like there is the RGB Sytem.
What I have done for the demonstration was simply to replace the normal building picture with one
that had its luminosity reduced by 50%.
That is of course no solution because the building would show dimmed inside the game.
My hope was, that some code could be written to reduce the picture's luminosity "on the fly" just before
mixing it into the window background.
The other approach is perfectly doable: generate a "dimmed" version of all the buildings, store it together with
Menu.png and Idle.png and use this.
I will gladly volunteer for this, if it is going to be this solution.

@Alexia: I don't understand. What exactly is broken or buggy for you?.
For me the pictures look fine, they are only too bright and obscure a clear view on the wares.

Revision history for this message
SirVer (sirver) wrote :

I agree with Alexia: The buildings are just somehow dropped in the background of the window: they are not properly aligned and are often clipped. En plus, they mostly only add clutter and impede the clearness of the windows. But they help recognizing which window is paired to which house. I would very much like to replace the buildings in the background without loosing the message.

Astuurs suggestion is a very good one to improve upon the situation, but it only lessens the pain I have with those pictures. I would love other suggestions.

Revision history for this message
Alexia Death (alexiade) wrote :

Long long ago I actually hacked up some code that aligned the images better... the code is now definetly bitrotted and lost, but I hink the key was aligning it to the bottom left corner and ignoring the hotspot.

Revision history for this message
Hans Joachim Desserud (hjd) wrote :

I think it helped to show the background images with 50% transpa... sorry luminosity. I don't really mind if the images are clipped by the window, but I can understand that some people do. Perhaps it would help to put the center of the image in the center of the window?

Another thing I thought about regarding placing the small build icon was to put it in the upper right corner, since the tabs leave that empty space anyway. However, unless it is made distinct enough people might mistake it for another tab, or make the window seem to cluttered.

Off-topic:
For the official tags, see the right side on https://bugs.launchpad.net/widelands/ . When I get round to it, I plan to write some documentation regarding bugs and the bugtracker.

Revision history for this message
Astuur (wolfsteinmetz) wrote :

Thanks HJD, always happy to learn more :)

I finally understood Alexia's woes -- it's the positioning she hates.
Personally I don't mind either - as long as I see enough to identify the building.
The advantage of not having the windows bigger than needed and dynamically reduce them,
seems more valuable to me than showing the house in question in full beauty.
But that's a matter of personal priorities and may even depend on the resolution that you use.

If the pictures cannot be dimmed or resized by the code for perfomance reasons, and we
should therefore need yet another png per house, I'd prefer to use the menu.png in some corner
of the window, but it would be loss.

Revision history for this message
Shevonar (shevonar) wrote :

Good news for all the graphic people: You don't need to make new pictures. Everything can easily be done by code.
At first I tried Astuurs suggestion: 50% luminosity and centered to the window. The picture will be clipped if the window is to small. To avoid clipping (if wished) we could ether make the window always big enough or scale the image down. I don't know what is simpler and looks better yet.
If you think it is necessary I will make a version with the picture in the top right corner of the window (though I think it might get very small).

Changed in widelands:
assignee: nobody → Shevonar (shevonar)
status: Confirmed → In Progress
Revision history for this message
SirVer (sirver) wrote :

Nice work! I can only reiterate what I stated in #5: I feel the images just distract from the content that the window should deliver. However, I understand that they somewhat help to link the window to the building. I am open for other suggestion how to get rid of them and keep the message.

Otherwise, the best we will be able to do is to fix the images as you are currently doing shevonar.

Revision history for this message
Astuur (wolfsteinmetz) wrote :

I believe that a picture of the house in question will be an advantage in any case, if it can be made dim enough not to interfere
with the more relevant window content.
My proposed 50% luminosity were just an example - we can go all the way to 15% or 10% and even combine it with transparency (though I think it will hardly be necessary).
I'm very much looking forward to Shevonar's solution and I am confident it will please most, if not all.

Revision history for this message
Shevonar (shevonar) wrote :

I also tried to combine reduced luminosity with transperancy before, but that makes the picture hardly recognisable (50% lum., 50% transp.). I've played around a bit more. Have a look at the attachement.

Revision history for this message
Alexia Death (alexiade) wrote :

Sofar the luminosity blends are still best IMHO, however, empire buildings are quite light. You should test this on the barbarian buildings like the woodcutter that are darker by nature.

Revision history for this message
Astuur (wolfsteinmetz) wrote :

I have a feeling that the real visibility problem is not with the background picture (which can be made quite unintrusive)
but with the fact that the wares, that are still missing, are (too) transparent, instead of being of reduced saturation, which might have a been a better choice.

Revision history for this message
Shevonar (shevonar) wrote :

Good notice Astuur. Now I know why you are a graphic artist and I am not. I had never thought of changing the wares queue transparency :S
I played around with the values again. The background image in this example is 30% luminosity 30% transparency. The wares images have been changed from greyed-out, 50% transperancy to greyed-out, 50% luminosity. I think we could use this but good ideas are always welcome :)

Side note: I tried to use the menu.png in the upper right corner, but that caused some trubble and some workarounds would be necessary. So I think the background picture is a cleaner solution (from a coders point of view).

Revision history for this message
Astuur (wolfsteinmetz) wrote :

Too much honor, Shevonar - my life's centered around natural science, and artwork I only did, because for a while all development in that field seemed so stagnant with WL and the need for it was so obvious. Level "Heimwerker" so to speak :)
But thanks anyway :)

Your values all seem to be a bit too far on the dark side for my personal taste.
I'll try to come up with my own values and show examples, okay.
So you can concentrate on the code side if you like. But if you want to go on with your own experiments, you may be faster.
I'm at it, but will need more time.
I learned from you that manupulating luminosity, transparency and saturation for the background pictures as well as the for
the wares is all "doable". Correct so far, I hope.
You can also in principle center and resize background pictures and determine the places for the wares and the priority radio buttoms,
and you can also of course control the size of the window independently from the rest.
That is a lot. I should be able to find a good solution..... asap

Revision history for this message
Shevonar (shevonar) wrote :

Thanks for your help Astuur. I'll see what I can do and - if I don't come up with something good - wait for your solution. Your assumptions about the capability of the code are all correct :)
The difficulty is to find values to have a good contrast between the wares and the background picture on the one hand and the background picture and the wooden background on the other hand. However I think you'll manage this problem.

Revision history for this message
Astuur (wolfsteinmetz) wrote :

Alright - I must confess that this was harder than I thought :)
Nonetheless there is a lot you can do, but not without some effort.
The challenge is to find settings that will suit _all wares_ and _all buildings_ and (and I forgot this part) the wooden background that we use. So the outcomes varies, even with uniform parameters, since the different shades influence each other.

I have not been over careful about the spacing and the size of the windows (I used some background that I still have
from my radically_new_all_inclusive_production_site_window_mockup).
The hole thing is and always will be a compromize, but it seems a better one than what we had so far.
Please ignore the binocular icon (I still had that in from the above named mockup)

I have worked on the same examples as Shevonar, namely the lightest and the darkest one.

The backround pictures are:
50% transparency, then +22% saturation, then +22% luminosity

The delivered wares are plain and unchanged.

The missing wares are:
50% transparency, -100% saturation, -35% luminosity.

Sorry this is so complicated - I would have rather stayed with one modifier, but there is a reason for this.
(some wares are "colorless" i.e. just greyshades).
If this is too much effort, it may be easier to find new graphics for marble, marble column, raw_stone etc.
I have not actually tested all wares through the whole process against the backgound, but tried to evaluate if they would make problems. I hope they don't.

It's all easier to see than to explain. Here is the colosseum
bye for today

Revision history for this message
Astuur (wolfsteinmetz) wrote :
Revision history for this message
Shevonar (shevonar) wrote :

I think I promised too much wenn I said the code can handle all these values without problems :S It is not only a lot of math, but also a question of your definition of saturation and luminosity. I have read a lot and found some interesting articles in german:
http://www.ralphaltmann.de/bibliothek/fotografik/pp_9907_040.pdf
http://www.ralphaltmann.de/bibliothek/fotografik/pp_9909_048.pdf
Except of the saturation increase for the background pictures I got everything working. The saturation increase is hard to implement in code and made the pictures "glow" too much in my opinion. I think the luminosity increase is enough.
See the results in the attachement.

Revision history for this message
Shevonar (shevonar) wrote :

I thought the missing wares were too hard to see with 50% transparency. That might be not that important cause you can see the priority buttons at the end of the line, but I made another example with no transparency.

Revision history for this message
Venatrix (elisabeth) wrote :

I see your point for reducing the transparency, but I feel it overdone. Can you try with perhaps about 25% transparency for the missing wares?

Revision history for this message
Shevonar (shevonar) wrote :

Sure!

Revision history for this message
Astuur (wolfsteinmetz) wrote :

Well, having found _one_ solution does not mean there are no other, or even superior solutions.
I think the first one (#20) is pretty good and would be my favourite.
Your latest ones are quite usable - but what I don't like (and so treid to avoid) is that
the absent wares appear more prominent (darker) then the present ones.
In some wares, that absence of color make the relation clear, in others, like the stones, it
sort of reverses the attention.
And as you said yourself - they don't need to be seen so clearly since all items in one row are the same
and they always have a priotity set at their end.

Revision history for this message
Shevonar (shevonar) wrote :

I pushed the version in #20 to trunk now. If you have new ideas feel free to open this bug report again.
Fixed in revision 6078.

Changed in widelands:
status: In Progress → Fix Committed
Changed in widelands-media:
status: New → Fix Committed
Revision history for this message
SirVer (sirver) wrote :

Released in build17-rc1.

Changed in widelands:
status: Fix Committed → Fix Released
Changed in widelands-media:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.