[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] rgb_to_color
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Tue, 2 Nov 2004 05:22:19 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CJVyJYJsq5CFdssgiF2VIz3dnnLK+SNFv3BWFqHcdQjg3oadDFTvKuO1YvhDsUXn1tmdpKq537aoQWlWsOBoyp5c6LWftdJDGjdMY2s/t2uCxX81S4maNkuaEODKD4ql/M9CNyLykgQ2cyYUQ8UnQJF38Iy7AY3cp1wWaVikRZs=
On Tue, 2 Nov 2004 11:31:34 +0100, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> Wouldn't this just be a one-line wrapper around makecol? Not that I'm
> opposed to the idea, but is it really that important to have a seperate
> function for it?
Besides having to deal with 6-bit to 8-bit issues, it could also be
useful to specify a depth. like so:
static inline int rgb_to_color(RGB *rgb, int depth)
{
return makecol_depth(depth, rgb->r*255/63, rgb->g*255/63, rgb->b*255/63);
}
Simple, yet not quite as simple as it would initially seem. Most would
only use <<2 and be stuck with improper scaling.
- Kitty Cat