AGS Development > Engine Development

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?

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:

--- Quote from: Crimson Wizard on 12 May 2022, 18:22 ---this is in todo list to change in AGS 4 branch

--- End quote ---



[0] Message Index

Go to full version