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.
Linked issues
Attachments
Comments 12
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?
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.
@unknown I specifically suggested that they let us texture pack it. That would let you go back to the old colors if you preferred them.
Now the durability bar doesn't turn red until the last pixel is left.
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.
@unknown 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...
@unknown I'm not the one that discovered that problem. Tell @unknown.
That's not the bug anyway. Mojang should let us texture pack the bar, since that's a solution that will please everyone.
This seems more like a suggestion instead of a bug. For feature suggestions or changes please see: Minecraft Suggestions on Reddit.