| RE: [AD] small bug in 15 and 16 bit asm color converters |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: <alleg-developers@xxxxxxxxxx>
- Subject: RE: [AD] small bug in 15 and 16 bit asm color converters
- From: "Robert Ohannessian" <ROhannessian@xxxxxxxxxx>
- Date: Sat, 23 Oct 2004 15:48:31 -0700
- Thread-index: AcS5UhFV7HE/I92STUSzctod55DfzgAAE1lA
- Thread-topic: [AD] small bug in 15 and 16 bit asm color converters
We should benchmark both. If the difference is negligeable, then we
should "do it right"(tm).
> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of Elias Pschernig
> Sent: Saturday, October 23, 2004 3:46 PM
> To: alleg-developers
> Subject: RE: [AD] small bug in 15 and 16 bit asm color converters
>
> On Sat, 2004-10-23 at 11:09 -0700, Robert Ohannessian wrote:
> > You'd normally do:
> >
> > Red8 = (red5 << 3) | (red5 >> 2);
> >
> > This will replicate the upper bits of red5 into the bottom of red8.
This
> > effectively makes 31 map to 255 and 0 map to 0.
> >
>
> Ah, yes. Quite simple. And probably faster than a LUT. But it
definitely
> will be slower than a single POR. So, before implementing it, is
there
> really a problem with having 7/3/7 as black? It feels wrong of course
> (same as having 248/251/248 as white, like Allegro currently does) -
but
> the former doesn't look wrong, while the latter does (on my monitor).
>
> --
> Elias Pschernig
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on
ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give
us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers