Pale Coloured Text

[stepsoversnails]

Hello!
So I have an issue with the colour of my speech text and message text. It's too pale!
For example, I'll set my characters speech colour to red (255, 000, 000) but when it shows on screen it's (255, 80, 80).
Here's the comparison:

I've tried everything! I've tried different fonts and made the colours darker to compensate but nothing works.
It might seem like I'm nit-picking but this is pretty important to me.
Any advice?

[Gurok]

Hrmmm... this is a bit of a guess, but you might have a gamma setting or colour profile interfering with AGS.
You could try adjusting the in-game gamma (System.Gamma), but it is best not to specify gamma and leave it user adjustable.
Try browsing your video card settings and ensure Gamma is 1.00 or 2.20 (depending on the scale used).
Try also removing any colour profiles and using sRGB if it's available.
Is this by any chance a low colour game (256 colours or 16-bit colour)? AGS might be choosing the nearest available colour.

Edit: CW is right. You should check the colour depth first. There's a default palette entry near those colour values.

[Crimson Wizard]

Is this by any chance a low colour game (256 colours or 16-bit colour)? AGS might be choosing the nearest available colour. Ignore this. I think you'd notice in the editor if that were the case.

Actually the color depth is the first question to ask in a case like this.

On other hand, 16-bit games can't set 255;0;0, in properties they set 248;0;0.

I would like to ask, how do you know it shows as (255, 80, 80)? Have you made a screenshot and checked in a graphics editor? This to make sure it is the game that draws it like 255;80;80.

[stepsoversnails]

My Gamma settings are fine and my game running in 32-bit (true-colour). I actually have an item in my game that is coloured with 255, 0, 0. That's how i noticed the pale text in the first place. and yeah i screen capped it to check what the RGB value was. It's of course not just the red that comes out pale in the text. it's any colour i set it to.
At the risk of unveiling my game early, here's a screen cap of the issue i'm facing:

I tried setting my game to 8-bit and the text showed as the right colour. it's pale in 16-bit, though.

[Crimson Wizard]

This color is actually a default speech color set when you create a new character.
EDIT: Sorry, did not notice the "not just the red that comes out pale in the text. it's any colour i set it to."
How do you set the speech color exactly?

I wonder, is there a setting in AGS that reduces the font brightness which I don't remember about?

[Snarky]

For things like speech color, AGS uses a "color number" instead of standard RGB values. (This is some bullshit we're stuck with for legacy reasons, or to support 8-bit games, I assume.) And some colors are reserved, for some unfathomable reason, so you can't use them. Or at least you can't set them in the editor; or maybe it's just that the editor's conversion from RGB to color number is wrong in some cases. In any case, it's a pain in the ass, and not well documented.

Try setting it in-game with yourCharacter.SpeechColor = Game.GetColorFromRGB(255,0,0);

Edit:
Description of how the color limitations in AGS work: http://www.adventuregamestudio.co.uk/forums/index.php?topic=43311.msg575738
Monkey's Workaround: http://www.adventuregamestudio.co.uk/forums/index.php?topic=43966

[Crimson Wizard]

I know that is generally true what Snarky sais (about 16-bit colors), but I am confused by the fact that it works well for me.
I created a 16-bit game, put 255;0;0 in the properties, Editor fixed it to 248;0;0. When I made a screenshot in game and opened it in image editor, it indicated that the text color is 255;0;0.

Thing is that the difference stepsoversnails having in his example is way too much to be mere color number imperfection.

[Snarky]

Yes, but stepsoversnails is working in 32 bit. Edit: I missed the bit where he/she says the problem also occurs in 16 bit.

I can't swear that this is the cause of the problem (I never worked out exactly which colors are corrupted), but it seems awfully likely.

[Crimson Wizard]

Yes, but stepsoversnails is working in 32 bit.

I tried in 32-bit too. And why 32-bit mode should have worse color mismatching than 16-bit?

Mismatching by 80 green/blue units is still too much. I would understand 4-8 maybe. But 80... weird.

[Snarky]

All right, I've refreshed my memory a bit, and the way I understand it, AGS Color Number is fucked up in several ways:

It is basically the 16-bit RGB value of the color, with some complications:

1. The values 0-31 have been specially assigned to certain basic "reserved AGS palette" colors, including COLOR_TRANSPARENT (i.e. magenta) to 0. (I'm not sure whether this is for consistency with 256-color games, or just a backwards compatibility thing from some remote past when things could only be set to 32 pre-set colors. Or something to do with "magic pink" logic.)

2. This leads to the remapping of a bunch of other colors, either because the slots are taken by the "reserved AGS" colors, or because they've already been mapped to one of those slots, so having them also mapped to some other value would be redundant.

3. In 32-bit, you have to convert the 16-bit RGB value to 32 bits. For certain colors (I'm not sure which it applies to, only the reserved ones, only the others, or all of them?), AGS does this in a very naive way (basically right-shifting the bit values of each color channel), which introduces conversion errors. The colors (particularly bright colors) are therefore slightly "off."

4. Finally, unless this has been fixed in a recent version, the color picker in the AGS Editor does not deal with most of this correctly/intuitively. I forget exactly how it works, but if you enter certain numbers, doesn't the editor just change them to something else? Or does it just display a completely different color in-game? I know that if you pick a named color it usually won't match (e.g. pick "black" and it will be transparent in-game), and I think that also applies to the preview color.

The third effect does not apply to 16-bit games, and you're right, the error should never be as big as 80 in any of the RGB channels (I think the maximum error is 7, with 255 turning into 248). However, the others do.

So I am guessing the problem here is that red has been mapped to one of the 0-31 slots, and that the 16-bit representation of (255,0,0) has instead been used for a rather different shade, (255,80,80). The solution is probably to figure out which AGS color number (somewhere in the 0-31 range) is red.

Edit: BTW, the only documentation I can find anywhere that even mentions anything about this is in the DrawingSurface.GetPixel() entry in the manual: "NOTE: In high-colour games, the first 32 colour numbers have a special meaning due to an AGS feature which maintains compatibility with 8-bit games."

[Crimson Wizard]

So I am guessing the problem here is that red has been mapped to one of the 0-31 slots, and that the 16-bit representation of (255,0,0) has instead been used for a rather different shade, (255,80,80). The solution is probably to figure out which AGS color number (somewhere in the 0-31 range) is red.

The high colors (index > 32) cannot be "remapped" in 16 and 32-bit games. They are always converted by math. The 16-bit representation for (255,0,0) is 63488.

2. This leads to the remapping of a bunch of other colors, either because the slots are taken by the "reserved AGS" colors, or because they've already been mapped to one of those slots, so having them also mapped to some other value would be redundant.

In terms of hires palette the reserved colors take "place" of 32 lowest hues of blue. I haven't heard of such a rule in AGS that would remap colors to something else simply because first 32 palette indices duplicate them. At least the engine code I saw does not indicate this.

E: For the sake of experiment I remapped all 32 system colors to "Red". Yet the color of speech is still 255,0,0.

[Snarky]

E: For the sake of experiment I remapped all 32 system colors to "Red". Yet the color of speech is still 255,0,0.

Not sure why that would make a difference?

But you're right. I made a test game, and the following observations:

-When I set the text color to red, either in the editor or in-game, it is totally red (per print-screen).
-My point 2 above is incorrect. Other colors are not remapped. Most probably any failure to match the "right color" was just due to point 3.
-Point 3 itself seems to have been fixed in recent versions. The conversion is now better, so that 16-bit white converts to 32-bit white, and same for all the primaries. Yay!
-Even in 32-bit games, you can still only specify colors with 16-bit accuracy, either for text color or rawdrawing. So (252,252,252) will be rounded to and displayed as (255,255,255), for example. Similarly, GetPixel() will only return colors with 16-bit accuracy. (Presumably sprites preserve their full 32-bit color depth, though I did not test that.)
-However, as monkey discovered, you can set a color to any 32-bit value. It will treat it as 16-bit, ignoring the high word, except that it doesn't remap the 0-31 slots. So if you need those shades of blue, you can simply add 65536 to the color you want.
-The editor still rounds RGB values to the closest 16-bit value for you, but now its method of rounding doesn't match how it's done in-game, so it will insist that red is (248,0,0), for example.

In conclusion, this was a red herring, and does not explain what's going on for stepsoversnails.