// for each palette entry:
pal.r = pal.b = pal.g = (byte) (0.299 * pal.r + 0.587 * pal.b + 0.114 * pal.b) // for each palette entry:
pal.r = pal.b = pal.g = (byte) (0.299 * pal.r + 0.587 * pal.b + 0.114 * pal.b)I also tried 128 across the board for grey, and it just made a dull fade which may be the best I can do with my method.
I think it may simply be because rather than have palletes controlled by rgb, I load predrawn sprites using sfml's sprite and texture classes. So the default rgba is 255,255,255,255 - so I have a sidequest to figure out the RIGHT WAY of applying rgb changes to predrawn sprites.
It may very well be a simple matter of "sfml does it differently" or perhaps having grey variants of all sprites and toggling. I feel there has to be a way to accomplish the fade to grey programmatically. Fun little dive tho! I'll have to post an update when I figure it out.
pal.r = pal.g = pal.b = (77 * pal.r + 150 * pal.g + 29 * pal.b) >> 8;
Hardware floating point was rare before the 486 DX and Pentiums. Not to mention that Integer<->FP conversion was slow. And division of any kind has always been slow. So you'd see a lot of fixed-point math approximations with power-of-two divisors so that you can shift-right.But rather than do that and cache them for timing triggers, I kind of like the scaling down by multiplication approach.
Edit: manipulate the rgb values that is - I wouldnt have converged on those hard values on my own.