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?
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 (https://www.adventuregamestudio.co.uk/forums/index.php?topic=55476.msg636575833#msg636575833), presumably because the internal AGS color/transparency calculations didn't exactly match mine.
None, except for backwards compatibility, and this is in todo list to change in AGS 4 branch (maybe not documented, but definitely in mind).
Quote from: Crimson Wizard on Thu 12/05/2022 18:22:40
this is in todo list to change in AGS 4 branch
Perfection
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
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).
Fully resolved in the latest AGS 4 release now.