While I don't have the original code, it's something along the lines of this:
// for each palette entry:
pal.r = pal.b = pal.g = (byte) (0.299 * pal.r + 0.587 * pal.b + 0.114 * pal.b)I havent gotten behind the console, but thats like, exactly what I was gonna do, except precompute like 5 or 6 tween values for r,g,b between 255 and the target for greyscale.
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.
So I was able to create all the bits necessary to introduce the palette change in a similar manner (3x256 changes) on the triggerz and at the moment of truth instead of grey I got a GREEN and PURPLE fadeout (I wasnt sure if you meant rbg or rgb for the ratios so i tried both).
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.