Creating CL_Colorf in clanlib 0.9

[rombust]

There is CL_Color for int's
There is CL_Colord for double's

Why not CL_Colorf for floats?

... Thinking about it, why do we need double precision for colours?

[logixoul]

yes I totally agree. we don't need double precision colors (float or double). will you be able to make the change including all the apis that take a Colord? ;)

incidentally this'll fix a gripe of mine where cl_colord gets accidentally constructed from cl_color, leading to sneaky speed problems. ;)

[rombust]

humm, i may be misreading your comment. We need float and/or double...

from opengl spec:



Current color values are stored in floating-point format,
with unspecified mantissa and exponent sizes.
Unsigned integer color components,
when specified,
are linearly mapped to floating-point values such that the largest
representable value maps to 1.0 (full intensity),
and 0 maps to 0.0 (zero intensity).
Signed integer color components,
when specified,
are linearly mapped to floating-point values such that the most positive
representable value maps to 1.0,
and the most negative representable value maps to -1.0 .
(Note that
this mapping does not convert 0 precisely to 0.0.)
Floating-point values are mapped directly.

[rombust]

Fixed in latest SVN - clanlib 0.9 now uses CL_Colorf. (CL_Colord has been kept, if required)

[Magnus Norddahl]

There's a small problem with this patch: it is not complete. A lot of the state classes, such as CL_LightSource and CL_Material, still take doubles instead of floats. The high level 2D classes (CL_Sprite, CL_Draw, CL_RoundedRect, CL_VectorFont) also still use doubles.

This is a problem because it now means the API is not consistent about it, which means that we end up in situations where one has to convert between doubles and floats.

Now we just need to fight over who needs to finish this patch. :D

[rombust]

heh, I forgot that!

I better get it sorted, as my engine will be going live this week

... Fixed (i hope)