 | | | | | |
Lars C. Hassing wrote in http://www.lugnet.com/cad/dev/?n=4187
> (snip)
> During implementation of Gyugyi's Direct Colors, I browsed his LDLite code:
> (snip)
> and read his doc:
> (snip)
> The code and the doc doesn't match!
> If the code is the "truth", then the hex ranges in the last two
> paragraphs should be swapped:
> (snip)
> Please decide which to change, the code or the doc.
> (FYI MLCad follows the code)
Well, Paul, have you decided?
> Also I would like to suggest that 16 is replaced with 17 (0x11):
>
> | zcp->r = 17 * ((c & 0x00000f00) >> 8);
> | zcp->g = 17 * ((c & 0x000000f0) >> 4);
> | zcp->b = 17 * ((c & 0x0000000f) >> 0);
>
> In this way the max color intensity of 15 (0xF) gets mapped to 255 (0xFF)
> in stead of just 240 (0xF0).
What do you think?
/Lars
| | | | | | | | | | | | | | |
In lugnet.cad.dev, Lars C. Hassing writes:
> Well, Paul, have you decided?
I just now noticed the thread. (Thanks for the email).
I'll add support for the 24-bit range, it is a good idea.
I'll look into the documentation bug. The code is correct
and I'll change the docs to match.
For the scaling, multiplying by 17 just seems to be
so "impure". On a 16 bit color display, it
produces an unsightly jump in color around 0x7
(jumping by 3 levels rather than 2), but few people
will be doing shading or color gradients by having many
different-colored triangles, so I guess it is OK.
But I can see the problem: any sort of
black and white output will want to see pure white ffffff
and pure black 000000, and anything else would cause
unsightly dithering on a printer.
Luckily a sclae by 17 is just a shift and an add, so the
performance hit will not be much (maybe nothing depending on
how the code pipelines). So I'll change the code to scale
by 17.
Thanks,
-gyug
| | | | | | |
