AGS Editor Color System (16-bit color properties problem)

[Snarky]

I'm having a lot of trouble figuring out how the color properties (for GUIs and character speech and probably some other things) work in the AGS editor.

First of all, I'm not able to set the full 24-bit range of colors, even though my game is running in 32-bit. For instance, I can't get pure white (255,255,255), it sets itself to (248,252,248), which is visibly green to my eyes on my screen. Also, I can't easily parse the ColourNumber property, apart from noticing that this "white" is 65535, or 2^16 - 1. So I take it the AGS colors are set in 16-bit, then? But is it really the case that you can't use pure white in 16-bit?

Second, the color palette you can use to set the colors don't match how they actually appear in the editor or game. The color that is called "black" and appears as black in the palette shows up as pink in the editor and transparent in the game. On the other hand, the color called "transparent" in the palette shows up as this pseudo-white. I'm guessing the palette colors and names are some sort of Windows standard that doesn't match what AGS does internally.

Umm... I guess in trying to explain my incomprehension I've more or less figured out what's going on, but I still think it's horribly confusing and probably broken. Currently neither of the two most fundamental colors in the whole palette, black and white, are available to anything you set the color of with the editor. And the mismatch between the RGB value of AGS "white" and the white in imported sprites (as well as between the darkest gray and the black in imported sprites) causes ugly artifacts in games that I've never been able to explain before.

Is there some sort of workaround for this problem? And would it be possible to move to 24-bit color for these properties, at least in 32-bit games?

Also, I'm wondering if the 24-bit representation of the 16-bit color values is handled by AGS or by the OS/screen card, because I suspect that the mapping is off. It seems as if it's just taking the 5-6-5 representation and shifting each channel 2 or 3 bits left, which means you are going to lose the top part of the range. That's why white comes out as (248,252,248). To correct for this, you should add another term to the 24-bit value:

r_24 = (r_16 << 3) + (r_16 >> 2)
g_24 = (g_16 << 2) + (g_16 >> 4)
b_24 = (b_16 << 3) + (b_16 >> 2)

(The logic is that you take the missing values that comes from not filling the lower bits and distribute them equally along the range, instead of just at the top. So if the 3 lowest bits are missing, you distribute those 2^3 = 8 values across the 5-bit range (32 values) you had. 8/32 = 1/4, so you shift right 2. Similarly, if the 2 lowest bits are missing, you get 4/64 = 1/16, so you shift right 4.)

Do this, and color 65535 (0xFFFF), white, comes out as (255,255,255 or 0xFFFFFF) as desired. No more green-white!

Edit: It might be easier and a bit more accurate, though slower, to simply convert the range. In AGS script:

r_24 = Maths.FloatToInt(Maths.IntToFloat(r_16)*255.0/31.0, eRoundNearest);
g_24 = Maths.FloatToInt(Maths.IntToFloat(g_16)*255.0/63.0, eRoundNearest);
b_24 = Maths.FloatToInt(Maths.IntToFloat(b_16)*255.0/31.0, eRoundNearest);

[Calin Leafshade]

Yea, this is a problem.

Really AGS should abstract this out to its own color class so that all colours were represented as an object.

like:

Code: ags

Color c = Color.FromARGB(r,g,b,a);
c.Red = 42;

The reason you cant see the full 24-bit colour space is that AGS Colours seem to work in a 16-bit colour space as a relic from the past.

This does need an update i think to reflect modern systems since 32-bit colour seems to be something of a hack on top of the 16-bit code.

[Khris]

To solve the white problem until this is fixed, use color 15, that's 252,252,252.