[NOT] Just Another UI

[av93]

35 minutes ago, Shiyn said:

Tbh i like the logo as it is, i just think the letters are too spread , and the dots are a little too proeminent. Also the bevel in the 0 cross seems a bit too obvious.

Much better! The main background doesn't have sense (hoplites standing in a middle of siege?). The four icons look nice, but they aren't intuitive to know what they mean. BTW there should be a consistent theme across all game and UI.

Edited April 24, 2018 by av93

[Shiyn]

Quote

Much better! The main background doesn't have sense (hoplites standing in a middle of siege?). The four icons look nice, but they aren't intuitive to know what they mean

Lol i could handle the hoplites, im more worried about the might ox they brought to the siege. Who need rams anyway. XD

 

[Nescio]

20 minutes ago, vladislavbelov said:

I mean, doesn't the Fedora support the screen division in a different proportion? And why you don't use a lower scale, i.e. 1.5?

Yes, Fedora can also support arbitrary sizes, of course. Half a screen is just more convenient for me personally (pressing two keys is much faster than resizing a window by moving around a cursor or having to look up a configuration file to specify a size in pixels). And yes, I suppose I could use 1920/1024=1.875 as gui scale. However, that's besides the point.

What matters is the mock-up is 1920×1080, 0 A.D.'s current GUI's width 1024. If the GUI is to be redesigned, it's important to keep in mind that not everyone has the same resolution screen, and some of those who could support it might want to play the game in a different size too. Just extending the used width from the current 1024 to 1280, 1600, 1920, or whatever might be welcomed by some but be inconvenient for others.

[OptimusShepard]

 

17 hours ago, Shiyn said:

Really nice work. One request, could you please put the resources to the middle or find another place which is not on the side? I think if we redesigne the UI, we should also care about ultrawide displays like 21:9. The current UI doesn't support this well, its very incovenient if you strongly have to look to the left.

[Shiyn]

Quote

Nescio said:

True, there is no point on implementing this if it cant support native 4:3 resolutions. Would act as a mod for those who want it but it will never make it to the main build. 
Actually my earlier design took this into consideration, since i left half screen alone for scretching and cropping, but since we added the left bar now were locked up on 16:10 logic. 
Ill give some thought about the options we have here before going deeper with this.

Nonetheless, heres the last iteration with some of WowGetOff additions.

Edited April 24, 2018 by Shiyn

[vladislavbelov]

3 minutes ago, Nescio said:

What matters is the mock-up is 1920×1080, 0 A.D.'s current GUI's width 1024. If the GUI is to be redesigned, it's important to keep in mind that not everyone has the same resolution screen, and some of those who could support it might want to play the game in a different size too. Just extending the used width from the current 1024 to 1280, 1600, 1920, or whatever might be welcomed by some but be inconvenient for others.

Yeah, I definitely agree with that. And I think the 1024 width is enough to use for a while.

I worried mostly about the scale for the engine. Because we have issues with that: 1) we don't support scaled fonts yet, 2) we don't support system DPI, no DPI aware yet (i.e. Windows on 125% just scale the game).

[Shiyn]

2 minutes ago, OptimusShepard said:

 

Really nice work. One request, could you please put the resources to the middle or find another place which is not on the side? I think if we redesigne the UI, we should also care about ultrawide displays like 21:9. The current UI doesn't support this well, its very incovenient if you strongly have to look to the left.

Yea, this was constantly bugging me even on 1080x. I like the idea of leaving it on the top bar but it should be a overlayed frame centered in the top left corner zone imo. I didnt touched the top bar and its concept yet but i may look into this.

[vladislavbelov]

3 minutes ago, Shiyn said:

True, there is no point on implementing this if it cant support native 4:3 resolutions. Would act as a mod for those who want it but it will never make it to the main build. 
Actually my earlier design took this into consideration, since i left half screen alone for scretching and cropping, but since we added the left bar now were locked up on 16:10 logic. 
Ill give some thought about the options we have here before going deeper with this.

Nonetheless, heres the last iteration with some of WowGetOff additions.

@Shiyn

1. Is it possible to make the palette a little bit warmer?

2. Is the bug from your screenshot reproducible:

?

[Shiyn]

Just now, vladislavbelov said:

@Shiyn

1. Is it possible to make the palette a little bit warmer?

2. Is the bug from your screenshot reproducible:

?

Hehe, this was happening since i couldnt find an option to override X, Y and Z values on the Atlas object panel. So i had to manually make the ground elevations inside some structures to set the height right. That can cause some elevation differences wich lead to this bug. What you mean by palette?

[Nescio]

14 minutes ago, Shiyn said:

True, there is no point on implementing this if it cant support native 4:3 resolutions. Would act as a mod for those who want it but it will never make it to the main build. 
Actually my earlier design took this into consideration, since i left half screen alone for scretching and cropping, but since we added the left bar now were locked up on 16:10 logic. 
Ill give some thought about the options we have here before going deeper with this.

Height is not a problem; if something works for 16:9, it will also work for 16:10, 3:2, 4:3, 5:4, and other aspect ratios. Width, in pixels, is the limiting factor. 0 A.D.'s GUI does not handle "stretching and cropping"; it's always 1024 pixels wide, regardless the size of the screen or window used. So if you want to implement your ideas, it's better if all GUI elements are located within 1024 pixels, even if your mock-up's 1920 wide.

19 minutes ago, vladislavbelov said:

Yeah, I definitely agree with that. And I think the 1024 width is enough to use for a while.

I worried mostly about the scale for the engine. Because we have issues with that: 1) we don't support scaled fonts yet, 2) we don't support system DPI, no DPI aware yet (i.e. Windows on 125% just scale the game).

Those two things are certainly desireable to have, but probably also quite hard to implement.

[Shiyn]

Quote

Nescio said:

I see what you mean. So isnt a matter of rescaling but keeping it tight to 1024. Thats surely a challenge for the current design,  the only way it would work would be to remove the portrait radial from middle and put it on the right side and redraw the minimap concept. I kinda tempts me to experiment with it but i wanna make this one something near consistent so i can move on. 

[Nescio]

2 minutes ago, Shiyn said:

I see what you mean. So isnt a matter of rescaling but keeping it tight to 1024. Thats surely a challenge for the current design,  the only way it would work would be to remove the portrait radial from middle and put it on the right side and redraw the minimap concept. I kinda tempts me to experiment with it but i wanna make this one something near consistent so i can move on. 

You could design a 1920 wide GUI, of course, that's up to you, but that would only be useful as a mod for players who would play 0 A.D. at at least that width.

If you want to redesign the GUI and create a mod that might be included in the main distribution and replace what we currently have, then yes, I'm afraid you'll have to limit yourself to using 1024 pixels, which is certainly challenging.

[Shiyn]

Oh yea, im with you one this one, think its around the very philosophy of 0AD to work on most plataforms and their various rigs. What i mean is, before i reshape this or even scratch a new concept i wanna be done with this one first, regardless of how i would implement it.  Tbh the last concept made it a bit too complex, i feel like this is getting beyond my ability to code it, haha.

 

[vladislavbelov]

17 minutes ago, Nescio said:

0 A.D.'s GUI does not handle "stretching and cropping"; it's always 1024 pixels wide, regardless the size of the screen or window used.

It's not actually true. GUI support stretching by setting a size in percentage in XML. A more complicated logic can be implemented in JS. But it's not easy and pretty hard to maintain it. So, I can say, it presents, but it's not ready to use freely.

38 minutes ago, Shiyn said:

Hehe, this was happening since i couldnt find an option to override X, Y and Z values on the Atlas object panel. So i had to manually make the ground elevations inside some structures to set the height right. That can cause some elevation differences wich lead to this bug.

Could you post your changes for this?

38 minutes ago, Shiyn said:

What you mean by palette?

A color set.

[Shiyn]

4 minutes ago, vladislavbelov said:

Could you post your changes for this?

A color set.

You mean in the /public code? Or the elevations? By the code, i didnt changed anything, just used the Atlas as it is. About the elevations, well, i can post them without any buildings so you could have a idea of the mess



Added new icons for the bug and translate buttons. ^^

Oh, and sure, i can give a go with a bit more warmish tone for the stone lightning

[vladislavbelov]

8 minutes ago, Shiyn said:

You mean in the /public code? Or the elevations? By the code, i didnt changed anything, just used the Atlas as it is.

I mean changes that lead to the bug with blue edges.

[Shiyn]

Just now, vladislavbelov said:

I mean changes that lead to the bug with blue edges.

Sure. Isnt hard to replicate with the current elevations; adding a building that increase your borders usually lead to it when passing over pointy terrain.

Here is one example:







The collision between the tower and fort borders shaped over the uneven terrain made it bug, i guess.

[Shiyn]

The map file if you feel like looking into this any further. > Map

[aeonios]

I think the formations panel should have its own border. Being only half-connected to the unit info panel looks bad.

[fabio]

On 4/24/2018 at 4:27 PM, vladislavbelov said:

2. Is the bug from your screenshot reproducible:

?

There is already a ticket for this: #919. Also #1229 is related.

[vladislavbelov]

3 hours ago, fabio said:

There is already a ticket for this: #919. Also #1229 is related.

I think so too, but I have few suspicions, so it can be the same or a kind of the same. Or it can be something unrelated.

[Stan`]

@temple submitted a fix for those ( which is a redesign of the territory system) but fixes that.

[wowgetoffyourcellphone]

Can u post just the UI layer/s? I wouldn't mind attempting to make a 1024 compatible version.

[OptimusShepard]

On 4/24/2018 at 4:25 PM, Shiyn said:

Yea, this was constantly bugging me even on 1080x. I like the idea of leaving it on the top bar but it should be a overlayed frame centered in the top left corner zone imo. I didnt touched the top bar and its concept yet but i may look into this.

Thx. Could you please also have a look on the minimap. On your designe it's fixed to the left border. May you could change the left side of it (minimap)? So if you change from 16:9 to 21:9 the map will stay more to the middle and is not fixed on the border. Everything which is fixed to the right or left border isn't very well for ultrawide resolution.

[wowgetoffyourcellphone]

@Shiyn Any chance you can post the photoshop file?