Topic: 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