| Re: [AD] compare ALLEGRO_COLOR with memcmp |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 6 Jun 2011, at 22:45 , Trent Gamblin wrote:
> Well I have a reason too. I think there may be more than 1 place it's done, but I'm speaking of al_convert_mask_to_alpha specifically. That's a slow function. Comparing individual floats including an epsilon will make it even slower.
That's the reason.
Note that it would be much faster to compare one 32-bit integer (if all colour components were 8-bit integers). So from that argument, using chars to represent components would have been a better idea.
> But here's the big reason why it doesn't need to be changed (in that instance): When you create bitmaps, in whatever paint program there is, you get values ranging from 0-255. When you call al_convert_mask_to_alpha(bitmap, al_map_rgb(255, 0, 255)), the value read from the bitmap and the mapped value will always be the same. You're not going to call al_convert_mask_to_alpha(bitmap, al_map_rgb_f(0.2345, 0.525912445, 0.7812409893)) (are you?)
The question is, what's the correct behaviour if someone does that? There may well be a case where someone tries something remotely similar, and have it not work.
> because you know the mask color from the paint program and it's giving you 0-255 ranged numbers. Just my 2cents.
Yes, in other words, if you need to match exact colours, you should basically use small integers to represent your colours. Agree with that, but Allegro doesn't store them that way.
It's probably not going to be a problem in practice, but unlike you I don't think that it never could be a problem in principle.
Anyway, I guess the answer is "no, won't change".
Evert