[suggestion] A possible low-cost implementation of custom UI colors

[updated] I've tweaked my code, to better preserve variations of hue.

Given FD's reluctance to implement the much-requested custom HUD colors, I'm assuming that the UI elements are drawn in orange in various bitmaps which are combined via overlays to produce what we see in game. That is, the HUD colors are "baked" into the UI bitmaps, something like this:

K3E3SYc.png


Because the colors are part of the artwork, the orange stuff can't be changed without changing the hue of the other elements. Assuming that's true, you just need to filter out the orange pixels and modify only those.

You can add a UI color option (dropdown list of color names) to the graphics settings, which will apply the custom UI colors to the assets when they are first loaded. The UI colors would not change until the assets are reloaded. This would mean that the changes are localized and shouldn't affect other elements in the game, like the faces in the mission board or hair color in Holo-Me.

If there are some UI images which shouldn't be filtered, you could add an exclusion list or store them in a separate "don't touch" folder.

Here's a sample implementation.

Code:
bool PostLoadUiBitmapColorAdjustment( CBitmap* bmp, int newHue, int newSaturation )
{
 int uiOrangeHue = 30; // might change, depends on HLS implementation
 int epsolon = 5;    // small delta, to handle slight variations of orange - tweak as needed
 bool didAnyPixelChange = false;
 // scan each pixel
 for ( int x=0; x < bmp->width(); x++)
 {
  for ( int y=0; y < bmp->height(); y++)
  {
   RGB rgbPixel = GetPixel( bmp, x, y);
   int hue, lightness, saturation;
   GetHLSfromRGB( rgbPixel, &hue, &lightness, &saturation);
   if ( (uiOrangeHue-epsolon <= hue) && (hue <= uiOrangeHue+epsolon) )
   {
    // I noticed there are subtle shades of orange, offset newHue to preserve slight hue variations
    int pixelHue = newHew + hue-uiOrange;

    didAnyPixelChange=true;
    rbgPixel = GetRGBfromHLS( pixelHue, lightness, newSaturation);
    PutPixel( bmp, x, y, rgbPixel);
   }
  }
 }
 return didAnyPixelChange;
}

This implementation can provide UI in any hue and even provides White, which is Saturation==0. If there is a problem with the orange matching colors it should not, you can increase the filter specificity by adding saturation and/or lightness limits to the filter.

Here's a possible list of UI colors, which can easily be exended:
Red: Hue = 0; Saturation=255
Orange: 30; 255
Yellow: 60; 255
Green: 120; 255
Aqua: 180; 255
Blue: 240; 255
Magenta: 300; 255
White: Hue=0; Saturation=0

There are other color possibilities, such as Pale Blue: 240; 100

See https://en.wikipedia.org/wiki/HSL_and_HSV for more details.

*Update* I just realized that I didn't mention that the GetRGBfromHLS() function needs to handle hues less than 0 and greater than 360, by wrapping them back into range the range 0..360.
 
Last edited:
Since this issue is continuing to generate complaints in the Dangerous Discussions forum, I thought I'd bump this thread, so it has a better chance of getting fixed for the upcoming quality-of-life improvements. Also, I've updated the code, to better preserve hue variations.
 
+1.

This would be great for VR users. The current orange works poorly in VR due to the nature of the headsets. Green is best, but the current method of changing the colour matrices in XML means the other colours all change at the same time. The worst part is the radar where you largely lose friendly/enemy/neutral differentiation.

You may think NW3's suggestion is just a QoL improvement, but it's actually a pretty big issue for many (not all) VR users. As evidence, look at all the time and effort gone into providing VR-friendly colour matrices to date.
 
  • Like (+1)
Reactions: NW3
Is there anyway to test the idea?

I've previously looked through the on-disk assets, but didn't find anything that I could use to verify this.

As a senior software engineer, who developed a couple of games a long time ago, this is the most likely scenario, in my opinion.

The other possibility is that there is code all over the UI that individually sets the various shades of orange directly (as RGB(255, 128, 0) and such), instead of using a variable, like rgbUI. I think that's less likely, because (while it could be a fair bit of work to track those down) it's poor programming practice and it wouldn't be nearly as big an issue to fix (as pre-baked asset colors). In this second scenario, I think the effort is low enough (and the demand is high enough) that the UI colors would be customizable (without affecting the radar colors) by now if this were the case.

I'm unable to think of a third scenario that would fit the known facts.

Also, my code be could easily be repurposed to recolor other bitmap assets, like ship paintjob colors, flight suit colors, etc. All you'd need to do is make a colored source bitmap (using, for example, red as primary and green as secondary) and pass in 1 or 2 new input hue arguments (to replace uiOrangeHue with primaryHue and secondaryHue) and change the if-statement in the inner loop to...

Code:
   if ( (primaryHue-epsolon <= hue) && (hue <= primaryHue+epsolon) )
   {
    int pixelHue = newHew + hue-primaryHue;

    didAnyPixelChange=true;
    rbgPixel = GetRGBfromHLS( pixelHue, lightness, newSaturation);
    PutPixel( bmp, x, y, rgbPixel);
   }
   else if ( (secondaryHue-epsolon <= hue) && (hue <= secondaryHue+epsolon) )
   {
    int pixelHue = newHew + hue-secondaryHue;

    didAnyPixelChange=true;
    rbgPixel = GetRGBfromHLS( pixelHue, lightness, newSaturation);
    PutPixel( bmp, x, y, rgbPixel);
   }
 
Last edited:
There has been a way on PC to change to UI colour to suit your individual preferences relatively easily for a while (e.g. http://arkku.com/elite/hud_editor/), although as mentioned above it does screw up some UI elements like faces, holo-me, etc.

A lot of people have been asking for an easy way to change the UI colour in game and I think it's time now for the devs to start looking at an in game solution that can be implemented on all platforms so us console players can make use of this feature too.

 
There has been a way on PC to change to UI colour to suit your individual preferences relatively easily for a while (e.g. http://arkku.com/elite/hud_editor/), although as mentioned above it does screw up some UI elements like faces, holo-me, etc.

.............

Not if you pick the right one. I use the mocha one and it is great, keeps the radar icons and faces are ok too.

P.S. If you stick your sig graphic in your BB sig option (settings / edit signature) it will save you pasting it in every time.
 
Last edited:
I guess the problem runs deeper than that, it's going to be a long while before the HUD color issue is going to get addressed

For now, we are going to stick with tricks and tweaks to customize our Interface.
 
Leviticus is an old obsolete bitter man.
He has no idea what an informed and civil discussion is. And he can't anymore.

I think this is an interesting thought worth resurfacing for those who haven't been around 2-3 years ago to see it.
Would copying this suggestion, and reposting it, balance the humors? I see no point.

I'm also wondering, can the coloring of an interface be hardcoded so deeply so you have to utilize some sort of processing to flush the whole thing pixel by pixel?

As I've said, I don't think "necroposting" should be avoided like a plague and I see no harm in it.
Maybe I'm somehow mistaken, if so - I apologize.
 
I dunno what's worse about necro-posts...

That they remind you how old some issues are...and that they aren't resolved...
Or that they remind you how often some issues are raised...and that they aren't resolved.

I've been playing Elite since it launched on PS4 (so not very long).
It never ceases to amaze me how old certain (many) issues are with this game.

It's like FDev doesn't know how to maintain/service a product...only bolt on more stuff.
 
Back
Top Bottom