GetColorFromRGB : 32 bits?

[Monsieur OUXX]

Is there still a technical reason for the "int" value of a color to be awkward?

By awkward I mean two things :
1) The fact that R, G and B values work by increments and maintain backwards compatibility for palettes, which doesn't let us use all the values for B (see help article for DrawingSurface.GetPixel). Blessed be the innocent soul who does SetPixel 0-31.
2) the fact that int colors go roughly from 0 to 65535, which means 16 bits

Maybe there's a smart way of making those values 32 bits and getting rid of a lot of crap?

[Snarky]

Yeah, it would be great to get away from the nonsense AGS does with colors.

A few years back I started work on a kludgey workaround that would allow you to draw any 32-bit color by overlaying two 1x1 pixel DrawingSurface.DrawImage() calls with carefully set transparency. It worked in theory, but not reliably in practice, presumably because the internal AGS color/transparency calculations didn't exactly match mine.

[Crimson Wizard]

None, except for backwards compatibility, and this is in todo list to change in AGS 4 branch (maybe not documented, but definitely in mind).

[Monsieur OUXX]

this is in todo list to change in AGS 4 branch

Perfection

[Crimson Wizard]

True 32-bit drawing colors are now supported in ags4 branch, will be a part of the next AGS 4 alpha update.

Respected Alpha component is still in TODO, but it may require more work, since all the primitive drawing operations must be affected, so I don't have any prediction as when this may be done.
https://github.com/adventuregamestudio/ags/issues/2525

[Crimson Wizard]

Past few changes, AGS 4 now features full 32-bit ARGB colors, the next PR actually adds support for raw drawing operations with alpha:
https://github.com/adventuregamestudio/ags/pull/2661

Next we'd need to see how standard items work if one assigns a translucent color to them (GUI and speech texts).

[Crimson Wizard]

Fully resolved in the latest AGS 4 release now.