[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Eric Botcazou wrote:
OK, I read a bit of that thread on [AL]. I think the best solution would
be to add `case 6' right in front of `case 0'; that should allow any
hue. (Allowing any hue is a Good Thing IMHO because it's usually
depicted as a circle (in particular, the range 0...360 suggests
degrees), and it's continuous that way. Plus, if even Allegro's examples
assume negative hue is ok, chances are that other people do it too.)
There is still a problem though: now 360-epsilon, which gives i = 6, is
treated like 0-60.
Do you mean if hue is so close to 360.0 (but still strictly smaller),
that hue/60.0 is represented exactly as 6? I'm not sure if this can
happen, but I think my code treats this case correctly too.
To convince yourself, first consider the case when hue is pretty close
to 360, say 359.94, so that hue/60.0 is close to, but still strictly
smaller than 6.0, namely 5.999. In this case:
i=5,
f=0.999,
x is very close to v*(1-s),
y is very close to v*(1-s),
so
*r=v,
*g=v*(1-s),
*b=v*(1-s).
Now consider the case when hue is so close to 360 that hue/60.0 is equal
to 6.0. In this case:
i=6,
f=0,
x=v*(1-s),
z=v*(1-s),
so
*r=v,
*g=v*(1-s),
*b=v*(1-s).
So the two cases produce the same results, as the user would expect.
Magic! :-) This works because the hue parameter really is periodic, with
period 360.0. The same reasoning holds if you add or subtract other
small numbers to 0 or 360.0 or -360.0. (Another way to implement it so
that you wouldn't complain in the first place would be to first divide
by 60.0, then do the fmod, but it really doesn't matter).
Sven