MC-104901Suboptimal visibility and horrific look of the tool's durability bar colors
The durability bar fades from green to red using a linear fade in the RGB colorspace. This results in a horrific 50% brown color for 50% durability, which both looks bad, and suffers in terms of visibility. The entire point of this bar is to convey information to the player, having to squint to even see it is a disappointing shortcoming in terms of UI design.
Instead, I propose fading in the HSV colorspace, like we know how color works, and pinning saturation and value to 100% and spinning the hue knob, resulting in the colors in the 2nd, 3rd, and 4th row of the attached image.
Related: the third and fourth rows of the attached image also do away with the weird pointless second box drawn in the damage bar which further obscures the data the bar is meant to convey.
Also related: Everyone I've asked prefers the 3rd row (with the thin bar) over the 4th row (with the double-thick bar), but nobody can tell me why.
In any case, if you need code to transform colorspace from HSV to RGB, you can google it, but there are more efficient ways to do it for this simple (and singular) application. A lookup table, for example. It would only be 256 (or 13) entries (depending on choices made). Alternatively, you could just let us define the bar graphics in a resource pack, with a new 256x16 (both 2^N) texture.
Here's to being able to read durability bars in the future.
Environment
All
Linked Issues
MCPE-162814Attachments1
Created Issue:
Durability bar colors are horrible.
The durability bar fades from green to red using a linear fade in the RGB colorspace. This results in a horrific 50% brown color for 50% durability, which both looks bad, and suffers in terms of visibility. The entire point of this bar is to convey information to the player, having to squint to even see it is a disappointing shortcoming in terms of UI design.
Instead, I propose fading in the HSV colorspace like we know how color works, and pinning saturation and value to 100% and spinning the hue knob, resulting in the colors in the 2nd, 3rd, and 4th row of the attached image.
Related: the third and fourth rows of the attached image also do away with the weird pointless second box drawn in the damage bar which further obscures the data the bar is meant to convey.
Also related: Everyone I've asked prefers the 3rd row (with the thin bar) over the 4th row (with the double-thick bar), but nobody can tell me why.
In any case, if you need code to transform colorspace from HSV to RGB, you can google it, but there are more efficient ways to do it for this simple (and singular) application. A lookup table, for example. It would only be 256 (or 13) entries, (depending on choices made). Alternatively, you could just let us define the bar colors in a resource pack, with a new 256x16 (both 2^N) texture.
Here's to being able to read durability bars in the future.
Environment
All
Attachments1
The durability bar fades from green to red using a linear fade in the RGB colorspace. This results in a horrific 50% brown color for 50% durability, which both looks bad, and suffers in terms of visibility. The entire point of this bar is to convey information to the player, having to squint to even see it is a disappointing shortcoming in terms of UI design.
Instead, I propose fading in the HSV colorspace like we know how color works, and pinning saturation and value to 100% and spinning the hue knob, resulting in the colors in the 2nd, 3rd, and 4th row of the attached image.
Related: the third and fourth rows of the attached image also do away with the weird pointless second box drawn in the damage bar which further obscures the data the bar is meant to convey.
Also related: Everyone I've asked prefers the 3rd row (with the thin bar) over the 4th row (with the double-thick bar), but nobody can tell me why.
In any case, if you need code to transform colorspace from HSV to RGB, you can google it, but there are more efficient ways to do it for this simple (and singular) application. A lookup table, for example. It would only be 256 (or 13) entries
,(depending on choices made). Alternatively, you could just let us define the bar colors in a resource pack, with a new 256x16 (both 2^N) texture.Here's to being able to read durability bars in the future.
The durability bar fades from green to red using a linear fade in the RGB colorspace. This results in a horrific 50% brown color for 50% durability, which both looks bad, and suffers in terms of visibility. The entire point of this bar is to convey information to the player, having to squint to even see it is a disappointing shortcoming in terms of UI design.
Instead, I propose fading in the HSV colorspace, like we know how color works, and pinning saturation and value to 100% and spinning the hue knob, resulting in the colors in the 2nd, 3rd, and 4th row of the attached image.
Related: the third and fourth rows of the attached image also do away with the weird pointless second box drawn in the damage bar which further obscures the data the bar is meant to convey.
Also related: Everyone I've asked prefers the 3rd row (with the thin bar) over the 4th row (with the double-thick bar), but nobody can tell me why.
In any case, if you need code to transform colorspace from HSV to RGB, you can google it, but there are more efficient ways to do it for this simple (and singular) application. A lookup table, for example. It would only be 256 (or 13) entries (depending on choices made). Alternatively, you could just let us define the bar colors in a resource pack, with a new 256x16 (both 2^N) texture.
Here's to being able to read durability bars in the future.
Durability bar colors are horrible.Suboptimal visibility and horrific look of the tool's durability bar colors
![[Mojang] Agnes Larsson](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Agnes LarssonThe durability bar fades from green to red using a linear fade in the RGB colorspace. This results in a horrific 50% brown color for 50% durability, which both looks bad, and suffers in terms of visibility. The entire point of this bar is to convey information to the player, having to squint to even see it is a disappointing shortcoming in terms of UI design.
Instead, I propose fading in the HSV colorspace, like we know how color works, and pinning saturation and value to 100% and spinning the hue knob, resulting in the colors in the 2nd, 3rd, and 4th row of the attached image.
Related: the third and fourth rows of the attached image also do away with the weird pointless second box drawn in the damage bar which further obscures the data the bar is meant to convey.
Also related: Everyone I've asked prefers the 3rd row (with the thin bar) over the 4th row (with the double-thick bar), but nobody can tell me why.
In any case, if you need code to transform colorspace from HSV to RGB, you can google it, but there are more efficient ways to do it for this simple (and singular) application. A lookup table, for example. It would only be 256 (or 13) entries (depending on choices made). Alternatively, you could just let us define the bar
colors in a resource pack, with a new 256x16 (both 2^N) texture.Here's to being able to read durability bars in the future.
The durability bar fades from green to red using a linear fade in the RGB colorspace. This results in a horrific 50% brown color for 50% durability, which both looks bad, and suffers in terms of visibility. The entire point of this bar is to convey information to the player, having to squint to even see it is a disappointing shortcoming in terms of UI design.
Instead, I propose fading in the HSV colorspace, like we know how color works, and pinning saturation and value to 100% and spinning the hue knob, resulting in the colors in the 2nd, 3rd, and 4th row of the attached image.
Related: the third and fourth rows of the attached image also do away with the weird pointless second box drawn in the damage bar which further obscures the data the bar is meant to convey.
Also related: Everyone I've asked prefers the 3rd row (with the thin bar) over the 4th row (with the double-thick bar), but nobody can tell me why.
In any case, if you need code to transform colorspace from HSV to RGB, you can google it, but there are more efficient ways to do it for this simple (and singular) application. A lookup table, for example. It would only be 256 (or 13) entries (depending on choices made). Alternatively, you could just let us define the bar graphics in a resource pack, with a new 256x16 (both 2^N) texture.
Here's to being able to read durability bars in the future.
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
relates to
The durability bar on Bedrock edition has a worse look comparated to the Java Edition's one, the shading of the green pixels to red are worse and it is also harder to notice the colored pixels because they get darker as the durability decreases.
Why this should be fixed:
This has already been reported and fixed on java (MC-104901) and would give better visibility, brighter colors and better accuracy to the damage bar.
Curiously, the durability bar was also updated on Legacy Console editions, but not on bedrock itself. This is sad because the durability bar is hard-coded and cannot be edited with texture packs.
This seems more like a suggestion instead of a bug. For feature suggestions or changes please see: Minecraft Suggestions on Reddit.
If I were suggesting that the bar be added, I'd agree with you. But I'm not suggesting that. I'm saying that the bars fade from green to red using the wrong colorspace. Which makes it a bug. It's also been this way since indev, which ranks it right up there with bug #4, IMO.
On the thin line between bug report and feature request it's in fact more the latter (it's deliberatly coded the way it works), but leaving this ticket open.
I have asked notch to comment on this issue, but until he does, or if he does not, let's examine the possibilities.
1) notch sat down and thought, and intentionally decided to make the durability bar nearly invisible at 50% and nearly unnoticable at 0%
2) notch didn't know how to do a HSV to RGB colorspace conversion
3) notch didn't understand why an HSV to RGB colorspace conversion was useful here
4) notch was busy, distracted, or lazy, when he wrote this code, and just did an RGB colorspace linear crossfade because it's faster to write.
Let's look at what those four options say about notch.
1) notch is a dick who enjoys screwing users. Works as intended.
2) notch is ignorant and can't work the google. Bug.
3) notch is incompetent and doesn't understand color. Bug.
4) notch was writing an entire game by himself, and decided that the durability bar wasn't important enough (at that moment) to write correctly. Bug.
So until notch himself shows up and tells you it's #4, what would you like to say happened again?
You won't get any answer from Notch since he's left Mojang several years ago.
He wrote the original code and he's capable of commenting here, same as anyone else. He's the only one that can tell you with 100% certainty why it works how it does.
Personally, I like the original. I think the fixed version is too noticeable, and it doesn't give that much information, anyway. Also, I've never experienced having to squint in order to see it. I also like the original one because it looks dirty, as if a used tool, rather than some arbitrary bright colours that people have learnt to associate with traffic lights, and I especially don't like the yellow, which from memory is supposed to be the most noticeable colour to humans or something. The yellow stands out way more than the other colours, especially the red which is the most important one to pay attention to.
That's just my two cents though.
Now the durability bar doesn't turn red until the last pixel is left.
This wasn't a bug to begin with, and now it's worse than before.
Krev I specifically suggested that they let us texture pack it. That would let you go back to the old colors if you preferred them.
This is not a fix, this is replacing one bug with another. I support creating a new bug to get them to fix it properly.
Logan Langrish I have no idea how to make red more visible, but if they'd let us texture pack it like I suggested, you could have a solid bar instead of a shrinking one that isn't even visible until it turns fully red at 5 or 10% durability.
Mojang - Please fix this properly, come on...
Pegasus Epsilon, please create a new bug report about that last pixel issue.
Kumasasa I'm not the one that discovered that problem. Tell Logan Langrish.
That's not the bug anyway. Mojang should let us texture pack the bar, since that's a solution that will please everyone.
Can the durability bar use the XYZ colorspace instead? It's very similar to RGB^2.